Certificat SSL

On Tue, 18 Jan 2005, Patrick Mevzek wrote:

Les AC ont de l'argent, non, au prix où elles vendent les
certificats....

C'est un beau raccourci. Ils ont des recettes et des dépenses. S'il y a
plus de recettes que de dépenses, il ont effectivement de l'argent, mais
je ne crois pas que ce soit le cas.

Les AC sont déficitaires selon vous (je parle des grosses style Verisign)
et vendent des certificats à perte ?

Qu'en savez-vous? ;)

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je crois que le meilleur moyen, c'est une signature qui contient
toutes les signatures et de virer les mauvaises avant envoi.
-+- Ivan in : Guide du Neuneu d'Usenet : Je signe donc je suis -+-

Deuxièmement, la norme X.509 fournit un schéma de validation de
certificat dans lequel est inscrit clairement qu'on doit avoir les CRL
des AC en question (peu importe le moyen, et le cas explicite où
^^^^^^^^^^^^^^^^^^^^

On invoque le saint-esprit ?

l'extension crlDistributionPoints n'existe pas est traité), ou un autre
moyen de vérifier une révocation (ceci pour dire que Microsoft ne
pouvait décemment pas écrire une validation propre et ignorer l'absence
de cette extension et l'absence de CRL dans son implémentation).

Peut-être. Mais ils n'étaient manifestement pas aidés par l'AC...

Enfin, quand en 2005 Microsoft ne sait toujours pas obtenir une CRL
correctement, on peut se poser la question "est-ce qu'ils auraient été
en mesure de traiter correctement une extension
crlDictributionPoints?"... J'ai ma réponse. ;)

Oui, tout façon vous partez du *postulat* que les AC ne font jamais
d'erreur et que quand elles en font ce n'est pas leur problème, puisque
c'est au client d'utiliser les CRLs (et dans un autre groupe vous dites
le contraire: il ne faut pas charger *certaines* CRLs)

J'espère en tout cas que Verisign vous paye bien...

Donc c'est la faute du développeur que d'utiliser un certificat qui ne
mentionne pas où trouver la CRL ?

Oui. Clairement.

C'est votre interprétation.

Le patch disponible ne fait que fournir une CRL locale contenant les
certificats incriminés (d'après l'auteur du bouquin sus-nommé
toujours), ce qui n'est en rien une solution à long terme.

Lis la norme ou la RFC3280, elles parlent explicitement de CRL gardée en
cache local. Bizarre, non, ça ressemble à ce que tu décris...

Et alors ?
Je n'ai pas dit que ce n'est pas une solution, je dis juste que ce n'est pas
une solution à long terme. C'est un patch rapide pour révoquer des
certificats quand l'implémentation ne gère pas l'usage d'une CRL distante.

Il faudrait donc peut-être prendre un point de vue plus nuancer et
arrêter de penser que tout est de la faute de l'utilisateur final qui
ne fait pas les choses comme il faut.

Mme Michu n'y est pour rien si Microsoft ne sait pas faire son travail,
c'est vrai, j'ai très certainement exagéré en lui jetant la pierre.
Aujourd'hui, je dirais que les torts sont partagés.

Ouf... on progresse... peut-être que d'ici 40 autres posts on arrivera
enfin à la conclusion que l'AC partage aussi une partie des torts dans
bien des cas. Mais je n'irai pas jusque là (en terme de posts), vu les
partis pris initiaux, ca ne m'intéresse pas d'essayer d'argumenter.

--
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>

Schneier dit pareil, même si Microsoft dit le contraire, mais au final
ils rejettent bien la faute sur l'AC. Cf
http://www.amug.org/~glguerin/opinion/revocation.html pour tous les
détails.

J'ai l'impression que tu n'as pas lu la page en détail,

C'est vrai, dès le départ:
``The fundamental error is that VeriSign issued those certificates to
somebody other than Microsoft''
qu'on pourrait traduire par:
l'erreur fondamentale/initiale provient de VeriSign qui a fourni deux
certificats à une entité autre que Microsoft.

Les ACs ne font jamais d'erreur vous disiez ?

la conclusion est contraire à ce que tu affirmes,

Des 4 méthodes disponibles pour récupérer une CRL, Verisign n'en utilise
que 2, les 2 les moins automatisables justement.

Je cite:
``Microsoft's CryptoAPI, as shipped by Microsoft, only handles CRLs when
they are listed in certificates that have the CRL Distribution Point
extension of RFC 2459.''

Donc Microsoft gère les CRLs, quand elles sont distribuées d'une certaine
façon. C'est un choix, c'est permis.
Verisign ne les distribue pas selon ce mécanisme. C'est un choix, c'est
permis (puis que le mécanisme en question est optionnel, mais recommandé).

Pour vous, c'est la faute de Microsoft.
Pour moi, les torts sont partagés, l'AC peut faire un effort pour assurer
*au maximum* la publication des CRLs, dons utiliser les 4 méthodes
disponibles. Le tort de Microsoft est de ne pas essayer tous les moyens,
oui, on est d'accord.
Les choses iraient beaucoup mieux si *chacun* faisait un effort plutôt
que de rejeter l'erreur sur l'autre.
C'est ainsi, je pense, que les choses progressent....

La faute en revient à Microsoft, clairement.

La faute en revient à un manque de coordination entre deux entités,
aucune des deux n'est innocente dans l'affaire.

--
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>

Le Wed, 19 Jan 2005 12:45:09 +0000, Patrick Mevzek a écrit :

C'est vrai, dès le départ:
``The fundamental error is that VeriSign issued those certificates to
somebody other than Microsoft''

Cette erreur est claire. VeriSign a fauté là-dessus et ce n'est même
pas sujet à discussion. Mais je n'ai pas l'impression que ce soit le fond
de la discussion qui porte plutôt sur les services que doit assurer une
AC à destination de ses clients, et in fine des utilisateurs lambda que
nous sommes.

Je cite:
``Microsoft's CryptoAPI, as shipped by Microsoft, only handles CRLs when
they are listed in certificates that have the CRL Distribution Point
extension of RFC 2459.''
Donc Microsoft gère les CRLs, quand elles sont distribuées d'une
certaine façon. C'est un choix, c'est permis. Verisign ne les distribue
pas selon ce mécanisme. C'est un choix, c'est permis (puis que le
mécanisme en question est optionnel, mais recommandé).

S'agirait-il d'une AC quelconque, utilisée dans un contexte plus
générique, c'est à dire sans lien particulier avec l'éditeur, voulant se
faire publier dans un produit que je serais de ton avis. En effet, en tant
qu'AC, si je veux me faire inclure dans un logiciel, je peux effectivement
me mettre d'accord avec l'éditeur du produit pour fournir un mécanisme
conforme à ce qu'il implémente, mécanisme qui peut résulter d'un
commun accord. OK.

Mais parallèlement, l'éditeur devrait aussi vérifier que c'est le cas,
et donc ne pas m'inclure si ce mécanisme ne peut être mis en place
(i.e. pas d'accord), puisque dans le cas présent, la non récupération
des CRLs pose un problème de sécurité évident et central. Selon toute
logique, et sur la base de ces constatations, Microsoft ne devrait pas
inclure les AC Verisign dans ses produits. De même, un warning devrait
monter à l'importation d'une AC Verisign pour dire à l'utilisateur que
le système ne sait pas récupérer les CRL automatiquement sur ces
certificats, bref lui dire que c'est mal. Mais franchement, sur toutes
les AC fournies en standard sur un OS Windows, combien ont un CRL
Distribution Point de publié ? Question : est-il plus intéressant pour
Microsoft d'obliger les AC à intégrer un CRL Distribution Point quitte
à refuser de les intégrer ou de ne pas se soucier ce ce point et de
procéder quand même ? Personnellement, j'ai une idée sur la réponse ;)

Or, dans le cas qui nous intéresse, il ne s'agit pas de ça. Il s'agit
d'un éditeur (Microsoft) qui, pour signer le code qu'il distribue,
_décide_ d'acheter un service auprès d'une AC (Verisign) qu'il _choisit_
parmi toutes les AC disponibles sur le marché. Et ce même éditeur
(Microsoft) _décide_ de ne pas implémenter la méthode de récupération
des CRL proposée par le prestataire qu'il a _choisi_. Dans ce cas de
figure, je suis plutôt de l'avis de Erwann, la faute est entièrement
pour Microsoft, dans son choix de souscrire à un service dont il ne
supporte pas une fonctionnalité indispensable. Soit Microsoft assume
_son_ choix d'AC et implémente la fonctionnalité, soit il persiste dans
_son_ choix de ne pas l'implémenter, mais dans ce cas, il choisit une
autre AC. Point.

Aujourd'hui, les choix de Microsoft ont conduit à une situation
simplissime : un OS Windows ne peut pas récupérer les CRLs de
l'AC qui sert à signer pour signer le code qu'ils distribuent. C'est
aussi simple que ça à mon sens. Ce n'est clairement pas normal, et ce
n'est amha ni de la faute de l'AC, ni de la faute de l'utilisateur (sinon
son choix d'utiliser Windows).

Alors OK, dans l'absolu, ça semble tellement simple (et encore) d'ajouter
ce champ dans les certificats que ça semble délirant qu'il n'y soit pas.
Mais d'un autre côté, si les clients exigeaient qu'il y soit, tout
conscients qu'ils sont de son importance (humm humm), et se tiennent à ce
choix (quitte à refuser de choisir un prestataire qui ne le fournit pas),
la loi du marché ferait son office et les AC le collerait pour ne pas
perdre trop de clients. Corollaire, si un client aussi gros Microsoft
exigeait des certificats avec un CRL Distribution Point, Verisign les lui
fournirait, papier cadeau offert, rien que pour ne pas les voir choisir un
autre prestataire.

Cet avis reste cependant personnel...


--
BOFH excuse #58:

high pressure system failure

Or, dans le cas qui nous intéresse, il ne s'agit pas de ça. Il s'agit
d'un éditeur (Microsoft) qui, pour signer le code qu'il distribue,
_décide_ d'acheter un service auprès d'une AC (Verisign) qu'il _choisit_
parmi toutes les AC disponibles sur le marché.

Il y a plusieurs autorités dans Windows, je pense, donc Microsoft n'a pas
choisi que Verisign, mais Verisign et quelques autres.
Enfin j'imagine.
Ils ont développé leur truc dans leur coin, pour toutes les AC, sans
vérifier que toutes les AC sont ``compatibles'' (au niveau publication
des CRLs) avec ce qu'ils ont fait.

Aujourd'hui, les choix de Microsoft ont conduit à une situation
simplissime : un OS Windows ne peut pas récupérer les CRLs de l'AC qui
sert à signer pour signer le code qu'ils distribuent. C'est aussi simple
que ça à mon sens. Ce n'est clairement pas normal, et ce n'est amha ni
de la faute de l'AC, ni de la faute de l'utilisateur (sinon son choix
d'utiliser Windows).

Même si ce n'est pas la faute de l'AC au sens strict, rien ne l'empêche
de participer à la résolution du problème. Ok, rien ne l'y oblige non
plus.

soit pas. Mais d'un autre côté, si les clients exigeaient qu'il y soit,

Demander à quelqu'un qui veut juste *utiliser* son ordinateur de
comprendre ce qu'est une CRL pourquoi c'est bien et pourquoi il doit
vérifier que son logiciel s'en serve, c'est illusoire.
Eduquer les utilisateurs, oui, car un ordinateur n'est pas une théière.
Estimer qu'ils doivent avoir potassés tous les RFCs & co avant de faire le
moindre choix, est illusoire.
Et même, selon moi, incorrect, car il ne faut pas tout rejeter sur
l'utilisateur, c'est aussi aux ``fournisseurs'' de faire les choses le
plus simple possible mais pas trop simple. Difficile, ok.

collerait pour ne pas perdre trop de clients. Corollaire, si un client
aussi gros Microsoft exigeait des certificats avec un CRL Distribution
Point, Verisign les lui fournirait, papier cadeau offert, rien que pour
ne pas les voir choisir un autre prestataire.

Cf plus haut, je ne pense pas qu'il y ait exclusivité dans le choix.
Chacun campe sur ses positions, chacun estimant avoir fait son travail.
C'est pour cela que je suis partisan, dans tous les cas similaires, d'un
effort *concerté* où chacun fait un pas dans le sens de l'autre.
Cela me parait plus utile que de pointer les gens du doigt (et pour le
coup, je ne suis ni fervent défenseur de Verisign ni de Microsoft, bien
au contraire), surtout dans des cas de figure où il n'y a pas de
standards strict définitifs sans options et/ou de structure à part de
``réglementation''/contrôle.

Voilà, voilà.

--
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 Wed, 19 Jan 2005, Patrick Mevzek wrote:

Schneier dit pareil, même si Microsoft dit le contraire, mais au final
ils rejettent bien la faute sur l'AC. Cf
http://www.amug.org/~glguerin/opinion/revocation.html pour tous les
détails.

J'ai l'impression que tu n'as pas lu la page en détail,

C'est vrai, dès le départ:
``The fundamental error is that VeriSign issued those certificates to
somebody other than Microsoft''
qu'on pourrait traduire par:
l'erreur fondamentale/initiale provient de VeriSign qui a fourni deux
certificats à une entité autre que Microsoft.

Exact. C'est une bonne traduction, et je suis d'accord avec cette partie,
qui ne représente qu'un tout petit bout de cette longue page... Le reste
est majoritairement des arguments contre Microsoft.

Les ACs ne font jamais d'erreur vous disiez ?

Vous devez confondre.
http://groups.google.com/groups?threadm=Pine.LNX.4.58.0501130849370.6765%40shining.seclogd.org
J'admets clairement que VeriSign a fait une erreur. Je n'ai aucun problème
là-dessus, et je serais bien con pour ne pas l'admettre.
D'ailleurs, c'est VeriSign qui s'est rendu compte de cette erreur et l'a
signalé, personne d'autre. Contrairement à ce que vous affirmez dans
http://groups.google.com/groups?threadm=pan.2005.01.13.14.03.32.323005.18513%40nospam.dotandco.com
une AC a tout intérêt à signaler de telles erreurs. Une AC vend de la
confiance, ne pas dévoiler ces erreurs ne peut *que* lui nuire.

la conclusion est contraire à ce que tu affirmes,

Des 4 méthodes disponibles pour récupérer une CRL, Verisign n'en utilise
que 2, les 2 les moins automatisables justement.

C'est vous qui le dites. Quand je demande à ce que mon AC soit référencée
par Microsoft, il est très simple pour Microsoft de demander une URL où
télécharger la CRL correspondante et prévoir le mécanisme adéquat. C'est
automatisable.

Je cite:
``Microsoft's CryptoAPI, as shipped by Microsoft, only handles CRLs when
they are listed in certificates that have the CRL Distribution Point
extension of RFC 2459.''

Vous oubliez quelques détails:
- la RFC n'est *pas* une norme. Certaines RFC sont bien foutues pour
qu'elles soient considérées comme des standard, la 2459 n'en fait pas
partie. Je ne détaillerai pas ici les cochonneries de cette RFC, qui
arrive à la fois à invalider d'autres normes et RFC sur lesquelles elle
s'appuie, et à ne pas être en conformité avec le marché,
- la norme X.509 existe depuis 1988, la v3 depuis 1997, et l'extension
crlDistributionPoints n'a été normalisée qu'en 2000 (la RFC2459 date
de 1999, donc on pourrait dire que cette extension a été 'standardisée'
cette année là). Question: comment faisait-on avant cela? Ca n'était
pas prévu par la norme? Lisez-la, vous y trouverez la réponse.

Donc Microsoft gère les CRLs, quand elles sont distribuées d'une certaine
façon. C'est un choix, c'est permis.

Chapitre et verset? La lecture de la norme et de la RFC3280 vous montrera
le contraire.

Verisign ne les distribue pas selon ce mécanisme. C'est un choix, c'est
permis (puis que le mécanisme en question est optionnel, mais recommandé).

Non, il n'est pas recommandé, et manifestement vous ne lisez pas assez les
normes et RFC pour écrire ceci (et l'auteur de cette page web non plus).
Note: une norme ou une RFC n'est pas écrite en français ou anglais, mais
en langage 'norme'. C'est presque pareil, mais il n'y a pas d'ambiguîté
dans les termes employés (ou bien la norme est caduque).
Dans la RFC2459, le paragraphe repris sur la page web en question dit:
-----
4.2.1.14 CRL Distribution Points

The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile
recommends support for this extension by CAs and applications.
[...]
-----

On note l'emploi des majuscules pour renvoyer aux définitions de la
RFC2119, et on note que cette RFC 'recommends' (et non 'RECOMMENDS') que
cette extension soit *supportée* (et non *utilisée*).

Plus loin, on trouve ceci:
-----
4.2 Standard Certificate Extensions

[...] Each extension in a
certificate may be designated as critical or non-critical. A
certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension may be ignored if it is not recognized.
[...]
Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions.
[...]
Support for the remaining extensions is OPTIONAL.
-----

Ici, il est clairement stipulé que le *support* (et non l'utilisation)
d'autres extensions que celles listées est 'OPTIONAL', terme écrit en
majuscules dont la définition est donnée par la RFC2119.

Maintenant, faites l'effort de lire attentivement les RFC2459 et 3280 pour
comprendre comment doit être vérifié un certificat. Pour la RFC2459, le
travail est simple: il n'y a pas de schéma fourni, et rien n'indique non
plus que l'on *doit* utiliser l'extension crlDP uniquement. Pour la
RFC3280, l'essence se trouve en 6.3, et principalement en 6.3.3. Et le cas
explicite où l'extension crlDP n'est pas renseignée est traité et ne peut
pas être ignoré.

Pour vous, c'est la faute de Microsoft.
Pour moi, les torts sont partagés, l'AC peut faire un effort pour assurer
*au maximum* la publication des CRLs, dons utiliser les 4 méthodes
disponibles. Le tort de Microsoft est de ne pas essayer tous les moyens,
oui, on est d'accord.

Non. Le tort de Microsoft est de ne pas faire son travail. Une PKI, c'est
techniquement maîtrisé, le plus gros du travail est de l'organisationnel.

Techniquement, il n'y a qu'à suivre bêtement la norme pour faire le
travail correctement. C'est du travail de pisseur de code, l'analyse est
déjà faite (et bien faite).

Si un des acteurs du marché ne joue pas le jeu et ne respecte pas les
règles, il se fait sanctionner, et ça n'est pas aux autres (qui ont leur
lot d'effort à fournir que vous semblez ignorer) de palier ses manques.

Les choses iraient beaucoup mieux si *chacun* faisait un effort plutôt
que de rejeter l'erreur sur l'autre.
C'est ainsi, je pense, que les choses progressent....

Vous considérez que les AC ne font pas d'effort, ou bien que la quantité
d'effort engagée de part et d'autre est inégale. Probablement parce que
vous ne voyez qu'une des deux parties.

Vous ne connaissez manifestement pas assez les rouages de la PKI X.509. Je
ne vous jette pas la pierre pour cela, c'est normal, c'est complexe, c'est
un métier (le mien). Mais vous entêter dans vos certitudes sans vous
renseigner et lire attentivement les documents librement disponibles,
c'est idiot. Pour vous, puisque vous n'apprendrez rien comme cela.

La norme est payante, les RFC sont gratuites, mais on peut trouver
gratuitement et légalement des drafts de la norme X.509 (et autres normes
associées) sur les sites des gentils contributeurs (Bull par exemple:
ftp://ftp.bull.com/pub/OSIdirectory, mais il semble qu'ils aient supprimé
les documents intéressants récemment, il ne reste que les DR. Je ne sais
pas si je peux les fournir).


Personnellement, j'arrête le thread ici, j'estime avoir:
- donné suffisamment d'informations pour permetter à quiconque étant
motivé de se faire une opinion étayée
- assez emmerdé de monde sur un sujet qui ne les intéresse pas forcément.
(d'ailleurs, on n'entend plus personne ici, il ne reste plus que nous
deux? ;)

Cordialement. (pour de vrai).

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Il n'est pas question de modération !!!
Les gens ont à se prononcer sur les caractéristiques d'une
robot-modération
-+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-

Le Wed, 19 Jan 2005 15:36:24 +0000, Patrick Mevzek a écrit :

Il y a plusieurs autorités dans Windows, je pense, donc Microsoft n'a pas
choisi que Verisign, mais Verisign et quelques autres.

Tu n'as pas compris (ou lu) ce que je viens d'écrire.

Il y a deux choses bien distinctes. La première, c'est le container d'AC
de l'OS. Ce container est là pour enregistrer des AC qui permettront de
valider les certificats présentés blablabla. L'éditeur y place des AC,
selon un modus operandi que je ne connais pas. Dans ce cas là, l'éditeur
est un intermédiaire fournissant un service.

La seconde chose, c'est la signature par l'éditeur de son code avec un
certificat qu'il a acheté à une AC. Il devient donc client de' l'AC, et
à ce titre là, la choisit.

Or il se trouve que Microsoft, en tant qu'éditeur d'OS, joue sur les deux
tableaux. Il est à la fois fournisseur d'une CryptoAPI, incluant de
manière "indépendante" des AC reconnues, et à la fois client final d'une
AC pour des besoins propres. Et c'est précisément de ces besoins propres
dont on discute.

soit pas. Mais d'un autre côté, si les clients exigeaient qu'il y
soit,
Demander à quelqu'un qui veut juste *utiliser* son ordinateur de

comprendre ce qu'est une CRL pourquoi c'est bien et pourquoi il doit
vérifier que son logiciel s'en serve, c'est illusoire.

Sauf que là, quand je te parle de client, je te parle de client de l'AC.
Or ici, le client de l'AC, ce n'est pas toi, moi ou Mme Michu, c'est
Microsoft, qui a choisit d'acheter des certificats à Verisign pour
satisfaire un besoin. C'est donc à lui d'apprécier les services rendus
par Verisign pour assurer ce besoin, pas à toi, moi ou Mme Michu. Nous,
on utilise l'OS et on attend de l'éditeur un service, à savoir que son
système soit capable de vérifier le code qu'on lui fournit, et donc
d'avoir les certificats qui vont bien, éventuellement les mettre à jour
et savoir récupérer les CRLs automatiquement, parce que justement, on
n'en a rien à battre de savoir ce qu'est et comment marche une CRL.

Est-ce que service est rendu ? Non. Pourquoi ? Parce que pour assurer ce
besoin, Microsoft au lieu de choisir une AC qui lui fournirait des
certificats complètement exploitables par son système (sur lesquels ils
vont être utilisés) comme on s'y attend, va aller choisir parmi toutes
les AC du monde, une AC qui fournit des certificats pour lesquels le
système ne sait pas récupérer la CRL automatiquement.

Analogie tirée par les cheveux. Suppose que je sois un commerçant en
ligne qui se vante de proposer paiement par Visa et Amex, mais que j'ai
souscrit comme seul service de paiement un service qui ne supporte que
Visa. Si tu ne peux pas payer avec ton Amex, c'est de ma faute ou celle du
service de paiement en ligne que j'utilise ? De la mienne évidemment,
puisque si je veux accepter les règlement en Amex, il me faut souscrire
un service adapté, soit en choisissant un fournisseur qui me permette
les deux type de paiement (cf. choisir la bonne AC pour le service), soit
choisir un prestataire supplémentaire qui fournisse le service manquant
(cf. implémenter le truc qui va bien pour récupérer les CRLs Verisign).
That's it. À la fin, c'est toi, client final, que ça fait chier, mais
parce que moi, intermédiaire, n'ait pas choisit mon "sous-traitant" comme
j'aurais dû le faire.

Prenons un autre exemple. Va sur https://www.microsoft.com/. Le certificat
présenté descend de CyberTrust, et le certificat correspond n'a pas de
CRL Distribution Point (en tout cas celui que vois dans Mozilla). Donc IE,
d'après le document cité en référence précédemment, n'est pas capable de
savoir si le premier certificat Microsoft de la liste, à savoir le
Microsoft Internet Authority n'a pas été révoqué, puisqu'il ne saura
pas récupérer la CRL CyberTrust. Est-ce de la faute de CyberTrust de ne
pas produire cette information facultative ? Ou celle de Microsoft qui
fournit des outils incapables de faire cette vérification alors qu'ils le
devraient ?

Cf plus haut, je ne pense pas qu'il y ait exclusivité dans le choix.

Exclusivité dans le choix de quoi ? Dans le choix de l'AC ? Non, c'est
justement mon propos. Microsoft pouvait choisir une autre AC, qui
fournisse un CRL Distribution Point. Dans le choix des méthodes de
récupération des CRLs ? Si on envisage la chose comme une collaboration
entre Verisign et Microsoft, non plus, ils peuvent se mettre d'accord.
Mais dans l'optique d'une relation client/fournisseur, c'est moins clair.
Lorsqu'il souscrit un service, un client en accepte les conditions, même
si ce n'est pas lui qui en subisse les conséquences directes. Microsoft
aurait dû choisir son AC selon ce que supportait la plate-forme
destiée à utiliser ces certificats (i.e. Windows), ou contourner le
problème soit en implémentant le bout de code qui manque (Well-known
URL), soit en exigeant de Verisign qu'il lui fournisse des certificats
avec CRL Distribution Point.


--
BOFH excuse #30:

positron router malfunction

On Wed, 19 Jan 2005, Patrick Mevzek wrote:

Deuxièmement, la norme X.509 fournit un schéma de validation de
certificat dans lequel est inscrit clairement qu'on doit avoir les CRL
des AC en question (peu importe le moyen, et le cas explicite où
^^^^^^^^^^^^^^^^^^^^

On invoque le saint-esprit ?

Non. On se débrouille, il y a d'autres moyens, on peut raisonnablement
s'entendre quand on s'appelle Microsoft et VeriSign...

J'espère en tout cas que Verisign vous paye bien...

Hint: je ne suis pas payé par VeriSign, mais je suis effectivement bien
payé.

[... je note que vous avez coupé la partie technique sans argumenter ...]

Mme Michu n'y est pour rien si Microsoft ne sait pas faire son travail,
c'est vrai, j'ai très certainement exagéré en lui jetant la pierre.
Aujourd'hui, je dirais que les torts sont partagés.

Ouf... on progresse... peut-être que d'ici 40 autres posts on arrivera
enfin à la conclusion que l'AC partage aussi une partie des torts dans
bien des cas. Mais je n'irai pas jusque là (en terme de posts), vu les
partis pris initiaux, ca ne m'intéresse pas d'essayer d'argumenter.

Tu as du retard, j'ai déjà admis que l'AC (VeriSign ici présente) avait
fauté, c'est évident. Je ne peux donc pas partir du postulat qu'une AC ne
fait jamais d'erreur. C'est à toi d'admettre que dans le monde réel, c'est
à chacun d'assumer son rôle:
- l'ISO pour analyser un besoin, proposer une solution et l'édicter en
tant que règle
- les AC pour faire les vérifications nécessaires, mettre en place des
solutions matérielles, des procédures, des audits internes et externes
(les procédures incluent également les erreurs liées à la vérification,
de sorte qu'une erreur peut être corrigée)
- les implémenteurs de logiciels (tel Microsoft) pour respecter les
règles énoncées par l'ISO et vérifier les certificats selon les règles
du bon usage.

VeriSign a fauté, a détecté son erreur; l'a signalée publiquement, et l'a
corrigée. Microsoft n'a jamais fait son travail correctement, depuis le
début. Et vous voulez faire croire que les torts sont partagés? Vous vivez
où? Renseignez-vous. Sérieusement.

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

Les ACs ne font jamais d'erreur vous disiez ?

Vous devez confondre.
http://groups.google.com/groups?threadm=Pine.LNX.4.58.0501130849370.6765%40shining.seclogd.org

Vérifiez le sens de l'expression
``c'est l'exception qui confirme la règle''
que vous employez.

D'ailleurs, c'est VeriSign qui s'est rendu compte de cette erreur et l'a
signalé, personne d'autre. Contrairement à ce que vous affirmez dans
http://groups.google.com/groups?threadm=pan.2005.01.13.14.03.32.323005.18513%40nospam.dotandco.com
une AC a tout intérêt à signaler de telles erreurs. Une AC vend de la
confiance, ne pas dévoiler ces erreurs ne peut *que* lui nuire.

L'AC a tout intérêt à générer les CRLs qui vont bien mais n'a aucun
intérêt à faire un communiqué de presse comme quoi ils ont délivré un
mauvais certificat.

D'ailleurs sur
http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx
je peux lire:
``In mid-March 2001, VeriSign, Inc., advised Microsoft that...''
Donc Verisign a prévenu son client, Microsoft qu'elle s'était plantée.
C'est loin d'être une annonce publique...

Je cite:
``Microsoft's CryptoAPI, as shipped by Microsoft, only handles CRLs
when they are listed in certificates that have the CRL Distribution
Point extension of RFC 2459.''

Vous oubliez quelques détails:
- la RFC n'est *pas* une norme.

Où ai-je dit le contraire ?

- la norme X.509 existe depuis 1988, la v3 depuis 1997, et l'extension
crlDistributionPoints n'a été normalisée qu'en 2000 (la RFC2459 date
de 1999, donc on pourrait dire que cette extension a été
'standardisée' cette année là). Question: comment faisait-on avant
cela? Ca n'était pas prévu par la norme? Lisez-la, vous y trouverez
la réponse.

Donc Microsoft gère les CRLs, quand elles sont distribuées d'une
certaine façon. C'est un choix, c'est permis.

Chapitre et verset? La lecture de la norme et de la RFC3280 vous
montrera le contraire.

Vous qui êtes très à cheval sur les dates (§ plus haut), elle date de
quand cette dernière RFC par rapport à des événements de début 2001 ?

-----
4.2.1.14 CRL Distribution Points

The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile
recommends support for this extension by CAs and applications.
[...]
-----

Il est bien écrit recommandé, oui ou non ?

On note l'emploi des majuscules pour renvoyer aux définitions de la
RFC2119, et on note que cette RFC 'recommends' (et non 'RECOMMENDS') que
cette extension soit *supportée* (et non *utilisée*).

Elle le recommande, donc on bien d'accord.
RECOMMENDS n'est d'ailleurs pas défini dans le RFC2119, vous mélangez
avec RECOMMENDED, autant être rigoureux jusqu'au bout...

Maintenant, faites l'effort de lire attentivement les RFC2459 et 3280
pour comprendre comment doit être vérifié un certificat. Pour la

Vous parlez d'un document postérieur au problème.
Vous ne pensez pas qu'il y a un léger souci ?

Techniquement, il n'y a qu'à suivre bêtement la norme pour faire le
travail correctement. C'est du travail de pisseur de code, l'analyse est
déjà faite (et bien faite).

C'est marrant, plus haut vous dites qu'au moins un RFC est mal foutu.
Donc l'analyse ne doit pas être si bien faite que ca, et le travail ne se
borne pas, ici comme ailleurs aussi, à transcrire les RFCs, il faut
parfois les ``interpréter'', c'est bien pour cela qu'il y a des problèmes
d'interopérabilité, sans compter ceux qui violent directement les
recommandations.

Vous ne connaissez manifestement pas assez les rouages de la PKI X.509.

Bon je crois qu'il vaut mieux arrêter là, parce que je refuse de
participer à des discussions où l'on essaye systématiquement de faire
passer l'autre pour un crétin stupide qui n'y connait rien. Ce n'est pas
ma façon de participer à une discussion, désolé.

Bonne continuation tout de même.

--
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>

Lorsqu'il souscrit un service, un client en accepte les
conditions, même si ce n'est pas lui qui en subisse les conséquences
directes. Microsoft aurait dû choisir son AC selon ce que supportait la
plate-forme destiée à utiliser ces certificats (i.e. Windows), ou
contourner le problème soit en implémentant le bout de code qui manque
(Well-known URL), soit en exigeant de Verisign qu'il lui fournisse des
certificats avec CRL Distribution Point.

Je suis d'accord avec tout ce qui précède. Le choix était peut-être tout
de même un peu restreint, car il ne devait pas y avoir des centaines d'AC
disponibles pour gérer la signature du code, surtout si on veut assurer
une compatibilité aussi grande que possible, ca oblige à retomber sur les
AC ``historiques'' je pense.

Mais, si choix réel il y avait effectivement, oui le choix fut mauvais,
probablement que l'un n'a jamais imaginé que l'autre pourrait faire
une aussi grosse bourde l'impactant directement :-)
(oui, c'est une mauvaise hypothèse de travail, on est d'accord, mais tout
le monde fait des raccourcis, après ils sont heureux ou malheureux).

--
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>