Declaration des revenus par Internet

Bonjour,

On Tue, 5 Apr 2005, Cedric Blancher wrote:

Le Mon, 04 Apr 2005 22:29:26 +0000, A. Caspis a écrit :

et que la presse continue à présenter la signature électronique
comme un progrès pour l'usager, alors qu'ici au contraire c'est
un élément de preuve qui lui est opposable et qui finira par
avoir davantage de poids juridique qu'une signature manuscrite.

Amha, une signature électronique ne peut pas avoir plus de poids qu'une
signature manuelle, ne serait-ce que parce que sa valeur est limitée à
la durée de vie de clé qui l'a générée. Si on ajoute à cela toutes

Exact. Mais il y a d'autres limites bien plus génantes:
- il est impensable d'espérer générer un certificat valable plus de 20
ans
- il n'est pas certain que dans 20 ans l'on soit encore capable de relire
les documents signés actuellement, par exemple un document Word signé,
et un document dont on a perdu la signification est un document sans
valeur

Face à ces problèmes techniques, les solutions papier actuelles
fonctionnent bien (merci aux archivistes), et le droit est bien rodé.

Donc à court ou moyen terme la crypto égale la signature manuscrite, avec
un avantage concernant le lien entre la signature et le document signé, et
une égalité sur la valeur de l'identité (on ne peut pas avoir une identité
électronique plus fiable que l'identité réelle).

A long terme, par contre, la crypto s'écroule complètement.

Il y a donc des domaines où la crypto s'applique parfaitement (contrats
BtoB, valables 5 ou 10 ans par exemple), et d'autres où ça ne va
clairement pas (droits d'auteur, qui courent jusqu'aux 70 ans après la
mort de l'auteur).

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
je pense que j'utilise la babasse comme tout le monde surtout pour les
pompes et j'ai eu un reset dans ma tete aussi si qqu'un pouvait
m'envoyer toutes pompes de 1S
-+- JB in GNU : Neuneu JB joue au shaddock -+-

On Tue, 4 Apr 2005, A. Caspis wrote:

Nombreuses NullPointerExceptions dans la console (pas très
rassurant de la part d'une appli crypto... heureusement que
ce n'est pas du C).

Je n'ai rien vu de tel dans ma session de déclaration+signature, je l'ai
faite hier soir, vers 22h.

Pour la déclaration des revenus, les enjeux sont faibles.
Mais cela m'ennuierait que la même infrastructure soit
généralisée à des applications plus sensibles (santé ?)

C'est pire que ça en ce qui concerne la santé, mais bon...

et que la presse continue à présenter la signature électronique
comme un progrès pour l'usager, alors qu'ici au contraire c'est
un élément de preuve qui lui est opposable et qui finira par

Ta signature manuscrite t'est aussi opposable. C'est même son but, c'est
ce qui indique ton intention, l'expression de ta volonté. La signature
électronique ne t'engage pas plus que ça.

avoir davantage de poids juridique qu'une signature manuscrite.

Non, voir mon autre message.

Je suggère donc les améliorations suivantes:

- Une procédure qui me permet de générer mon certificat avec
le logiciel (ou token) de mon choix. Concrêtement: un
formulaire web où je saisis mon nom, mon numéro, le montant
de mon dernier impôt et mon certificat en upload, et qui me

Tu n'envoies pas ton certificat, tu envoies une preuve de la possession de
ta clé privée, et ta clé publique (message PKCS#10), mais c'est en gros
ça.

renvoie mon certificat signé par la DGI.
D'ailleurs on peut probablement déjà faire ça en décortiquant
teleir_cryptolib.jar et les échanges avec le serveur.

Oui, on peut le faire, évidemment. En fait, c'est comme ça que ça
fonctionne réellement, l'applet est un habillage.

- Une procédure de déclaration par email.
Logiquement c'est par là que la PKI devrait se développer.
En pratique: J'édite ma déclaration en ligne avec des jolis
formulaires en HTML, de l'aide en ligne etc. Puis le serveur
me l'envoie par email dans un format non ambigu (XML, ascii).
Je signe et je renvoie l'email signé.

Mouais. Envisageable, mais quelques réserves:
- imaginons que Mme Michu oublie de cocher les cases qui vont bien pour
signer et chiffrer son mail, la déclaration passera donc en clair sur
les tuyaux. On pourrait se dire qu'en envoyant à Mme Michu un document
XML déjà chiffré à destination de la DGI, on évite la compromission
d'informations (Mme Michu ne pourrait pas envoyer un document en clair,
mais simplement non signé), mais là, ce sont les techos qui vont raler
parce qu'ils signent un truc opaque (et ils auront raison), les
cryptologues raleront parce qu'on préfère signer d'abord et chiffrer
ensuite (pour les mêmes raisons, là encore avec raison), et enfin la
DGI va devoir conserver dans ses archives des données chiffrées pendant
un temps indéterminé, avec une clé privée pour les déchiffrer (puisque
la signature est appliquée après le chiffrement)
- et si le logiciel de courrier de Mme Michu veut jouer avec du
formatage, mettre du HTML autour de tout ça, ajouter une marge à
gauche, et autres machins, ça complique d'autant le travail du serveur
pour récupérer ses données. Ceux qui ont un MUA pour dinosaures (genre
Pine ou Mutt) et qui échangent des mails avec des clickophiles sous
Outlook me comprendront.

En matière de sécurité, on doit jongler avec 2 opposés:
- l'utilisateur est potentiellement malveillant et/ou ignorant
- c'est Mal (tm) de faire des choses dans le dos de l'utilisateur,
surtout si ça engage sa responsabilité

Il faut un compromis. L'applet Java tel qu'elle est développée ici en est
un. Ca n'est pas idéal, c'est certain, mais n'importe quelle autre
solution ne sera pas non plus idéale. Un pas vers l'idéal serait d'avoir
des utilisateurs bien informés et compétents, et on peut alors monter le
niveau de sécurité et de complexité de l'ensemble. Mais c'est une utopie,
il faut bien le reconnaître.

Idéalement, le serveur m'envoie un accusé de réception signé.

Ca ce serait bien. Il est clairement indiqué sur le PDF reçu qu'il est
opposable à l'administration fiscale en l'état, mais une signature en
plus, ce serait encore mieux.

Y a t-il des impossibilités techniques ?

Aucune.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Existe-t-il un numéro vert oû ceux qui débuttent sur les forums du web
peuvent poser des questions ? Ce forum de conseils est très bien, mais
il serait bon de pouvoir discuter de vive voix avec des conaisseurs.
-+-Le Guide du Neuneu d'Usenet: Le club des connaisseurs de neuneux -+-

Bonjour,

On Tue, 4 Apr 2005, A. Caspis wrote:

Erwann ABALEA wrote:

Tu proposes quoi pour faire la même chose, en t'adaptant le plus possible
à l'audience la plus large?

Une API suffisamment documentée pour que je puisse l'utiliser
avec des logiciels auxquels je fais confiance. Ensuite, libre à

Ben justement, on attend une unification de cette API. Ca existe déjà:
CAPI, PKCS#11, JCE pour les plus courantes. Sous Windows tu as la CAPI en
natif, utilisée par Office, Outlook (+express), IE, et autres.
Mozilla/Netscape préfère utiliser PKCS#11, qui a aussi ses limites, mais
l'avantage d'être disponible sur plusieurs plate formes. Malheureusement,
en Java, tu n'as pas accès à la CAPI, et difficilement accès à une
bibliothèque PKCS#11 installée sur ton système. Alors tu as le choix entre
JCE et tout faire à la main.

la DGI (ou à des tiers) de proposer une interface interactive
au dessus. Pour la télédéclaration de la TVA des entreprises,
les éditeurs de logiciels de compta n'ont-ils aucun moyen
d'automatiser la procédure ?

Je ne sais pas comment les certificats sont utilisés pour TeleTVA, mais je
pense que c'est techniquement possible. L'audience n'est pas du tout la
même, le logiciel est maîtrisé et ne permet pas tellement la customisation
par l'utilisateur.

La version user-friendly, c'est ce que tu vois à l'écran. La version
parsable par une machine, c'est ce que l'applet signe. Il n'y a pas de
juste milieu.

C'est pourtant un problème crucial. Que se passe t-il si je signe
un document ambigü tel que:
<body bgcolor="#E0E0E0">
<font color="#D0D0D0">Revenus 2004: 0 euro</font>
<font color="#F0F0F0">Revenus 2004: 1 euro</font>
</body>

Outre le fait que le HTML n'est pas la meilleure forme pour stocker des
informations manipulées par une machine, quelle est réellement ta
question? Si tu décides de signer ça, tu t'engages sur des c*nneries, et
tant pis pour toi. Si tu penses à une malveillance de l'application entre
l'affichage et la signature, il n'y a pas de solution magique, et un
binaire opaque externe au navigateur (solution proposée par un autre
contributeur) n'offre rien de ce côté là non plus.

- Pourquoi l'accusé de réception n'est-il pas signé, lui ?
Mme Michu pourrait-elle le vérifier?

Son Outlook afficherait un gros warning en rouge clignotant,
tout comme IE lorsqu'un site web présente un certificat louche.

L'AR n'est pas un mail, c'est un document PDF. As-tu de quoi vérifier un
document PDF signé?

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
j'ai entendu dire que 1 million de site se font sur le web par mois.
Pour sortir ma pageweb de cette folie, j'entreprends d'utiliser tous les
moyens possibles pour la faire connaitre. Allez y le plus possible.
-+- H1 in: Guide du Neuneu d'Usenet - Errare neuneutus est -+-

On Tue, 5 Apr 2005, Laurent Blume wrote:

Erwann ABALEA wrote:

[...]

Mme Michu, Mme Michu... Me rappeler mon mot de passe une fois par an, j'ai du
mal aussi! J'ai eu besoin de quelques essais, et heureusement que c'est un mot
de passe que j'utilise ailleurs.
Et là, quelle solution, à part le noter quelque part, ce mot de passe?

C'est pas une mauvaise solution, si tu n'utilises pas le post-it sous le
clavier. Un logiciel pour stocker tes différents mots de passe, le tout
sous une forme chiffrée, c'est pas si mauvais. C'est un peu comme un
coffre qui contiendrait des clés d'autres coffres.

Pas exactement. On sait fournir un certificat à l'usager final quel que
soit son navigateur (en gros). Ca ne pose aucun problème depuis plusieurs
années. Mais ici, on a besoin d'utiliser le certificat pour un usage non
prévu par les navigateurs, et ça coince.

L'authentification du client par le serveur?

Client au sens humain, pas au sens navigateur. On délivre un certificat
pour un usager. On a plusieurs solutions pour ça:
- type DGI: des infos d'un niveau de confidentialité variable sont
envoyées à l'usager, et sont stockées sur les serveurs de la DGI. Une
comparaison est effectuée quand l'usager veut un certificat,
- type Verisign serveur: l'usager demande un certificat, sa demande est
en attente côté AC, un (ou plusieurs) représentant de l'AC contacte
l'usager (par téléphone par exemple), effectue quelques vérifications,
et décide de valider ou rejeter la requête.

D'ailleurs, il faudra que je vois s'il est possible/utile de chercher un contact
technique pour remonter ces problèmes si j'arrive à les cerner correctement.

Je ne peux pas remonter ces infos, mais je sais que ça ne sert à rien,
tout sera changé pour la prochaine campagne.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----

Il veut que frjv disparaisse afin que les contacts entre pirates
et public soit réduits. Cela afin d'assurer son pain quotidien.
lepen va etre content d'apprendre que des ges partageant ses idees

-+- Gleny in: Guide du Neuneu d'Usenet - Le Godwin pour les nuls -+-

On 05 Apr 2005 07:42:13 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:

Par contre, comment l'administration fiscale peut-elle prouver qu'une
déclaration donnée a bien été effectuée par un contribuable et pas par
l'administration fiscale elle-même ?

Justement parce que le certificat du client est généré par l'applet
Java sur le poste du client, et que l'administration n'en possède pas la
clé publique. Non ?

Non. Qu'est-ce qui prouve que le "poste du client" n'est pas en fait
le poste d'un employé de l'administration fiscale ?


--
;-)

Erwann ABALEA wrote:

C'est pas une mauvaise solution, si tu n'utilises pas le post-it sous le
clavier. Un logiciel pour stocker tes différents mots de passe, le tout
sous une forme chiffrée, c'est pas si mauvais. C'est un peu comme un
coffre qui contiendrait des clés d'autres coffres.

À condition toutefois que l'utilisateur réussisse à garder ce logiciel pendant
un an sans perte de disque...
Je pense que pratiquement, la disquette (ou CD-R ou clef USB ou autre support
amovible et fiable) plus le post-it dessus, rangé avec les déclarations
physiques, ce n'est effectivement pas si mal.
Comme je l'ai écrit par ailleurs, je pense que ces informations ne sont pas très
confidentielles, et comme d'autres l'ont indiqué, ce n'est qu'une signature.
Après tout, qui se soucie de sécuriser parfaitement se signature manuscrite?

Client au sens humain, pas au sens navigateur. On délivre un certificat
pour un usager. On a plusieurs solutions pour ça:
- type DGI: des infos d'un niveau de confidentialité variable sont
envoyées à l'usager, et sont stockées sur les serveurs de la DGI. Une
comparaison est effectuée quand l'usager veut un certificat,
- type Verisign serveur: l'usager demande un certificat, sa demande est
en attente côté AC, un (ou plusieurs) représentant de l'AC contacte
l'usager (par téléphone par exemple), effectue quelques vérifications,
et décide de valider ou rejeter la requête.

Ok, je vois, merci.

Je ne peux pas remonter ces infos, mais je sais que ça ne sert à rien,
tout sera changé pour la prochaine campagne.

Bonne chose, parce que ce matin, derechef, l'authentification de mon proxy ne
passe plus. Étrange, un coup oui, un coup non.

Laurent

Le Tue, 05 Apr 2005 11:15:09 +0000, Fabien LE LEZ a écrit :

Non. Qu'est-ce qui prouve que le "poste du client" n'est pas en fait
le poste d'un employé de l'administration fiscale ?

Qu'est-ce qui prouve que la déclaration d'impôt qui t'es opposée avec
ta signature en bas a bien été signée par toi ?...


--
Puisque nous n'avons aucun problème traduisant le Suédois au frencece
ne devrait pas être aucun problème pour que vous le fassiezl'autre voie
autour. Sucez sur ceci: www.Hlookslikeshit.xxx.com
-+- H in GNU : Pour qui sont ces suédois qui sucent sur nos sites ? -+-

Client au sens humain, pas au sens navigateur. On délivre un certificat
pour un usager. On a plusieurs solutions pour ça:
- type DGI: des infos d'un niveau de confidentialité variable sont
envoyées à l'usager, et sont stockées sur les serveurs de la DGI. Une
comparaison est effectuée quand l'usager veut un certificat,

Je pense qu'une grosse partie du probleme viens de là...
Quelle est la valeur d'une signature électronique dont on a pas la certitude
que le certificat et sa clé privée sont bien uniquement en la possession de
la personne physique (et morale) ?
J'entends par là deux problèmes :
- Qu'est-ce qui empeche une tierce personne de générer un certificat a mon
nom ?
- Qu'est-ce qui empeche une tierce personne de me voler mon certificat sur
mon poste informatique (bon, je suis parano, ca peux être difficile, mais
sur une machine d'utilisateur lambda...) ?

Pour moi, le certificat tel qu'il est généré n'a que peux de valeur... voire
même moins de valeur qu'une signature manuscrite.
On peut imiter ma signature, mais ca reste une imitation, on ne me volera
pas ma main pour signer a ma place...

En ce sens, je pense que l'approche belge de la carte d'identitée
electronique est une avancée. La clé privée ne sortant pas de la carte, on
peux avancer que le signataire est bien en possession de sa propre carte...
en cas de perte ou de vol, le certificat est révoqué.. rendant les
signatures effectuées après la date du vol ou de la perte invalides.

Erwann ABALEA wrote:

Outre le fait que le HTML n'est pas la meilleure forme pour stocker des
informations manipulées par une machine, quelle est réellement ta
question?

La console Java suggère que j'ai signé numériquement non
seulement ma déclaration, mais aussi le contrat d'utilisation
du service de télédéclaration, qui est justement en HTML:

| formToSign <?xml version="1.0" encoding="ISO-8859-1"?>
| <FORM_XML VALUE=CONTRAT>
| <html><head><title>Contrat d'adhesion</title>
| <meta http-equiv="Content-Type" content="text/html;
| charset=iso-8859-1">
| <link rel="stylesheet" href="/css/teleIR.css">
| </head>
| [...]

Comme la feuille de style teleIR.css n'est pas couverte par la
signature, la DGI pourrait la modifier pour changer a posteriori
l'apparence du document que j'ai signé. Après lecture rapide du
HTML, il n'y a pas de risque, mais sur le principe, c'est mal.

Je ne sais pas si cette signature est transmise au serveur,
ni si elle est vérifiée. En 2006 je patcherai l'applet pour
signer un contrat bidon, pour voir.
C'est peut-être seulement un test des fonctions de crypto.
On ne sait rien. Ce n'est pas documenté.

Si tu décides de signer ça, tu t'engages sur des c*nneries, et
tant pis pour toi. [...]

Sur le moment je n'étais pas conscient d'avoir signé
numériquement ce contrat d'utilisation. Et vous ?

AC

On Tue, 5 Apr 2005, Cedric Blancher wrote:

Le Tue, 05 Apr 2005 06:20:47 +0000, Fabien LE LEZ a écrit :

Par contre, comment l'administration fiscale peut-elle prouver qu'une
déclaration donnée a bien été effectuée par un contribuable et pas par
l'administration fiscale elle-même ?

Justement parce que le certificat du client est généré par l'applet
Java sur le poste du client, et que l'administration n'en possède pas la
clé publique. Non ?

Non. L'applet génère une paire de clés RSA, construit une requête PKCS#10
(cette requête contient la clé publique et un DN qui ici ne sert à rien,
le tout est signé par la clé privée), et envoit cette requête avec les
infos saisies par l'usager.
Côté DGI, un module (appelé AA) vérifie que les informations saisies sont
correctes, que la requête est bien formée, que la signature de la requête
est valide, et envoit tout ça plus infos complémentaires à la plate forme
hébergeant l'AC de la DGI (envoi signé+chiffré).
Cette plate forme vérifie la signature de l'AA, les infos, tout ça,
vérifie que l'usager n'a pas déjà un certificat en cours de validité,
fabrique le certificat de l'usager, et le renvoit au module AA.
Le module AA reçoit ce certificat, met à jour les différents référentiels
(il y en a 2), et renvoit le certificat à l'applet.
L'applet reçoit le certificat, elle a toujours la clé privée dans un
fichier PKCS#12 chiffré, elle n'a plus qu'à ouvrir le PKCS#12, ajouter le
certificat, et refermer le tout.

En dehors de la génération de la clé privée, tout ça prend environ 4 à 5
secondes quand tout se passe en ligne.
En cas de forte charge, un mécanisme de delestage est mis en oeuvre, qui
consiste à mettre les requêtes à l'AC en attente, et elles passeront au
fil de l'eau, quand la charge redeviendra acceptable. L'usager recevra
alors un email lui indiquant où récupérer son certificat, celui-ci aura
déjà été intégré dans les 2 référentiels.

Même circuit pour une révocation, mais la plate forme AC ne délivre pas de
certificat, elle renvoit simplement un status (OK), et les référentiels
sont mis à jour en conséquence. Une CRL est ensuite générée
périodiquement, pour qui veut la vérifier.

Après, l'administration fiscale a une copie du certificat de l'usager
(seulement son certificat, c'est un objet publique que tout le monde peut
obtenir en cherchant bien). Un des référentiels sert à filtrer les accès
Web, l'autre est une sorte de référentiel maître (et cas de
désynchronisation, il faut un maître et des répliqués).

Évidemment, on pourrait arguer que l'applet est
biaisée et que la clé privée est en fait envoyée à la méchante
administration, mais les études de l'applet ne le montre pas.

J'allais dire: "et les études des flux ne le montrent pas", mais tout est
en SSL. Je sais ce qui est envoyé, mais je ne peux rien en dire. Je peux
simplement dire, avec le peu de valeur que ça peut avoir, que tout est
fait proprement, dans les règles de l'art.

J'espère que je n'en ai pas trop dit. Je ne pense pas, honnètement, il n'y
a rien que du classique là-dedans.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Moi je dis : 3 lignes c'est suspect, c'est fait pour le GCU.
-+- SP in Guide du Neuneu sur Usenet : Allez hop ! Au GNoUf -+-