utiliser certificat impots pour signer mail

Erwann ABALEA wrote:

Et une criticité, qui peut parfois influer sur la sémantique à accorder à
l'extension (par exemple le certificatePolicies, voir sa sémantique dans
la norme (pas la RFC3280, elle est borgne sur ce point), c'est "amusant").

A ce que je sache, le X509 v4 retire les mentions dans ce sens sur le
"Certificate Policy", en particulier celle cité ici :
http://www.imc.org/ietf-pkix/old-archive-97/msg01554.html

Et je crois qu'il y a maintenant un addendum à la norme précisant que la
criticité ne doit jamais changer la sémantique de l'extension.

Et l'opinion des personnes les plus autorisées dans ce domaine semble
être unanime pour faire en sorte que ce soit le cas partout, et que s'il
reste des endroits où le texte des normes/RFC dit autre chose, qu'on
trouve une solution pour le corriger et éliminer ces situations.

Ce qui n'empèche qu'il reste plusieurs cas (CRLDP, key usage) où l'on
autorise les applications à ne pas prendre en compte les extension
non-critiques.
Mais ce n'est pas vraiment une sémantique différente, c'est plutôt faire
comme si l'extension était totalement inconnu, ce qui revient à ce que
l'application utilise le certificat sans implémenter l'extension, ce qui
est justement autorisé par le fait qu'elle soit non critique.

Par ailleurs, les RFC du PKIX sont un profile de la norme ANSI.
Ce qui signifie que le PKIX restreint l'ensemble de ce qui est autorisé
par la norme. Ce qui signifie que quand il y a apparement un conflit
entre les deux, lorsque les intructions du PKIX restreignent plus que ce
ne fait la norme, il ne s'agit pas réellement d'un problème, et les
implémentations conformes au PKIX peuvent rejeter des cas autorisés par
X509 (si on trouve un cas inverse, là c'est un défaut de PKIX).
Et je crois que ce que dit la RFC3280 sur les certificate policy c'est
de la prendre en compte de la même manière que si elle était critique,
ce qui restreint simplement les valeurs autorisées par rapport à X509
v3, donc n'a jamais posé de problème.

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

Erwann ABALEA wrote:

Et une criticité, qui peut parfois influer sur la sémantique à accorder à
l'extension (par exemple le certificatePolicies, voir sa sémantique dans
la norme (pas la RFC3280, elle est borgne sur ce point), c'est "amusant").

A ce que je sache, le X509 v4 retire les mentions dans ce sens sur le
"Certificate Policy", en particulier celle cité ici :
http://www.imc.org/ietf-pkix/old-archive-97/msg01554.html

Je pensais plutôt au paragraphe 8.2.2.6 du draft v7 de X.509 4ème édition
(et pas v4, on ne change pas la version). Je viens de vérifier, le
paragraphe est le même dans la X.509v3 de 2000 (même numéro, même texte).

La partie en question dit ceci:
-----
Si l'extension est marquée comme critique, ceci indique alors que le
certificat sera utilisé uniquement pour les buts et conformément aux règles
impliquées par l'une des politiques de certificat indiquées. Les règles
d'une politique particulière peuvent exiger que le système utilisant des
certificats traite d'une manière particulière la valeur du qualificatif.

Si l'extension est marquée comme non critique, son utilisation ne limite
pas nécessairement l'utilisation du certificat aux politiques figurant dans
la liste. Un utilisateur de certificat peut toutefois exiger la présence
d'une politique particulière pour utiliser le certificat (voir article 10).
Les qualificatifs de politique peuvent être traités ou ignorés au choix de
l'utilisateur de certificat.
-----

Il ne s'agit pas ici du "support" ou non de l'extension, mais de savoir
comment on la traite, puisque même une application sachant traiter
correctement cette extension aura un comportement différent pour cette
extension selon que celle-ci est déclarée critique ou non.

Cette permissivité découle à mon sens directement du paragraphe 8.1.1, qui
dit ceci, entre autres:
-----
Tous les certificats sont émis conformément à une
politique, même si cette dernière ne figure pas dans le certificat ou n'est
pas référencée par ce dernier.
-----

Je n'ai pas vu de différence dans le draft v7 que j'ai sur ces points, à
part le dernier paragraphe cité, qui devient:
-----
All certificates are issued in accordance with a policy, even if the policy
is neither recorded anywhere nor referenced in the certificate.
-----
qui est encore plus permissif (puisqu'on peut se permettre de ne pas
référencer du tout la politique).

Et je crois qu'il y a maintenant un addendum à la norme précisant que la
criticité ne doit jamais changer la sémantique de l'extension.

C'est déjà le cas avec l'actuelle norme (X.509v3/2000):
-----§7-----
Lorsqu'elle reconnaît une extension et
qu'elle est capable de la traiter, une implémentation utilisant des
certificats doit traiter ladite extension quelle que soit la valeur du
marquage de criticité.
-----

Et pourtant.... ;)


Dans la RFC3280, c'est la paragraphe 4.2.1.5 qui s'applique, et ce
paragraphe ne traite que le cas où l'extension est déclarée comme
critique.

Et l'opinion des personnes les plus autorisées dans ce domaine semble
être unanime pour faire en sorte que ce soit le cas partout, et que s'il
reste des endroits où le texte des normes/RFC dit autre chose, qu'on
trouve une solution pour le corriger et éliminer ces situations.

C'est ce que je pensais il y a quelques années encore, mais aujourd'hui je
suis moins de cet avis. Il est clair qu'adopter ce comportement
(critique=je jette si je ne connais pas, non-critique=je fais le travail
correctement quand même) simplifie le travail des implémenteurs, mais il
offre moins de souplesse (par exemple, on perd le comportement actuel du
certificatePolicies tel qu'il est décrit). On peut quand même se
débrouiller pour 'regagner' cette souplesse, en créant d'autres
extensions, mais du coup, ça 'recomplexifie' le travail de
l'implémenteur... Alors est-ce vraiment la peine de tenter de gagner ce
qu'on va peut-être perdre plus tard? bof.

Ce qui n'empèche qu'il reste plusieurs cas (CRLDP, key usage) où l'on
autorise les applications à ne pas prendre en compte les extension
non-critiques.

On voit donc bien qu'on a besoin d'un drapeau indiquant qu'on veut
renforcer les contrôles...

Mais ce n'est pas vraiment une sémantique différente, c'est plutôt faire
comme si l'extension était totalement inconnu, ce qui revient à ce que
l'application utilise le certificat sans implémenter l'extension, ce qui
est justement autorisé par le fait qu'elle soit non critique.

C'est en contradiction avec le §7 (là encore, à mon sens). Une application
reconnait ou ne reconnait pas une extension, mais cette reconnaissance ou
non ne doit pas dépendre d'un drapeau contenu dans cette extension. Dit
autrement, une application ne peut pas (comprendre: ne devrait pas)
choisir de traiter ou pas une extension selon que ça l'arrange ou pas...
Sinon, tu imagines ce que ça peut faire sur d'autres extensions, comme le
basicConstraints par exemple. D'ailleurs, la description de cette dernière
extension interdit à une application qui la reconnait de faire comme si
elle ne la reconnaissait pas si elle était déclarée non critique (je sais,
c'est tordu comme phrase). On a donc bien une différence de sémantique
pour le certificatePolicies en fonction du drapeau critique.

Par ailleurs, les RFC du PKIX sont un profile de la norme ANSI.

C'est dit où?

Ce qui signifie que le PKIX restreint l'ensemble de ce qui est autorisé
par la norme. Ce qui signifie que quand il y a apparement un conflit
entre les deux, lorsque les intructions du PKIX restreignent plus que ce
ne fait la norme, il ne s'agit pas réellement d'un problème, et les
implémentations conformes au PKIX peuvent rejeter des cas autorisés par
X509 (si on trouve un cas inverse, là c'est un défaut de PKIX).

Quand on compare la RFC et la norme sur certains points, on se dit qu'en
tant qu'implémenteur, on doit faire un choix, on ne peut pas être
totalement conforme aux deux. Et je trouve que les travaux de PKIX ne sont
pas suffisamment 'argumentés', il n'y a pas de cadre pour appuyer certains
choix, ce qui donne l'impression de quelque chose de mal ficelé.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Sur IE 4.0 comment faire pour poster un message dans plusieurs forums
et avec la réponse dans un seul? Je viens de réussir le contraire!
-+- RG in <http://neuneu.mine.nu> : Le crosspost pour les nuls -+-

Erwann ABALEA wrote:

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

Erwann ABALEA wrote:

Et une criticité, qui peut parfois influer sur la sémantique à accorder à
l'extension (par exemple le certificatePolicies, voir sa sémantique dans
la norme (pas la RFC3280, elle est borgne sur ce point), c'est "amusant").

[...]
Si l'extension est marquée comme critique, ceci indique alors que le

certificat sera utilisé uniquement pour les buts et conformément aux règles
impliquées par l'une des politiques de certificat indiquées. Les règles
d'une politique particulière peuvent exiger que le système utilisant des
certificats traite d'une manière particulière la valeur du qualificatif.

Si l'extension est marquée comme non critique, son utilisation ne limite
pas nécessairement l'utilisation du certificat aux politiques figurant dans
la liste. Un utilisateur de certificat peut toutefois exiger la présence
d'une politique particulière pour utiliser le certificat (voir article 10).
Les qualificatifs de politique peuvent être traités ou ignorés au choix de
l'utilisateur de certificat.
-----

Il ne s'agit pas ici du "support" ou non de l'extension, mais de savoir
comment on la traite, puisque même une application sachant traiter
correctement cette extension aura un comportement différent pour cette
extension selon que celle-ci est déclarée critique ou non.

Confère David Kemp exactement sur ces deux paragraphes, et aussi sur
"basic contraint", il devrait faire medium :
http://www.imc.org/ietf-pkix/old-archive-97/msg01552.html

[...]
Ce qui n'empèche qu'il reste plusieurs cas (CRLDP, key usage) où l'on
autorise les applications à ne pas prendre en compte les extension
non-critiques.

On voit donc bien qu'on a besoin d'un drapeau indiquant qu'on veut
renforcer les contrôles...

C'est ce qu'est le flag 'critical' par définition.

Mais ce n'est pas vraiment une sémantique différente, c'est plutôt faire
comme si l'extension était totalement inconnu, ce qui revient à ce que
l'application utilise le certificat sans implémenter l'extension, ce qui
est justement autorisé par le fait qu'elle soit non critique.

C'est en contradiction avec le §7 (là encore, à mon sens). Une application
reconnait ou ne reconnait pas une extension, mais cette reconnaissance ou
non ne doit pas dépendre d'un drapeau contenu dans cette extension. Dit
autrement, une application ne peut pas (comprendre: ne devrait pas)
choisir de traiter ou pas une extension selon que ça l'arrange ou pas...

Mais à partir du moment où l'extension n'est pas critique, l'émetteur du
certificat prend le risque d'une non-reconnaissance, c'est
l'interprétion par DK des deux paragaphes que tu cite sur
certificatePolicies.

Sinon, tu imagines ce que ça peut faire sur d'autres extensions, comme le
basicConstraints par exemple. D'ailleurs, la description de cette dernière
extension interdit à une application qui la reconnait de faire comme si
elle ne la reconnaissait pas si elle était déclarée non critique (je sais,
c'est tordu comme phrase).

La description se contente de rappeller la règle générale du paragraphe
7. Le cas de l'application qui ne traite cette extension est décrit par
la note 1 (si tu n'as pas vu l'extension/décide de ne pas la voir, le
certificate doit être être "end-entity").

On a donc bien une différence de sémantique
pour le certificatePolicies en fonction du drapeau critique.

Je n'ais jamais dit autre chose que ce que tu décris là, c'est à dire
que pour certaines extensions, les normes déconseillent très, très fort
d'ignorer une extention non critique, et que pour d'autres elles disent
que c'est acceptable.

Mais il n'y a jamais trois comportements différents 'pas présent',
'présent non critique', 'présent critique', il y a deux comportement, et
une license accordée pour certaines extensions d'adopter le comportement
'pas présent' pour le cas 'présent non critique', au lieu de
systématiquement gérer comme 'présent critique'.

Alors ensuite savoir si on appelle cela ou non une différence de
sémantique, c'est aussi utile que de choisir si la tomate est un légume
ou bien un fruit (botaniquement un fruit, culinairement un légume).

Par ailleurs, il y a un effort pour réduire ce genre de cas, et celui
par encore cité mais pourtant typique sur les "Extended key usage" a été
supprimé par la rfc 3280 par rapport à la rfc 2459 :

2459 :
"If the extension is flagged non-critical,[...]
It is an advisory field and does not imply that
usage of the key is restricted by the certification authority to the
purpose indicated."

3280 :
"If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. [...]
If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special keyPurposeID anyExtendedKeyUsage."

Tu vois d'ailleurs qu'ici a été trouvé une solution astucieuse pour
appliquer strictement la règle tout en gardant la souplesse nécessaire,
sans créer une extension de plus.

D'ailleurs, on devrait faire la même chose avec un anyPolicy :-)

Par ailleurs, les RFC du PKIX sont un profile de la norme ANSI.

C'est dit où?

Partout. Dans le titre des RFC concernée. Dans le charter.
Dans le premier paragraphe :
"This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
Revocation List (CRL) for use in the Internet."

Oui, la définition précise de ce qu'est un profile de X.509 n'est pas
partout, mais est évoqué par X.509 lui-même.

Quand on compare la RFC et la norme sur certains points, on se dit qu'en
tant qu'implémenteur, on doit faire un choix, on ne peut pas être
totalement conforme aux deux.

Si tu trouve un point où tu trouve que la RFC autorise quelquechose qui
est interdit par le X.509, n'hésite pas à le sortir !

Et je trouve que les travaux de PKIX ne sont
pas suffisamment 'argumentés', il n'y a pas de cadre pour appuyer certains
choix, ce qui donne l'impression de quelque chose de mal ficelé.

Je ne crois pas pas que le X.509 soit bien meilleur sur ce point de vue.

Erwann ABALEA wrote:

Le site http://oid.elibel.tm.fr offre à ce jour la description de
72657 OID, soit *19* fois plus que le site d'Alvestrand qui n'est
plus

mis à jour depuis longtemps, me semble-t-il. La base d'Harald
Alvestrand a été incluse dans notre site avec son accord (elle
contenait 3781 OID au moment de l'intégration) et quelques erreurs
détectées ont été corrigées.

Et cette intégration a eu lieu quand?

Pour être précis, aucune intégration n'est vraiment prévue. Harald
a donné son accord pour que les données contenues sur son site soient
réutilisées sur le nôtre.

Je vois maintenant des références à
elibel.tm.fr quand je parcours la base d'Alvestrand que je n'avais
pas

remarqué avant.

En effet, ma préférence aurait été que sa page principale "OID"
pointe sur notre site. Peut-être fera-t-il cela une fois que le
répertoire d'OID sera effectivement déplacé sur le site web de
l'UIT.

J'ai vu que tous les OID du SET y sont également. Par contre, je
n'ai pas

vu/compris comment ajouter des commentaires ou informations. Je suis
bigleux?

Pour le moment, il faut cliquer sur un lien dans le texte (en petits
caractères !) en bas de la page et un mail est produit. Prochainement,
une page va permettre de proposer plus facilement des modifications.
En revanche, pour ajouter la description d'un OID qui n'est pas encore
décrit dans le répertoire, il suffit d'utiliser l'un des moyens
décrits à :
http://asn1.elibel.tm.fr/oid/faq.htm#4

Il est prévu que ce répertoire d'OID migre sur le site de l'UIT
(et

acquiert un caractère plus officiel) avant la fin de cette
année.

C'est vrai que ça manquait. Un répertoire officiel, ça évite les
doublons

(2 OIDs pour un même 'objet' théorique).

Je doute que le répertoire évite réellement les doublons : c'est un
endroit unique où l'on peut trouver de l'information sur les OID, mais
ce n'est pas un système d'enregistrement qui assure "l'unicité
universelle". L'allocation de sous-arcs dans l'arbre est totalement
décentralisée et chaque niveau dans l'arbre est le seul a avoir la
responsabilité de l'allocation des arcs de niveau immédiatement
inférieur.
Par ailleurs, les doublons ne peuvent être réellement évités que si
chacun s'astreint à saisir ses OID dans la base et c'est bien loin
d'être le cas :(

de site officiel du groupe de travail. Mais ça semble être le
seul

site qui rassemble autant d'information sur la technologie ASN.1.

Il me reste à trouver un bon parseur XER, pour contenter à la fois
mes

collègues web-addicted qui ne jurent que par XML et ... ben
seulement moi,

qui préfère largement de l'ASN.1 bien formé et du binaire compact.
J'ai vu

qu'il y a aussi des ressources par chez vous sur ce sujet.

Les outils disponibles sont listés à :
http://asn1.elibel.tm.fr/en/links/#xml

Olivier Dubuisson