Merci pour ta réponse, j'aime particulièrement ton point de vue sur CA transparency.
Juste quelques points :
en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ?
Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
TLSA tout seul sans DNSSEC est inutile.
Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.
Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.
Certificate Transparency corrige quoi au juste ?
Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».
L'idée derrière Certificate Transparency est de créer une base publique de tous les certificats émis existants.
Si l'utiliser pour détecter les conneries des CA peut être un premier cas d'utilisation évident.
L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.
Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.
Ça l'est. Et je n'ai jamais dit que j'aimais particulièrement cette solution. cf mon commentaires précédents sur les alternatives.
C'est DANE/DNSSEC que je n'aime pas pour tout un tas de raisons evidentes expliquées plus haut.
Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 1.
Merci pour ta réponse, j'aime particulièrement ton point de vue sur CA transparency.
Juste quelques points :
Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
TLSA tout seul sans DNSSEC est inutile.
Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.
Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.
L'idée derrière Certificate Transparency est de créer une base publique de tous les certificats émis existants.
Si l'utiliser pour détecter les conneries des CA peut être un premier cas d'utilisation évident.
L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.
Ça l'est. Et je n'ai jamais dit que j'aimais particulièrement cette solution. cf mon commentaires précédents sur les alternatives.
C'est DANE/DNSSEC que je n'aime pas pour tout un tas de raisons evidentes expliquées plus haut.
Nous sommes d'accord.
```