Résumé

  • Dans la RFC 10002, dont Joseph Mandel et Sean Turner sont les éditeurs, la preuve de possession établit que l’entité finale détient et sait utiliser la clé privée associée à la clé publique. Elle ne démontre ni l’identité ni le droit de recevoir le certificat demandé.
  • CMC transporte séparément la preuve d’identité et la preuve de possession, puis exige de les relier à la même entité. Une autorité d’enregistrement peut ajouter une enveloppe et des contrôles, tandis que l’autorité de certification conserve sa propre décision de politique.
  • L’audit utile garde les objets dans leur ordre : requête originale, méthode de possession, identité, lien anti-substitution, interventions des autorités d’enregistrement, décision de l’émetteur, réponse, certificat exact, installation, validation et révocation.

Une signature PKCS #10 répond avec précision à une question : la partie qui a signé disposait-elle de la clé privée correspondant à la clé publique placée dans la requête ? Lorsque la vérification réussit, on obtient une preuve cryptographique forte. On ne reçoit pas, par le même calcul, un dossier d’identité ni une autorisation de nom de domaine.

Cette limite paraît évidente lorsqu’on lit chaque norme séparément. Elle disparaît vite dans une chaîne automatisée. Le premier composant renvoie « signature valide », le suivant résume « requête valide », et le tableau de bord finit par afficher « certificat autorisé ». Trois changements de sens ont eu lieu sans nouvelle preuve.

La famille CMC publiée en juillet 2026 aide à empêcher ce glissement. La RFC 10002 décrit les messages de gestion de certificats au-dessus de CMS. La RFC 10003 précise leur transport par HTTP, fichier, courrier ou TCP. La RFC 10004 indique les exigences applicables aux différentes classes d’agents. Joseph Mandel et Sean Turner éditent ensemble les trois textes. Il ne s’agit donc ni d’une invention individuelle de Turner ni d’une garantie de déploiement.

Le profil public de l’IETF situe sa contribution : participation depuis l’IETF 34, plus de 50 RFC comme auteur ou coauteur, mandat de Security Area Director de 2007 à 2014 et plusieurs responsabilités de présidence consignées au 1er septembre 2026. Cette expérience explique une présence durable dans les standards de sécurité. Elle ne donne à Turner aucune compétence opérationnelle sur une autorité de certification, une autorité d’enregistrement ou un demandeur particulier.

La possession est une propriété de la clé

PKCS #10 place une clé publique, un sujet et des attributs dans un objet signé. La signature protège cet ensemble contre une substitution simple de clé et montre que le signataire peut produire une signature avec la clé privée correspondante. La RFC 2986 décrit pourtant trois actes du côté de l’autorité : authentifier le demandeur, vérifier la signature puis, si la requête satisfait ses règles, construire un certificat.

La condition « si » concentre la politique. L’autorité peut refuser un sujet, un nom alternatif, une durée, un usage de clé ou un profil. Elle peut demander d’autres preuves. Elle n’est pas un service d’impression commandé par une signature valide.

CMC emploie le terme Proof-of-Possession, ou POP, pour cette famille de preuves relatives à la clé. La RFC 10002 mentionne notamment la signature, le défi-réponse direct, la preuve indirecte, la publication et l’attestation, sans imposer chaque forme à chaque échange. Leur point commun n’est pas d’autoriser le certificat. Il est de montrer que l’entité finale possède la clé privée et peut l’utiliser.

Une clé volée reste capable de signer. Un appareil légitime peut avoir reçu un identifiant d’inventaire erroné. Un administrateur peut contrôler une clé sans être habilité à demander le nom d’un service. Une organisation peut prouver la possession technique tout en échouant aux règles du secteur ou de l’émetteur. La cryptographie peut confirmer la clé sans résoudre ces contradictions institutionnelles.

Relier deux preuves n’en fait pas une seule

La RFC 10002 nomme séparément la preuve d’identité. Une Simple PKI Request ne convient pas lorsqu’il faut incorporer cette preuve. Une Full PKI Request peut utiliser un secret partagé, un certificat existant ou une autre méthode convenue entre les parties.

La séparation crée un risque de substitution. Si Alice fournit une identité recevable et Bob une possession de clé recevable, un système ne doit pas assembler les deux résultats pour produire une demande au nom d’Alice avec la clé de Bob. CMC exige donc que l’identité et la POP soient liées à la même entité. Le témoin calculé à partir d’un secret, la correspondance entre secret et nom de sujet ou le lien avec un certificat existant sont des moyens de prouver cette jointure.

La jointure est un événement de sécurité à part entière. Il faut enregistrer les identifiants reliés, les octets couverts, le vérificateur, la méthode et le résultat. Deux cases vertes dans une interface ne prouvent pas qu’elles se rapportent à la même personne ou au même appareil.

Le secret partagé garde, lui aussi, une histoire extérieure au protocole. La RFC n’en organise pas la distribution hors bande. Un témoin mathématiquement correct ne renseigne pas sur le destinataire initial du secret, sa protection ou sa réutilisation lors de tentatives successives. La qualité de la preuve ne peut dépasser sans explication la qualité de l’enrôlement qui l’a rendue possible.

L’autorité d’enregistrement ajoute une enveloppe

CMC distingue l’entité finale, l’autorité d’enregistrement et l’autorité de certification. La première possède la paire de clés. La deuxième peut effectuer un contrôle local, regrouper ou router les requêtes, archiver une clé ou traiter des extensions. La troisième émet le certificat. Dans une chaîne, le même nœud peut être serveur face à l’entité finale et client face à l’autorité de certification. Ce changement de direction ne change pas magiquement ses pouvoirs.

Le cœur signé doit rester intact. Modifier une requête PKCS #10 ou CRMF invaliderait la signature et la POP. Lorsqu’une autorité d’enregistrement demande une modification, elle la porte dans un contrôle extérieur. Plusieurs intermédiaires peuvent produire plusieurs enveloppes imbriquées. L’historique permet alors de distinguer la volonté du demandeur de l’action ajoutée plus tard.

Cette provenance est indispensable pour les extensions X.509. Le demandeur peut solliciter des noms, usages, politiques ou autres champs. Le serveur doit savoir traiter les extensions définies, mais n’est pas tenu de toutes les insérer. Il peut modifier une demande sans en inverser le sens. Le certificat final est donc le résultat d’une décision, pas une copie certifiée conforme de la requête.

Conserver seulement le certificat efface ce qui avait été demandé. Conserver seulement la requête efface qui l’a transformée. Un reçu complet associe les deux sans les confondre : objet signé, enveloppes, signataires, règles appliquées, changements, décision et octets du certificat.

Le transport possède son propre succès

Avec la RFC 10003, un client HTTP envoie le message CMC par POST selon les types de média prévus. HTTPS peut protéger le canal ; le texte ne rend pas l’authentification HTTP obligatoire pour tous les clients. Protection du canal, authentification HTTP, preuve d’identité CMC et possession de la clé sont des contrôles différents.

Le code d’état est tout aussi local. Une réponse HTTP 2xx confirme le traitement de l’échange HTTP. À l’intérieur, la réponse CMC peut indiquer une attente, une mauvaise identité, une POP requise ou échouée, ou une extension non prise en charge. L’opérateur doit lire le message encapsulé et, en cas de succès, comparer le certificat retourné à la requête.

La RFC 10004 ne change pas ce principe. Une implémentation peut respecter une classe de conformité sans que cela prouve le bon traitement d’une transaction réelle, la qualité d’une politique ou l’adoption par le marché. Le standard décrit ce qu’un agent doit savoir faire ; le reçu montre ce qu’il a effectivement fait.

Le certificat émis ouvre une nouvelle enquête

Après l’émission viennent la livraison, l’installation et l’usage. La RFC 5280 encadre la construction et la validation du chemin, les politiques, les contraintes de nom, les périodes de validité et les informations de révocation. Un certificat correct peut ne jamais atteindre l’équipement. Un certificat installé peut ne pas correspondre à la clé locale. Un chemin valide peut authentifier une identité que l’application refuse d’autoriser.

Il faut donc éviter un état global « certificat OK ». Heng Lu propose, avec la primauté du code en fonctionnement, de conserver les éléments permettant de reproduire chaque affirmation. Pour l’enrôlement : requête, preuves, liaison, enveloppes, politique et réponse. Pour l’exploitation : certificat, correspondance de clé, cible d’installation, chemin, source de statut et décision du service.

Le reçu ne doit pas être élégant au point d’effacer la réalité. Il doit montrer au moins le demandeur et l’heure, la clé et les champs sollicités, la POP, l’identité, leur lien, chaque intervention d’autorité d’enregistrement, l’autorité de certification et sa version de politique, le statut CMC, le certificat exact, l’installation, puis la révocation ou le remplacement.

Le mérite de cette architecture collective est de résister à un raccourci séduisant. Une preuve de clé correctement vérifiée reste une excellente preuve de clé. Elle ne devient pas une autorisation simplement parce qu’un autre système souhaite une réponse binaire.

Sources