utiliser certificat impots pour signer mail

Patrick Mevzek wrote:

garantie .. d'identité ? vous connaissez réellement des serveurs qui
téléchargent les CRL de la direction générale des impots ??

Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.

Ah tient ? Ce n'est pas à l'utilisateur d'assurer la validité des
certificats utilisés en assurant que son logiciel préféré utilise bien
les CRLs ?
Marrant ca, j'avais cru comprendre le contraire sur fr.comp.securite...

C'est à la partie qui reçoit les données de vérifier la validité du
certificat de la partie qui les envoie avant de lui faire confiance.

En l'occurence, les données vont de l'utilisateur vers la DGI, donc
c'est à la DGI de faire la vérification, et pour la DGI cela pose
beaucoup moins de problèmes de mettre le serveur qui va supporter le
volume de la CRL qu'à l'utilisateur.

Si plus tard la DGI envoie des données signées aux utilisateurs, alors
ils ont tout intérêt à en vérifier la non révocation, on espère que la
DGI utilisera alors une CA séparée dans sa hiérachie pour que la taille
de la CRL soit plus gérable.

Ah tient ? Ce n'est pas à l'utilisateur d'assurer la validité des
certificats utilisés en assurant que son logiciel préféré utilise bien
les CRLs ?
Marrant ca, j'avais cru comprendre le contraire sur fr.comp.securite...

C'est à la partie qui reçoit les données de vérifier la validité du
certificat de la partie qui les envoie avant de lui faire confiance.

Sauf qu'on parlait du cas de figure de l'usage du certificat pour envoyer
un email donc entre deux utilisateurs sans rapports avec la DGI.
(en pure théorie, puisque ce n'est pas possible en pratique).

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

On Tue, 18 Jan 2005, Jean-Marc Desperrier wrote:

Erwann ABALEA wrote:

Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.

Si, si, excellent test pour les capacités des logiciels :-)

De quels logiciels? ;)
Et si on mettait la CRL sur BitTorrent, plutôt que sur nos serveurs? ;)

Elle fait 20 Mo
environ, contient 576022 certificats révoqués (aujourd'hui), bouffe
environ 70 Mo de RAM une fois parsée par OpenSSL. Je pense qu'on devrait
atteindre les 40Mo à la fin de la prochaine campagne.
C'est énorme et dérisoire. ;)

Au moins cela peut servir d'exemple montrant de manière définitive que 3
ans de validités, c'est beaucoup trop pour des certificats destinés au
grand public, et que la bonne solution est un renouvellement automatisé
sans aucun manipulation pour quand ils reviennent l'année suivante.

3 ans avec une seule utilisation par an, pour une population aussi large
et diversifiée, c'est largement trop, on est d'accord.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tu as une vision obsolète du Net. Les groupes sont hébergés chez les
FAI maintenant. Il FAUT que leur gestion change.
-+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-

On Tue, 18 Jan 2005, Patrick Mevzek wrote:

garantie .. d'identité ? vous connaissez réellement des serveurs qui
téléchargent les CRL de la direction générale des impots ??

Un utilisateur peut configurer son logiciel de courrier pour télécharger
*la* CRL, mais honnètement, il ne devrait pas le faire.

Ah tient ? Ce n'est pas à l'utilisateur d'assurer la validité des
certificats utilisés en assurant que son logiciel préféré utilise bien
les CRLs ?
Marrant ca, j'avais cru comprendre le contraire sur fr.comp.securite...

Le smiley n'est apparu que plus tard. En fait, c'est la plus grosse CRL
que je connaisse, et elle va encore grossir. Comme je l'écrivais, c'est
énorme et ridicule. La Bonne Chose (tm) à faire est bien évidemment de
télécharger la CRL, quand on doit vérifier la validité du certificat (et
qu'on n'a pas d'autre moyen, ce qui est très important), mais en l'état
actuel, faire cette opération mettra à genoux une liaison RTC et un PC bas
de gamme. Garanti.
Comme l'écrit plus tard JMD, la DGI n'a pas besoin de télécharger cette
CRL, donc pour eux c'est tout bénef. Ils n'ont pas besoin de cette CRL
parce qu'ils ont un autre moyen de vérifier les révocations. Lire la norme
X.509 ou la RFC3280 pour plus de détails.

Concernant ce dont on cause ailleurs, il s'agit de la Class3 Code Signing
de chez VRSN, et la CRL correspondante fait moins de 100k. L'ordre de
grandeur fait que le smiley ne s'applique pas, et que ne pas vérifier la
CRL n'est pas une bonne pratique.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tous cela, il faut que ça change. Je PAYE mon abonnement Internet et
j'exige que mon vote et mes opinions soient pris en considération.
-+- Rocou In GNU - Les payeurs ne sont pas les conseilleurs -+-

Concernant ce dont on cause ailleurs, il s'agit de la Class3 Code
Signing de chez VRSN, et la CRL correspondante fait moins de 100k.
L'ordre de grandeur fait que le smiley ne s'applique pas, et que ne pas
vérifier la CRL n'est pas une bonne pratique.

Donc il y a deux types de CRLs, les bonnes et la mauvaises.
La différence entre les deux, c'est que les bonnes faut les utiliser,
mais pas les mauvaises.
Quoi qu'il en soit, en cas de problèmes, c'est de la faute de
l'utilisateur.
Bof.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

On Tue, 18 Jan 2005, Sylvain wrote:

La norme X.509 ne se réfère pas au PKCS#6, pas besoin. Les extensions des
certificats sont complètement définis dans la norme X.509.

meaningless, autant dire que X509 n'est pas basé sur ASN.1

Vous confondez. Il n'y a pas d'extension critique dans les certificats
TeleIR v1. Je parlais de l'extension d'OID 2.16.840.1.113733.1.6.9, qui
n'est qu'un booléen.

un boolean dans un octet string ... (as per P.6)

La branche 2.16.840.1.113733 appartient à VeriSign,

c'est acquis depuis le début du thread.

et l'extension en question signifie simplement que le certificat a été
délivré en utilisant leur plate forme "OnSite" (rien de bandant donc). Le
FFh, c'est la valeur du booléen de l'extension, pas la criticité de cette
extension.

exact, erreur de lecture de ma part.

garantie .. sécuritaire ? un P.12 (une clé et son cert) stocké dans un
cert store logique (sur disque) et donc non protégé par code porteur est
loin d'être sur.

Comment ça non protégé par code porteur? Tu n'as pas saisi de mot de passe
pour sauvegarder ton PKCS#12? C'est ton problème alors.

?? soit vous répondez déliberemment à coté (dans un esprit récemment
évoqué: moi Linuxien je fais tout bien, vous windowsien ne faites que
des conneries et "c'est votre problème"), soit vous confondez la
protection du p.12 par PBE pour en assurer le transport (là il y a un
mot de passe) et protection de l'utilisation de la clé, pour ce second
point et sous windows (là où on rencontre des Outlook) aucun mot de
passe ne protège l'utilisation d'une clé si elle est stockée par le CSP
Microsoft (et le download depuis le Minefi ne laisse pas le choix du CSP
conteneur).

noter par ailleurs que le P.12 transmis chiffre la clé privée par
pbeWithSHA1And3KeyTripleDES_CBC (bien) mais chiffre également le cert
par pbeWithSHA1And40BitRC2_CBC (nettement moins bien); or comme le même
password est utilisé une attaque force brute sur le second révèlera le
premier; éclairez-moi si j'ai loupé qlq chose.

euh un second cert/clé j'espère, sinon (chiffrer avec sa clé de
signature) ce sera une bétise de plus.

Non, un seul bi-clefs. Ca n'est pas une si grosse bétise que ça, tant que
tu choisis une taille de clefs raisonnable.

la taille des clés ne change rien à l'histoire!
ici encore, j'ai l'impression que vous ne faites aucun cas de la
protection contre l'utilisation (abusive) de la clé.

coté utilisateur, un cert de chiffrement sert sans arrêt pour discuter
avec un proxy, un serveur SSL, un serveur DHCP, etc, etc; la raison veut
que la clé privée soit libre d'emploi ou débloquer une fois par session.

la clé de signature (surtout si marqué non répudiation) doit être
protégée par une vérification systématique (à chaque usage) du porteur.

utilisez une seule clé pour ces 2 usages et n'importe quel faux serveur
générera autant de vrai-fausses-signatures qu'il le souhaite.

Sylvain.

Sylvain wrote:

[...] pour ce second
point et sous windows (là où on rencontre des Outlook) aucun mot de
passe ne protège l'utilisation d'une clé si elle est stockée par le CSP
Microsoft (et le download depuis le Minefi ne laisse pas le choix du CSP
conteneur).

La version de l'applet actuelle n'utilise pas le moins du monde le CSP
Microsoft uniquement un exemplaire du certificat stocké sur disque dans
un PKCS12 et protégé par le mot de passe que vous fournissez dans
l'interface.

Si une version future l'utilise, elle devrait permettre aussi de choisir
son CSP.

Par ailleurs, quand on importe un certificat dans le CSP Microsoft
logiciel, il est possible de choisir l'option "protection renforcée"
dans laquelle un mot de passe est bel et bien utilisé pour chiffrer la
clé privée.
Il y a même un note de Microsoft indiquant que sur ses anciennes version
d'OS c'est le seul moyen d'avoir un minimum de sécurité pour la clé
privé, car l'algo utilisé pour chiffrer les données du compte à partir
de l'identifiant de session est totalement cassé.

[...] le P.12 transmis chiffre la clé privée par
pbeWithSHA1And3KeyTripleDES_CBC (bien) mais chiffre également le cert
par pbeWithSHA1And40BitRC2_CBC (nettement moins bien);

C'est assez usuel, la DGI ne dérive pas de pratiques courantes en cela.

or comme le même
password est utilisé une attaque force brute sur le second révèlera le
premier; éclairez-moi si j'ai loupé qlq chose.

Si c'était vrai, cela serait un faille énorme de l'algo utilisé, en
l'occurence PKCS#5. Ca serait connu, non ?

Et donc pkcs#5 dérive les clé à partir du mot de passe en utilisant un
sel, la valeur de clé RC2 généré pour le premier cas et le deuxième
n'est pas la même. Brute forcé la seconde n'apportera rien pour attaquer
la première.

Joliment essayé cependant.

[...]
coté utilisateur, un cert de chiffrement sert sans arrêt pour discuter
avec un proxy, un serveur SSL, un serveur DHCP, etc, etc; la raison veut
que la clé privée soit libre d'emploi ou débloquer une fois par session.

la clé de signature (surtout si marqué non répudiation) doit être
protégée par une vérification systématique (à chaque usage) du porteur.

utilisez une seule clé pour ces 2 usages et n'importe quel faux serveur
générera autant de vrai-fausses-signatures qu'il le souhaite.

Non, l'algo de signature est différent de celui de chiffrement, une
valeur généré pour un chiffrement ne peut être réutilisée pour une
signature. De même pour l'authentification, on ne fait pas signer
directement une valeur quelconque.

Ca reste assez peu élégant, quand on débloque la clé pour un usage, on
la débloque pour l'autre, et il est plus propre d'avoir des certificats
bien séparés.

Sylvain wrote:

La version de l'applet actuelle n'utilise pas le moins du monde le CSP
Microsoft uniquement un exemplaire du certificat stocké sur disque dans
un PKCS12 et protégé par le mot de passe que vous fournissez dans
l'interface.

ok, merci pour ce rappel, je ne savais plus précisemment comment ce P.12

était arrivé là -- on ne doit pas payer d'impots assez souvent :-/

Par ailleurs, quand on importe un certificat dans le CSP Microsoft
logiciel, il est possible de choisir l'option "protection renforcée"
dans laquelle un mot de passe est bel et bien utilisé pour chiffrer la
clé privée.

exact, ce n'est toutefois pas le choix par défaut.

[...] le P.12 transmis chiffre la clé privée par
pbeWithSHA1And3KeyTripleDES_CBC (bien) mais chiffre également le cert
par pbeWithSHA1And40BitRC2_CBC (nettement moins bien);

Et donc pkcs#5 dérive les clé à partir du mot de passe en utilisant un
sel, la valeur de clé RC2 généré pour le premier cas et le deuxième
n'est pas la même. Brute forcé la seconde n'apportera rien pour attaquer
la première.

exact aussi, le salt étant nécessairement transmis (comme paramètre de
l'algo), la clé (re)générée ne dépends que du password; la taille de la
clé n'intervient pas dans sa protection et seul l'entropie du password
compte.

j'vais retourner coder mes additions, m'évitera de dire trop de bétises.

Sylvain.

On Wed, 19 Jan 2005, Patrick Mevzek wrote:

Concernant ce dont on cause ailleurs, il s'agit de la Class3 Code
Signing de chez VRSN, et la CRL correspondante fait moins de 100k.
L'ordre de grandeur fait que le smiley ne s'applique pas, et que ne pas
vérifier la CRL n'est pas une bonne pratique.

Donc il y a deux types de CRLs, les bonnes et la mauvaises.
La différence entre les deux, c'est que les bonnes faut les utiliser,
mais pas les mauvaises.

En supprimant les parties importantes de mes contributions, on peut me
faire dire ce qu'on veut, c'est évident, vous en faites la démonstration
jour après jour...

Je reprend une partie de ce que j'ai écrit:
-----
La Bonne Chose (tm) à faire est bien évidemment de
télécharger la CRL, quand on doit vérifier la validité du certificat (et
qu'on n'a pas d'autre moyen, ce qui est très important), mais en l'état
actuel, faire cette opération mettra à genoux une liaison RTC et un PC bas
de gamme. Garanti.
-----

Ai-je écrit qu'il ne fallait pas télécharger et vérifier cette CRL? A
moins que nous ne parlions pas la même langue (c'est possible après tout,
un autre trolleur fou n'use pas du même vocabulaire que le reste du
monde), la réponse est non. Vous pouvez pinailler tant que vous vouler,
jouer de votre mauvaise foi habituelle, c'est non.

Ici, l'utilisateur peut télécharger la CRL, elle est disponible, et elle
est même indiquée dans votre extension préférée, la crlDP:
http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL

Il reste 2 moyens de vérifier la validité d'un certificat (la norme en
parle, j'en parle, n'allez pas me dire que vous ne saviez pas que c'était
permis). L'un n'est utilisable que par la DGI, il s'agit de leur base de
données interne (je ne détaillerai pas ici le pourquoi de la chose, pour
des raisons évidentes de confidentialité), l'autre est utilisable par tout
un chacun, il s'agit de faire pointer son navigateur vers
https://onsite.certplus.com/services/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/
de cliquer sur le lien 'Search', et de renseigner ses critères. Simple. En
faisant cela, vous interrogez la base de données de l'AC (qui n'est pas la
base de données de la DGI dont je cause plus tôt).

"Ah ben oui, mais personne ne nous l'avait dit". C'est tout simplement
parce que vous n'ètes pas censé utiliser ce certificat avec votre logiciel
de courrier, donc personne n'a communiqué là-dessus. Est-ce une faute?
S'il vous reste un peu de mauvaise foi, servez-vous en.

Quoi qu'il en soit, en cas de problèmes, c'est de la faute de
l'utilisateur.

Ici oui. Clairement. Mme Michu ne sait pas ce qu'est un certificat, une
CRL, ne lit pas fmc, et n'ira pas essayer d'importer son certificat DGI
dans son logiciel de courrier. Mais la population qui essaye de le faire
n'est pas constituée de Mme Michu.

"Ah ben non M'sieur l'assureur, je savais pas qu'en bidouillant mon moteur
je perdais le bénéfice de l'assurance en cas d'accident..."

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Keyboard not connected, press <F1> to continue.

On Wed, 19 Jan 2005, Sylvain wrote:

On Tue, 18 Jan 2005, Sylvain wrote:

La norme X.509 ne se réfère pas au PKCS#6, pas besoin. Les extensions des
certificats sont complètement définis dans la norme X.509.

meaningless, autant dire que X509 n'est pas basé sur ASN.1

C'est marrant le nombre de gens qui commentent la X.509 sans l'avoir lue.
X.509 est basée sur ASN.1 (X.208/X.680), explicitement. X.509 est basée
sur DER (X;209/X.690), explicitement. Mais X.509 n'utilise aucune
définition de PKCS#6, et la définition d'une extension X.509 n'est pas la
même qu'un attribut PKCS#6, de même qu'un certificat X.509v3 n'a pas le
même format qu'un 'ExtendedCertificate' de PKCS#6. Bref, aucun lien entre
PKCS#6 et X.509v3. Autant dire qu'il y a un lien entre une clé PGP et un
certificat X.509.

Vous confondez. Il n'y a pas d'extension critique dans les certificats
TeleIR v1. Je parlais de l'extension d'OID 2.16.840.1.113733.1.6.9, qui
n'est qu'un booléen.

un boolean dans un octet string ... (as per P.6)

Non. Un booléen. Le fait que ce soit encodé dans un OCTET STRING est
implicite, puisque c'est comme ça qu'une extension X.509v3 est codée. Mais
le contenu de l'extension (sa charge utile) est un booléen, pas "un
boolean dans un octet string".

La branche 2.16.840.1.113733 appartient à VeriSign,

c'est acquis depuis le début du thread.

Je ne suis pas certain que tous les lecteurs aient en tête l'association
2.16.840.1.113733 <=> VeriSign, c'est pourquoi je l'ai indiqué.

garantie .. sécuritaire ? un P.12 (une clé et son cert) stocké dans un
cert store logique (sur disque) et donc non protégé par code porteur est
loin d'être sur.

Comment ça non protégé par code porteur? Tu n'as pas saisi de mot de passe
pour sauvegarder ton PKCS#12? C'est ton problème alors.

?? soit vous répondez déliberemment à coté (dans un esprit récemment
évoqué: moi Linuxien je fais tout bien, vous windowsien ne faites que
des conneries et "c'est votre problème"), soit vous confondez la
protection du p.12 par PBE pour en assurer le transport (là il y a un
mot de passe) et protection de l'utilisation de la clé, pour ce second
point et sous windows (là où on rencontre des Outlook) aucun mot de
passe ne protège l'utilisation d'une clé si elle est stockée par le CSP
Microsoft (et le download depuis le Minefi ne laisse pas le choix du CSP
conteneur).

[... JMD a répondu à cette question, et aux autres ...]

Pour répondre autrement à votre question, vous faites (implicitement ou
explicitement) confiance à un certificat code signing pour exécuter du
code sur votre Windows. Savez-vous comment est protégée la clé privée du
développeur? C'est simplement l'équivalent d'un PKCS#12 stocké sur disque.
Rien de plus.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
j'ai entendu dire qu'une société allait commercialiser des logiciels
permettant de ne pas télécharger les pubs et je vous trouvre cela
inadmissible. Les sites seront mis tout nu et cela ridiculisera le site.
-+- BL in: Guide du Neuneu d'Usenet - A poil, tout le monde a poil -+-