Le 14 septembre 2017 à 12:42, Wallace <wall...@morkitu.org> a écrit : > Quand une autorité émet un certificat illégitime elle se fait radier des > navigateurs pour la partie web et des certificats racines des OS. > > On a déjà vu arriver cela à des autorités payantes avec des gars qui je > suppose, savent la sanction qui arriverait s'ils développaient mal leurs > API ou parcours achat.
Alors, sauf cas particulier où l'AC appartient à un état qui l'utilise pour du MITM et autres activités pas très claires (c.f. l'Iran et gmail.com), ça ne se passe pas comme ça. Les cas de radiation des AC sont prises suites à des manquements *répétés* aux règles du CA/Browser forum ainsi qu'à l'absence de déclaration de ces incidents par l'AC aux navigateurs, ou en cas de réponses jugées non satisfaisantes aux questions de la communauté suite à ces incidents. D'ailleurs à peu près toutes les grosses AC ont au moins une fois émis un certificat qui n'aurait pas du l'être. Par exemple, pour la dernière AC révoquée (StartCom / WoSign), les fautes ont été commises de façon répétés et en quantités industrielles : https://wiki.mozilla.org/CA:WoSign_Issues Même après ça, pour avoir un peu suivi les discutions, les sanctions auraient pu êtres bien plus légères qu'une révocation si WoSign avait apportée des réponses satisfaisantes à la communauté. Malheureusement les réponses ont été manquantes ou contradictoires, et chaque réponse à soulevée encore plus de questions quand à la gestion de l'AC. Pour Mozilla / NSS, les discutions sont publiques et se passent sur le newsgroup mozilla.dev.security.policy. Y participent également la team Google Chrome ainsi quelques employés d'Apple. Bien que ça ne soit pas officiel, les décisions de l'équipe Google Chrome sont largement basées sur la conclusion de ses discutions publiques avec la communauté. En revanche, côté Microsoft et Apple, les décisions sont prises en interne. Là encore, malgré les lourdes fautes qui avaient été commises, il a été décidé de blacklister de façon très progressive les certificats StartCom plutôt que de façon sèche, car cette AC était énormément utilisée, étant une des seules à proposer des certificats gratuits avant l'arrivée de LE. > Letsencrypt aussi génial que c'est, permet de tester en illimité ou > presque le processus de validation. Je n'espère pas mais je pense > néanmoins que le risque que cela arrive est non nul, lorsque quelqu'un > trouvera une faille et émettra des certificats gmail.com et consorts. L'avantage de LE, c'est qu'il n'y a pas d'employés. Donc pas d'humains qui peuvent faire des erreurs de validation. Leur API est basée sur le protocole ACME qui est conçu par un workgroup de l'IETF, donc je te laisse imaginer les discutions interminables sur des points de détails. :) Alors après bien sûr, on est jamais à l'abris d'un bug dans la validation, mais c'est quand même compliqué étant donné que le code de la partie serveur se trouve sur GitHub, que le protocole a été discuté pendant des mois à l'IETF, et qu'il y a une infra de pré-prod qui permet à tous de tester les modifs avant leur passage en live. L'autre gros avantage de Let's Encrypt, c'est qu'il n'y a pas de top management qui ne comprend rien et veut juste vendre le plus de certificats possible quitte à contourner les règles. C'est un gros problème chez Symantec (avant le rachat de sa branche SSL par l'excellent DigiCert) et Comodo notamment, où les techs sont très compétents mais où le management est complètement à côté de la plaque. Mais ça ce n'est pas spécifique aux AC. ;) -- Jonathan Leroy. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
