Résumé

  • RFC 9883 permet au titulaire d’un certificat de signature d’affirmer qu’il détient une autre clé privée, destinée à l’établissement de clé, sans fournir de preuve technique de cette détention.
  • L’acceptation dépend de la politique du CA, de la validation du chemin et de la signature, de l’identité des noms et de la capacité à retrouver le certificat signataire.
  • La compromission ultérieure de la clé de signature doit conduire à retrouver puis révoquer les certificats d’établissement issus de ses déclarations.

Le mot « possession » apparaît dans l’attribut, la signature de la demande est valide et le nouveau certificat vise une clé publique bien formée. Rien de cela ne signifie que la clé privée correspondante a participé à l’opération. La signature a été produite par une clé antérieure, déjà certifiée.

Deux clés et deux faits

Le déroulement PKCS#10 décrit par RFC 9883 commence par une paire de signature. Le sujet signe une première demande et reçoit un certificat autorisé pour la signature. Il crée ensuite une paire destinée à l’établissement de clé. La seconde demande contient cette nouvelle clé publique et l’attribut privateKeyPossessionStatement, mais elle est signée avec l’ancienne clé privée de signature.

Le texte ne cherche pas à dissimuler l’écart. Il dit que le sujet du certificat de signature affirme, sans en apporter la preuve, qu’il possède la clé privée d’établissement. Si la politique de certification l’autorise, le CA peut accepter cette affirmation à la place d’un mécanisme technique. RFC 6955 décrit de telles preuves pour certaines clés DH ou ECDH, mais elles ne conviennent pas à PKCS#10 et ne couvrent pas les KEM comme ML-KEM. L’attribut de RFC 9883 fonctionne avec PKCS#10 et CRMF.

La signature valide démontre donc une chose circonscrite : le contrôle de la clé de signature pour cette demande. Elle relie un justificatif antérieur à une affirmation sur une autre clé. Elle ne montre ni le lieu de génération de cette autre clé, ni son caractère exportable, ni sa disponibilité au moment où le certificat sera utilisé.

Le CA porte la décision

Le CA doit valider le chemin du certificat signataire selon RFC 5280 et vérifier la signature de la demande. Un échec impose le rejet. Le nom du sujet devrait être identique dans les deux contextes. Si les sujets ou les noms alternatifs diffèrent, la politique doit expliquer comment établir qu’ils représentent la même entité ; sans résultat, le rejet est obligatoire.

L’attribut désigne le certificat signataire par son émetteur et son numéro de série. Il peut aussi l’embarquer. Lorsque le même CA émet les deux certificats, l’omission est permise, mais le demandeur suppose alors que le CA sait retrouver tous ses certificats encore valides. Cette hypothèse relève de l’exploitation d’un dépôt, pas de l’ASN.1. Un identifiant n’est ni le certificat récupéré, ni son chemin validé, ni son état historique.

Dans PKCS#10, la clé publique d’établissement et l’attribut se trouvent dans les informations signées de la demande. Dans CRMF, le choix signature de ProofOfPossession, poposkInput, l’identité de l’expéditeur et une copie de la clé publique organisent la même dépendance ; la déclaration est ajoutée dans regInfo. Dans les deux cas, la clé d’établissement n’exécute pas une preuve.

Le document interdit donc cet attribut pour obtenir un certificat de signature. Une clé apte à signer peut prouver directement sa possession en signant sa propre demande. La substitution est réservée au problème plus étroit des clés d’établissement.

La révocation révèle la dette

Si la clé de signature est compromise, un tiers peut fabriquer de nouvelles déclarations. La révocation rapide du certificat de signature est la protection indiquée. RFC 9883 recommande aussi de révoquer tous les certificats d’établissement obtenus grâce aux déclarations signées par cette clé.

Cette opération exige un graphe conservé dès l’émission : certificat signataire, demande, version de politique, décision d’identité et certificats produits. La robustesse de la clé de signature devrait en outre être au moins égale à celle de la clé d’établissement. Sinon, le pont de confiance devient le maillon faible.

Sources