Résumé

  • La RFC 9883 permet à une clé de signature certifiée de porter une déclaration pour une autre demande de certificat de négociation de clé.
  • Cette déclaration affirme la possession ; elle ne la prouve pas techniquement.
  • L’AC doit valider le chemin du certificat signataire, la signature de la demande et la politique d’équivalence d’identité.

Le piège opérationnel est précis : vérifier une signature répond à « qui a signé ? », pas à « qui contrôle la clé privée du certificat demandé ? ». L’attribut privateKeyPossessionStatement transfère une assurance de la première clé vers la seconde, sous forme d’une assertion signée.

Son OID est 1.3.6.1.4.1.22112.2.1. Sa structure complète est PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL } : signer désigne le certificat de signature par le nom de l’émetteur et le numéro de série, tandis que cert, facultatif, contient ce certificat. Ce dernier ne peut être omis que si l’AC est aussi l’émettrice du certificat de signature et peut retrouver tous les certificats valides qu’elle a émis. Cette exception est limitée : elle ne permet pas de déduire l’identité du signataire.

L’AC doit valider le chemin de certification du certificat de signature et rejeter la demande si ce chemin est invalide. Elle doit aussi vérifier la signature de la demande avec la clé publique du certificat de signature et rejeter tout échec. Le nom du sujet et les SAN devraient correspondre à ceux du certificat de signature. En cas de différence, la politique de certificat doit expliquer l’équivalence ; si l’AC ne peut pas l’établir, elle doit rejeter la demande. L’attribut ne doit pas servir à obtenir un certificat de signature.

Les formats ne placent pas les données de la même façon. En PKCS#10, subjectPublicKeyInfo porte la clé publique de négociation, les attributs portent la déclaration, et la signature de la demande est vérifiée avec le certificat de signature. En CRMF, la demande porte le sujet et la clé publique de négociation ; la preuve de possession du format utilise le choix de signature et l’identité de l’expéditeur, tandis que regInfo porte la déclaration. Il ne faut donc pas confondre leurs structures d’encodage.

La RFC 5280 fournit la base de validation du chemin et des usages de clé. La RFC 6955 offre un contraste utile avec des mécanismes qui fournissent une preuve technique de possession pour des clés Diffie-Hellman. La RFC 9883 ne transforme pas son attribut en preuve cryptographique de la seconde clé privée. Son objet diffère aussi de la RFC 9881, consacrée aux identifiants ML-DSA dans PKIX, et de la RFC 9882, consacrée aux octets signés dans CMS.

Analyse de Theo March : le mécanisme ressemble à une racine d’assurance déléguée. Cette lecture est une analyse, non une exigence de la RFC. L’AC devrait relier dans ses journaux chaque certificat dérivé au certificat signataire, conserver la décision d’équivalence d’identité et surveiller les volumes, les changements de sujet, les répétitions et les échecs. Ces contrôles rendent le transfert auditable.

La révocation crée une propagation. En cas de compromission du certificat de signature, la RFC identifie la révocation rapide comme seule protection et indique que l’AC devrait révoquer les certificats de négociation obtenus grâce aux déclarations signées par ce certificat. Une procédure de propagation, des alertes et un inventaire sont une analyse opérationnelle, pas un schéma d’automatisation imposé. La clé de signature devrait offrir une force au moins égale à celle de la clé de négociation. En migration, il faut tester la parité, les changements d’algorithme et les règles d’équivalence.

Jeu de tests d’enrôlement : chemin et signature valides ; chemin invalide ; signature altérée ; certificat incorporé absent alors que l’AC n’est pas l’émettrice ; absence récupérable chez l’émettrice ; sujets ou SAN différents avec équivalence documentée puis sans équivalence ; demande d’un certificat de signature ; clé signataire plus faible ; et encodages PKCS#10 et CRMF contrôlés à leurs emplacements propres. Le journal devrait relier émetteur-numéro de série, empreintes des demandes et des clés, décision de politique et certificat produit.

En incident, suspendre l’émission depuis le certificat suspect, conserver les preuves, confirmer la compromission, révoquer rapidement le certificat signataire, inventorier les certificats dérivés et les révoquer selon la politique de l’AC. Ensuite, renouveler les rôles nécessaires, examiner les décisions d’équivalence et de force, puis surveiller les rejouements et nouvelles déclarations. Ce parcours est l’analyse de Theo March, pas une procédure complète prescrite par la RFC.

Sources