Résumé

  • Le profil de la RFC 5280 exigeait déjà keyUsage et cRLSign pour une clé signant des CRL, mais son algorithme ne demandait de vérifier le bit que si l’extension était présente.
  • La RFC 10007 impose, pour un certificat v3, deux constats distincts : l’extension existe et le bit cRLSign est activé. Un nom concordant, une chaîne valide et une bonne signature ne remplacent pas ce mandat.
  • Un reçu exploitable conserve séparément version et identité de la clé, présence de l’extension, portée et fraîcheur de la CRL, chaîne, signature, résultat de révocation et exception ancienne.

Une signature numérique répond à une question remarquable : les octets reçus ont-ils été signés par la clé privée correspondant à cette clé publique ? Elle ne répond pas à toutes les questions que l’organisation pose ensuite.

La clé était-elle certifiée pour signer des listes de révocation ? Le certificat choisi était-il celui que le point de distribution désignait ? La liste était-elle fraîche et couvrait-elle le certificat examiné ? Ces propositions sont liées, mais aucune ne doit absorber les autres.

La RFC 10007, publiée en juin 2026 sur le Standards Track de l’IETF, corrige précisément la première confusion. Elle met à jour la RFC 5280 et porte les noms de Corey Bonnell, Tadahiko Ito et Tomofumi Okubo, Bonnell étant cité en premier. Cette attribution décrit une contribution à une œuvre collective de l’IETF ; elle ne lui attribue ni invention solitaire ni contrôle sur les déploiements.

Deux clés derrière le même nom

Le scénario du RFC commence par une délégation légitime. Une autorité de certification remet au sujet X un certificat pour la clé A. Le certificat contient keyUsage et active cRLSign. D’autres certificats indiquent, dans leur point de distribution, que X publiera leur information de révocation au moyen d’une CRL indirecte.

La même autorité remet ensuite à X un autre certificat, cette fois pour la clé B. Celle-ci sert à un usage ordinaire et son certificat ne contient pas keyUsage. Le sujet et son distinguished name restent X. La chaîne de certification de B peut parfaitement aboutir à la même ancre de confiance.

Si X signe une CRL avec B, le calcul cryptographique peut réussir et le nom de l’émetteur peut correspondre. Pourtant, le certificat de B n’a jamais affirmé que cette clé était destinée à signer des CRL. L’identité commune ne transporte pas automatiquement le mandat de A vers B.

Cette construction révèle pourquoi le contrôle de but est indispensable. Certifier « cette clé appartient à X » et certifier « cette clé de X peut accomplir l’acte Y » sont deux décisions. Un système qui joint les sujets par leur seul nom rétablit une autorité que le profil de certificat cherchait à séparer.

Quand l’absence devenait le cas le plus permissif

La section 4.2.1.3 de la RFC 5280 était déjà nette. Lorsqu’un certificat sert à valider des signatures sur des certificats ou des CRL, l’extension keyUsage doit être incluse et marquée critical. Le bit cRLSign indique que la clé publique du sujet peut vérifier les signatures de listes de révocation.

La difficulté se trouvait dans la rédaction de l’algorithme de validation. L’étape de la section 6.3.3 disait : si une extension key usage est présente, vérifier que cRLSign est activé. Une implémentation littérale rejetait donc une extension présente sans le bon bit, mais pouvait ne rien vérifier si l’extension entière manquait.

L’absence produisait un résultat plus favorable qu’une interdiction explicite. C’est une forme fréquente d’erreur de validation : le programme contrôle la valeur d’un champ optionnel sans contrôler que ce champ est obligatoire dans le contexte courant.

La RFC 10007 réécrit l’étape pour les certificats v3. Le validateur vérifie que keyUsage est présent, puis que cRLSign est activé. Les journaux devraient refléter les deux opérations. Une extension absente suggère un mauvais profil ou une mauvaise sélection de certificat ; un bit désactivé exprime un usage incompatible. Les corrections ne sont pas identiques.

Une exception de format, pas une permission générale

Les certificats X.509 v1 et v2 ne possèdent pas de champ extensions. La nouvelle exigence de présence ne peut donc leur être appliquée. Cette exception doit rester attachée à la version du certificat et à une politique identifiée ; elle ne peut justifier l’absence de keyUsage dans un certificat v3.

La transition peut être douloureuse. Une ancienne infrastructure peut utiliser depuis longtemps un certificat v3 destiné aux CRL mais mal profilé, sans extension. Les validateurs historiques l’acceptent ; après une mise à jour conforme à la RFC 10007, certains nœuds rejettent la même CRL. Les octets et la signature n’ont pas changé, mais la question de mandat est enfin posée.

Il serait trompeur d’appeler cela simplement une régression. La nouvelle version expose une dette de profil. La RFC recommande aux CA d’inclure keyUsage pour éviter cette rupture. Lorsque le profil ne peut être modifié, l’autorité de gestion de la politique PKI devrait exiger des DN distincts selon les usages.

Des noms distincts diminuent le risque de sélectionner la mauvaise clé. Ils ne réémettent pas le certificat, ne réparent pas les points de distribution et ne fixent pas la durée d’une exception. Ces actes appartiennent au déploiement.

Le mandat ne remplace pas le reste de la révocation

Un cRLSign correct ne rend pas toute CRL valable pour tout certificat. Il faut encore sélectionner le bon émetteur, construire la chaîne, contrôler les algorithmes, traiter distribution point et issuing distribution point, reconnaître une CRL indirecte, interpréter les extensions critiques et vérifier thisUpdate et nextUpdate. Les relations entre CRL complète et delta doivent aussi rester cohérentes.

Le résultat sur le certificat cible vient ensuite. Une CRL autorisée peut être périmée. Une CRL fraîche peut être hors portée. Une CRL parfaitement validée peut annoncer que le numéro de série cible est révoqué. L’automatisation doit donc refuser les raccourcis « signataire autorisé = certificat sûr » et « rejet d’autorisation = attaque prouvée ».

Le rejet d’un certificat v3 dépourvu de keyUsage prouve un défaut précis de représentation du mandat. Il ne prouve pas que la clé a été compromise, que la CRL est falsifiée ou qu’un exploit a eu lieu.

La lecture par l’agency de Heng Lu clarifie les responsabilités. Les auteurs du standard établissent un langage commun. La CA choisit ses profils. L’éditeur transforme le texte en running code. L’autorité de politique décide des dérogations. Le service subit les conséquences. Le résultat de l’un ne peut devenir tacitement le consentement de l’autre.

La spécification minimale porte sur les contrôles communs ; le calendrier de migration demeure local. Le code en fonctionnement est la preuve du comportement réel, à condition d’en conserver les entrées plutôt qu’un simple booléen.

Un reçu qui permette de refaire le raisonnement

Le reçu commence par les pièces : certificat cible, ancre de confiance, URI et condensat de la CRL, heure de collecte, thisUpdate, nextUpdate, algorithme et version du validateur. Il identifie exactement le certificat d’émetteur choisi : numéro de série, Subject Key Identifier, Authority Key Identifier pertinent, DN et version.

Il déroule ensuite les verdicts : chaîne, signature, version v3, présence et caractère critical de keyUsage, valeur de cRLSign. Une exception v1/v2 doit nommer la politique, son propriétaire, sa population et sa date de revue.

La portée forme un autre groupe : distribution point, cRLIssuer, indirect CRL, issuing distribution point, raisons couvertes, CRL complète ou delta. Enfin viennent le numéro de série cible, sa présence, la date et le motif de révocation, la fraîcheur et la décision de l’application.

Lorsque deux versions divergent, ces jointures indiquent si l’une a omis le contrôle, si les deux ont choisi des certificats différents ou si le rejet vient d’une autre étape. Un feu rouge indifférencié produit une panne ; un reçu structuré produit une migration révisable.

La conclusion peut alors rester exacte : tel validateur a traité telle CRL avec tel certificat v3 ; keyUsage était présent et cRLSign activé ; chaîne, signature, portée, fraîcheur et série cible ont fourni leurs résultats propres. La confiance n’est pas un badge. C’est l’assemblage de preuves qui refusent de se remplacer.

Sources