Résumé

  • RFC 10007 corrige l’algorithme de RFC 5280 : pour un certificat v3 d’émetteur de CRL, l’extension keyUsage doit être présente et le bit cRLSign doit être activé.
  • Un même sujet peut détenir deux clés différentes ; la correspondance du nom, la validité de la chaîne et la signature mathématique ne donnent pas à la seconde clé le mandat de publier des révocations.
  • La correction peut rendre incompatibles des certificats v3 anciens mais destinés aux CRL sans extension ; l’AC, l’autorité de politique et l’exploitant de la partie utilisatrice ont donc des travaux distincts.

La panne qui ressemble d’abord à un progrès

Imaginons le lendemain d’une mise à jour. Le nouveau validateur refuse une CRL que l’ancien acceptait. La tentation consiste à classer le changement comme régression logicielle et à rétablir l’ancien comportement. RFC 10007 oblige à poser une autre question : le certificat v3 de la clé porte-t-il réellement l’autorisation cRLSign ? Sa fiche RFC Editor date cette correction de juin 2026 et indique qu’elle met à jour RFC 5280.

Le scénario normatif utilise un sujet X et deux clés. La clé A reçoit un certificat dont keyUsage contient cRLSign. La clé B reçoit un autre certificat au même sujet, sans keyUsage, parce qu’elle sert à une activité ordinaire. Des certificats à vérifier désignent X comme émetteur indirect de leur CRL. Si X signe ensuite la CRL avec B, le nom correspond, la chaîne peut être valide et la signature peut être exacte. Ce qui manque est le mandat de cette clé précise.

L’ancien texte de RFC 5280 demandait de vérifier cRLSign si l’extension existait. Son absence ouvrait donc une branche où le test de finalité disparaissait. La notice de RFC 5280 rappelle pourtant que le profil d’émission imposait déjà l’extension aux clés destinées à vérifier des signatures de certificats ou de CRL.

RFC 10007 aligne les deux côtés. Pour un certificat v3, il faut vérifier la présence de keyUsage, puis cRLSign. Les certificats v1 et v2 ne possèdent pas de champ d’extensions : la nouvelle condition ne leur demande pas l’impossible.

Un nom n’est pas une clé, une clé n’est pas un usage

La correction paraît minuscule parce qu’elle ne change ni l’algorithme de signature ni l’ancre de confiance. Elle restaure une séparation essentielle : identité déclarée, clé publique, chemin de certification et usage certifié sont quatre assertions différentes.

RFC 4514 définit la représentation textuelle LDAP des noms distinctifs ; sa notice n’en fait pas un identifiant global de clé. Deux certificats peuvent légitimement nommer le même sujet et contenir des clés différentes. C’est précisément pourquoi le nom X ne peut absorber la finalité de la clé A et la transmettre à B.

Dans RFC 5280, digitalSignature, keyCertSign et cRLSign sont séparés. cRLSign couvre la vérification des signatures des CRL, des delta CRL et des listes de révocation d’autorité. La capacité mathématique d’une clé à produire une signature ne remplace pas cette certification de finalité.

Le rendu Datatracker de RFC 10007 et l’historique du document prouvent le parcours de normalisation. La charte LAMPS et l’historique du groupe situent les travaux de maintenance PKIX. Aucun de ces registres ne mesure l’adoption réelle par un produit ou une PKI.

La CRL indirecte empile plusieurs preuves

Une CRL indirecte couvre des certificats qui n’ont pas été émis par le signataire de cette CRL. Le certificat cible peut indiquer un cRLIssuer dans son point de distribution. La CRL porte une extension critique issuingDistributionPoint, avec indirectCRL, qui délimite son périmètre.

La partie utilisatrice doit donc vérifier successivement le nom attendu, le rôle indirect, le périmètre, le chemin jusqu’à la même ancre de confiance, la signature, la finalité cRLSign, les dates et la couverture des motifs. RFC 10007 ne corrige qu’un maillon. Un bit exact ne garantit ni le contenu, ni l’actualité, ni l’accessibilité du dépôt.

Cette séparation rejoint RFC 3647, qui distingue l’AC, l’autorité d’enregistrement, le dépôt, l’abonné et la partie utilisatrice, ainsi que la politique de certificat, les pratiques, l’audit et la disponibilité du service de statut. Sa notice aide à ne pas confondre une règle cryptographique avec l’ensemble du service responsable.

Corriger l’acceptation sans perdre la révocation

Le risque de transition est explicite. Une application mise à jour ne pourra plus vérifier une CRL signée par un certificat v3 destiné à cet usage mais dépourvu de keyUsage. Le rejet est conforme à la nouvelle règle ; il peut néanmoins supprimer la seule source de statut dont dépend une application.

La réponse prioritaire appartient à l’AC : inventorier, corriger le modèle de certificat, réémettre, faire chevaucher les anciennes et nouvelles chaînes, puis retirer l’ancien émetteur. Si le profil ne peut réellement pas changer, RFC 10007 invite l’autorité de politique à imposer des noms distinctifs différents selon l’usage. Cette solution évite la collision décrite, mais ne remplace pas la bonne finalité dans les émissions futures.

Un échec de CRL ne signifie pas « certificat révoqué ». Il signifie que cette preuve n’est pas acceptable. Le statut peut rester indéterminé. L’exploitant doit préserver cette troisième valeur, faute de quoi il choisit entre deux mensonges : autoriser comme si tout allait bien ou bloquer comme si la révocation était certaine.

OCSP suit une autre délégation. RFC 6960 exige que le répondeur soit l’AC, une autorité locale ou un délégué explicitement certifié avec id-kp-OCSPSigning dans les conditions prévues ; sa notice documente ce protocole. RFC 10007 ne transforme pas OCSP en secours automatique.

RFC 6818 et sa fiche montrent que RFC 5280 avait déjà reçu des clarifications. Une norme maintenue n’est pas une flotte mise à jour : il reste à tester les bibliothèques, les certificats et les chemins qui fonctionnent réellement.

Une règle mince, une adoption locale

Le cadre de Lu Heng sur la primauté du code en fonctionnement distingue la publication de la réalité opérationnelle. Son texte sur la spécification initiale minimale et la décision future localisée défend des invariants déterministes, vérifiables localement, tout en laissant le séquencement aux participants qui supportent le résultat.

RFC 10007 correspond à un tel invariant : une clé v3 ne signe pas une CRL par défaut ; son certificat doit dire explicitement qu’elle le peut. La migration, elle, doit rester observable et réversible. Publier la règle ne réémet aucun certificat et ne prouve aucune couverture.

Sources