En décembre 2011, le CA/Browser Forum, composé de représentants des principales autorités de certification telles que Symantec, Comodo, GoDaddy et DigiCert, ainsi que de fournisseurs de navigateurs tels que Microsoft, Apple, Mozilla et Opera, a publié un document intitulé "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates" (Exigences de base pour l'émission et la gestion de certificats de confiance publics). Ce document présente un ensemble de normes minimales convenues pour les vendeurs de certificats SSL/TLS .
L'une de ces normes prévoit essentiellement l'élimination des certificats à clé publique RSA de 1024 bits d'ici à la fin de 2013 : tout certificat à clé RSA, même les certificats d'entités finales ("abonnés"), qui expirent après le 31 décembre 2013, doivent avoir une clé d'au moins 2048 bits. C'est une grande nouvelle dans certains milieux ; un certain nombre de fournisseurs de certificats publics ont dû modifier leurs procédures et, plus important encore, commencer à faire migrer leurs clients vers des certificats de 2048 bits. Nombre d'entre eux ont entamé ce processus il y a déjà un certain temps.
Mais cela a également suscité des inquiétudes parmi les organisations qui exploitent leur propre site PKI... l'automne dernier, Microsoft a publié une mise à jour qui a invalidé tout certificat avec une clé RSA de 512 bits ou moins ... une mesure similaire est-elle prévue pour les certificats de 1024 bits ?
Dans de nombreux cas, ces organisations sont incapables de se débarrasser de tailles de clés plus petites, en raison des limitations de l'ancien site hardware que leur PKI doit prendre en charge. En tant qu'implémenteurs de PKI , l'équipe de Certified Security Solutions (CSS) PKI doit souvent renoncer à ses choix d'algorithmes préférés en raison de ce type de limitations. Bien qu'il soit extrêmement important pour les organisations de disposer d'un plan de migration pour abandonner les certificats de 1024 bits dans leur environnement, un blocage général des certificats de 1024 bits aujourd'hui serait catastrophique dans de nombreux cas.
Jusqu'à présent, je pense que nous ne risquons rien. Le forum CA/Browser indique clairement que ses lignes directrices ne s'appliquent qu'aux autorités de certification de confiance. Voici ce que l'on peut lire dans les premiers paragraphes : "Ces exigences ne concernent pas l'émission ou la gestion de certificats par des entreprises qui exploitent leur propre infrastructure de clés publiques à des fins internes uniquement, et pour lesquelles le certificat racine n'est pas distribué par un fournisseur d'applications Software ." J'ai interrogé divers contacts de Microsoft et je n'ai entendu parler d'aucun projet visant à bloquer purement et simplement les certificats de 1024 bits... pour l'instant.
Bien sûr, c'est toujours une très bonne idée de commencer à migrer les certificats de 1024 bits hors de l'environnement du mieux que vous pouvez. Si vous disposez d'un site PKI basé sur Microsoft (AD CS) et qu'il est très utilisé, il y a de fortes chances que vous en ayez, étant donné que de nombreux modèles de certificats Microsoft par défaut ont une taille de clé minimale de 1024.
Un bon début consiste à dresser l'inventaire des certificats de 1024 bits que vous utilisez. Vous pouvez le faire à partir de la console de gestion de l'autorité de certification, en utilisant un filtre ("View->Filter..." à partir de la console de gestion). L'exemple ci-dessous montre comment afficher uniquement les certificats dont la taille de clé est inférieure ou égale à 1024 bits :
Une fois que vous disposez d'un inventaire, vous pouvez commencer à déterminer à quoi servent vos certificats 1024 bits et à quelles machines ou à quels appareils ils sont délivrés. Si les systèmes en question prennent en charge RSA 2048, la migration devrait être relativement facile. Dans le cas contraire, une planification plus poussée de la migration peut s'avérer nécessaire. Toutefois, en réduisant l'étendue du problème au strict minimum, il devrait être plus facile de développer des solutions de contournement, si et quand un "blocage" de 1024 bits deviendra une réalité.
