Résumé

  • Avec RFC 9763, le demandeur prouve au moment de l’enregistrement qu’il contrôle la clé privée d’un certificat existant ; l’autorité peut ensuite inscrire dans le nouveau certificat l’empreinte du certificat existant tout entier.
  • Cette relation ne constitue ni une authentification en cours ni l’ordre d’employer les deux certificats. Le protocole et le vérificateur décident encore si une preuve suffit, si les deux sont requises et si la connexion doit continuer.
  • L’audit doit donc séparer la preuve fournie à l’autorité, l’assertion inscrite à l’émission, les deux chemins de certification, les actes cryptographiques de la session et la décision locale finale.

Le tableau de migration affiche deux certificats « associés ». Le premier relève de l’algorithme historique, le second d’un algorithme post-quantique. Les dates sont bonnes, les sujets se ressemblent et l’extension attendue est présente. Pour un comité de pilotage, la colonne verte paraît annoncer que la migration est faite.

Mais l’association n’a encore authentifié aucune connexion. Elle ne montre pas que les deux clés privées ont signé l’échange observé. Elle ne révèle pas le jeu d’ancres de confiance du destinataire. Elle ne garantit pas que la négociation a conservé l’algorithme le plus fort. Elle ne tranche même pas la question de savoir si une seule authentification réussie suffit.

C’est précisément la retenue de la RFC 9763. Le texte définit l’attribut de demande relatedCertRequest et l’extension X.509 RelatedCertificate. Ensemble, ils donnent une assurance supplémentaire que deux certificats d’entité finale appartiennent à la même entité. Ils ne réalisent pas, à eux seuls, une fonction de sécurité.

Une relation produite avant l’usage

La construction commence avec un Certificat A déjà émis. Son titulaire demande un Certificat B, par exemple pour accompagner une transition de la cryptographie classique vers la cryptographie post-quantique. La demande ordinaire porte la nouvelle clé publique. Dans le modèle PKCS#10 de la RFC 2986, la signature de la demande lie le nom, la clé publique et les attributs et démontre la possession de la clé privée correspondante.

RFC 9763 ajoute une preuve distincte concernant A. L’attribut relatedCertRequest contient l’émetteur et le numéro de série de A, un instant de demande, une information de localisation et une signature. Cette signature est calculée avec la clé privée de A sur la concaténation de l’identifiant DER du certificat et de l’instant encodé.

L’instant est un BinaryTime. La RFC 6019 le représente comme un nombre de secondes depuis le 1er janvier 1970 à minuit UTC, hors secondes intercalaires. Le format est déterministe ; la durée pendant laquelle la preuve reste « suffisamment fraîche » ne l’est pas. RFC 9763 en confie la définition à la politique locale de l’autorité de certification.

Cette séparation est saine. La spécification commune dit quelles données signer et comment les vérifier. L’organisation qui supporte le risque fixe la fenêtre temporelle. Un journal d’audit doit conserver l’instant, la politique appliquée et sa version. Garder seulement le verdict « frais » rend la décision impossible à rejouer après un changement de politique.

Ce que l’autorité vérifie réellement

Une autorité qui prend en charge l’attribut doit d’abord obtenir A depuis l’emplacement indiqué. Elle doit valider son chemin conformément à la RFC 5280, vérifier que l’émetteur et le numéro de série correspondent à certID, appliquer sa règle de fraîcheur, puis vérifier la signature avec la clé publique de A.

Ces opérations ne forment pas un état magique unique. La récupération établit quelles données ont été reçues. La validation de chemin applique des ancres et des politiques. La comparaison identifie le bon certificat. Le test temporel applique une décision locale. La signature prouve l’action de la clé privée de A sur cette demande précise.

La nuance de RFC 5280 est essentielle : les ancres de confiance et les politiques font partie des entrées de validation. Un chemin peut satisfaire les conditions minimales de l’algorithme tout en restant impropre à une application particulière. Les usages de clé et usages étendus doivent être traités séparément lorsqu’ils sont tous deux présents.

Après ces contrôles, l’autorité peut émettre B avec l’extension RelatedCertificate. Elle ne doit y référencer que le certificat présenté dans la demande. A doit porter les bits d’usage de clé et les OID d’usage étendu revendiqués dans B. L’autorité devrait aussi constater que A est valide lors de l’émission.

La période pendant laquelle A et B seront simultanément utilisables reste toutefois l’affaire du souscripteur. Une émission correcte n’empêche pas A d’expirer plus tôt, d’être révoqué ou d’être renouvelé sous une forme qui ne correspond plus à l’empreinte inscrite dans B. « Valide au jour de l’émission » est un fait historique, pas une garantie de disponibilité future.

L’empreinte vise des octets exacts

Dans B, l’extension contient l’identifiant de l’algorithme de hachage et l’empreinte de l’intégralité de A. Elle ne désigne pas abstraitement « le certificat classique du même client ». Elle ne hache pas seulement sa clé publique. Elle n’englobe pas tous les certificats portant le même nom.

Cette précision permet une vérification locale simple. Quand un pair reçoit A et B, il calcule l’empreinte de A selon l’algorithme indiqué et compare le résultat à la valeur de B. Il n’a pas besoin de demander à une autorité en ligne quel ancien certificat était visé.

Elle évite aussi une dangereuse approximation d’inventaire. Si A est réémis avec le même sujet et la même clé mais une autre période de validité, un autre numéro de série ou d’autres extensions, ses octets changent. Son empreinte change. Le nouveau A n’est pas celui auquel B est lié. Un inventaire regroupé uniquement par nom de sujet peut donc annoncer une relation que le certificat ne porte plus.

L’extension ne devrait pas être critique, afin de ne pas casser l’interopérabilité avec des logiciels qui ne la comprennent pas. Elle ne doit apparaître que dans un certificat d’entité finale. Cette compatibilité permet une adoption progressive ; elle ne prouve pas l’adoption. Un logiciel ancien qui ignore l’extension n’a pas vérifié la relation.

Le vérificateur reçoit un élément, pas un ordre

Dans un protocole capable d’authentifications multiples, le destinataire qui reçoit les données appropriées examine l’extension, calcule l’empreinte du second certificat et vérifie la correspondance. La norme s’arrête ensuite volontairement. La conduite à tenir dépend de la politique de chaque pair : exiger les deux authentifications, en accepter au moins une, terminer ou abandonner la connexion.

Le partage du contrôle varie aussi selon le protocole. Dans CMS ou S/MIME, le signataire choisit les clés qu’il pense utiles aux destinataires. Dans une négociation en ligne, les préférences du vérificateur peuvent s’exprimer. La RFC 5652 définit la syntaxe CMS et ses structures de certificats ; la RFC 8551 décrit le conditionnement S/MIME utilisé pour transporter des certificats. Ces formats ne décident pas de l’autorisation applicative.

RFC 9763 le dit sans ambiguïté : l’association n’oblige pas à utiliser un certificat avec l’autre. Elle indique qu’ils peuvent être employés ensemble parce que les clés sont sous le contrôle de la même entité. Le certificat parle pour l’autorité au moment de l’émission ; il ne parle pas à la place du vérificateur au moment du risque.

Deux horloges de contrôle des clés

La sécurité de l’ensemble exige une preuve de contrôle au moment de l’enregistrement auprès de l’autorité et au moment de l’usage auprès du vérificateur. Ce sont deux événements différents.

La signature de relatedCertRequest prouve que la clé de A a participé à l’enregistrement. La signature de la demande ordinaire concerne la nouvelle clé. L’extension conserve ensuite l’association émise. Une session ultérieure doit encore contenir les actes cryptographiques que la politique du protocole requiert. La présence de B dans un message ne fait pas agir sa clé privée.

Si seule la clé classique signe, le certificat post-quantique associé n’ajoute pas une preuve post-quantique. Si les deux signatures sont présentes mais qu’une seule est validée, l’autre ne produit aucune assurance. Si les deux calculs réussissent mais qu’un chemin aboutit à une ancre non admise, l’empreinte de relation ne peut pas élargir la confiance locale.

Cette frontière distingue aussi RFC 9763 de la RFC 9883. RFC 9883 accepte, selon la politique, une déclaration signée au sujet d’une autre clé d’établissement sans preuve technique de possession de cette autre clé. Ici, la clé de A produit une vraie signature, la demande ordinaire couvre B, puis l’autorité conserve l’association exacte. Le sujet n’est pas le remplacement assumé d’une preuve, mais la non-confusion entre preuve d’enregistrement et usage futur.

La RFC 9955 étudie quant à elle les propriétés possibles des signatures hybrides et leurs règles de combinaison. RFC 9763 ne choisit pas un combinateur universel. Elle fournit un signal de relation exploitable par une règle de protocole définie ailleurs.

Franchir deux autorités ajoute un contrat

Quand la même organisation a émis A et B, elle peut souvent retrouver et valider l’ancien certificat dans son propre environnement. Entre deux organisations de certification, la situation change. L’autorité de B peut ne pas posséder l’ancre nécessaire pour A. RFC 9763 prévoit alors des arrangements préalables : contrats, ancres configurées et accords sur l’usage, l’émission et l’acceptation.

Le hachage ne rend pas deux politiques équivalentes. La vérification d’identité, la protection matérielle des clés, les règles de révocation et les obligations du souscripteur peuvent différer. L’autorité de B devrait choisir une politique offrant une protection comparable à celle de A ; cette comparabilité est une décision attribuable, pas une propriété mathématique de l’extension.

Il faut donc bannir les raccourcis de rapport : « même entité » ne signifie pas « même niveau d’assurance » ; « chemin valide » ne signifie pas « chemin accepté pour cet usage » ; « relation confirmée » ne signifie pas « double authentification réussie ».

Le transport du certificat a sa propre surface de risque

L’attribut indique où obtenir A. Dans le cas d’une même organisation, une URL HTTP(S) peut exposer un message CMS ne contenant que les certificats. Entre organisations, RFC 9763 recommande plutôt une URL data: embarquant les certificats et informations de révocation utiles. La RFC 2397 définit ce schéma.

Une URL signée n’est pas une source approuvée. Elle peut pointer vers du contenu malveillant. Il faut parser prudemment, vérifier la forme et valider entièrement le matériel. Une récupération réseau peut en outre être observée et dévoiler qu’une autorité traite une demande liée à un certificat précis. Le transport intégré réduit ce signal externe sans abolir les contrôles.

Le dossier de décision devrait garder le mode de transport, l’empreinte du contenu reçu, le résultat du parseur, les données de chemin et de révocation et l’ensemble d’ancres utilisé. Sans cela, le certificat B final ne suffit pas à prouver quelles données l’autorité a examinées.

L’association ne bloque pas le repli

Une attaque de repli peut apparaître avant même que l’extension soit examinée : un pair malveillant omet la prise en charge de l’algorithme fort et force un échange reposant sur l’algorithme faible. Le certificat ne peut pas témoigner d’une capacité qui n’a jamais été proposée ou qui a disparu pendant la négociation.

Les preuves nécessaires vivent dans les configurations minimales, les transcriptions authentifiées lorsqu’elles existent, le mode effectivement choisi et les alertes de changement. Le nombre de certificats associés mesure une préparation administrative. Le trafic montrant les deux preuves mesure l’usage.

Cette allocation rejoint la primauté du code exécuté et le triptyque spécification initiale minimale, décision future localisée et adoption volontaire de Heng Lu. La couche commune peut définir les octets, les signatures, l’empreinte et la comparaison. Le participant qui exécute le protocole garde la décision future. La publication ne crée pas l’adoption.

L’analyse des couches de réalité impose enfin de ne pas fondre l’enregistrement, l’émission, le certificat reçu, la preuve de session, la politique locale et l’effet observé dans un statut unique. Chacun a son producteur, son instant et sa portée.

La chaîne de preuves à conserver

Au stade de la demande, conserver les octets exacts de la CSR, l’identifiant de A, l’instant, la localisation, les données signées, le verdict de signature et les éléments de validation de A. À l’émission, conserver les octets et l’empreinte de A, les octets de B, la règle de correspondance des usages, la décision de politique et le calcul de chevauchement des validités.

Au stade de l’usage, conserver les certificats réellement reçus, les deux résultats de chemin, la comparaison d’empreinte, les signatures réellement vérifiées, le mode négocié, la version de politique, la décision du pair et l’état final de la connexion. Le but n’est pas de tout journaliser ; il est de pouvoir attribuer un échec au bon mécanisme.

Sources