Résumé

  • RFC 10002 conserve la demande signée de l’entité finale dans une couche CMS interne, tandis qu’une autorité d’enregistrement peut ajouter, dans une couche PKIData externe, un témoignage de preuve ou une demande de modification.
  • Signature valide, possession de la clé privée, identité établie, témoignage accepté, contrôle traité et certificat émis sont six conclusions distinctes. Le mot « vérifié » ne suffit pas.
  • Une organisation doit pouvoir rejouer la chaîne : requête originale, enveloppes RA, ordre des contrôles, portée des délégations, politique de la CA et différence exacte entre ce qui fut demandé et ce qui fut signé.

Le risque apparaît souvent après une opération réussie. La demande PKCS #10 est archivée, sa signature est correcte et la clé publique du certificat délivré correspond. Pourtant, une extension a disparu et un attribut de nom a été remplacé.

Il serait facile d’en conclure que la CA a altéré la demande. Ce serait imprécis. L’objet signé par le demandeur peut être resté parfaitement intact. Une autorité d’enregistrement a pu l’encapsuler, attester d’un contrôle d’identité, demander une correction, puis transmettre l’ensemble à la CA. Celle-ci a encore pu appliquer sa politique avant l’émission.

RFC 10002, publié en juillet 2026 sur la voie normative de l’IETF, décrit ce langage CMC et remplace les RFC 5272 et 6402. RFC 10003 traite des transports ; RFC 10004 attribue les capacités minimales aux entités finales, aux RA et aux CA. Leur architecture oblige à séparer la protection cryptographique d’un objet de l’autorité institutionnelle qui transforme une demande en certificat.

Ce que la signature PKCS #10 affirme réellement

Selon RFC 2986, une demande PKCS #10 réunit un nom de sujet, une clé publique, des attributs facultatifs, un identifiant d’algorithme et une signature sur les informations de demande. La vérification démontre que les octets protégés n’ont pas changé et que la clé privée de signature a été utilisée.

Elle ne démontre ni le droit juridique d’utiliser le nom, ni la possession d’une autre clé incapable de signer, ni l’obligation pour la CA d’inclure toutes les extensions. Elle n’accorde pas davantage à une RA le droit de modifier un champ.

Une requête CMC simple peut transporter directement ce PKCS #10, mais elle ne porte pas les contrôles avancés. RFC 10002 en interdit l’emploi lorsque la preuve d’identité est incluse et elle ne convient pas à une clé privée qui ne peut pas signer. La requête complète place au contraire PKIData dans SignedData ou AuthenticatedData de CMS.

RFC 5652 permet d’encapsuler un contenu déjà protégé dans une nouvelle enveloppe signée, authentifiée ou chiffrée. Une RA ne doit donc pas réécrire silencieusement le PKCS #10 ou le CRMF interne : elle détruirait la signature ou la preuve de possession. Elle ajoute une couche externe et signe sa propre contribution. Plusieurs RA peuvent créer plusieurs niveaux.

Cette construction donne une provenance possible, pas une autorisation automatique. La signature interne répond à « qu’a protégé le demandeur ? ». La signature externe répond à « qui a ajouté ce contrôle ? ». Il faut encore établir que cet intermédiaire avait compétence pour ce type de contrôle et cette population.

Prouver la possession n’est pas établir l’identité

La preuve de possession concerne la clé privée. Pour une clé de signature, une signature peut suffire. Pour une clé de chiffrement ou d’établissement de clé, la preuve peut prendre la forme d’un défi, d’une réponse ultérieure ou d’une confirmation après délivrance. RFC 4211 formalise ces variantes dans CRMF et prévoit le cas raVerified, où la RA indique avoir accompli la POP dans des conditions précises.

La preuve d’identité rattache la transaction à une personne, un appareil ou une organisation selon une méthode d’authentification. Identity Proof Version 2 de RFC 10002 peut employer un secret partagé pour calculer un MAC sur les éléments de la requête. L’ancienne version demeure pour compatibilité, mais RFC 10004 impose la version moderne.

Ces preuves ne sont pas interchangeables. Détenir une clé ne confère pas le droit de porter une identité d’entreprise. Vérifier un dossier RH ne prouve pas que la clé non exportable se trouve dans le matériel déclaré. Une donnée booléenne verified efface précisément l’information dont dépend l’enquête.

CMC reconnaît aussi la délégation. RA POP Witness permet à une RA d’affirmer qu’elle a exécuté la preuve de possession. RA Identity Proof Witness permet de transmettre le résultat d’une preuve d’identité, notamment lorsque la CA ne connaît pas le secret partagé ou lorsque le contrôle a eu lieu hors bande.

Le témoignage n’est pas la preuve d’origine. Il devient une nouvelle assertion, signée par la RA et acceptée selon une politique. Le journal doit donc préciser l’auteur, la méthode, le sujet, la clé visée, la portée de l’habilitation et la référence vers les éléments conservés. Control Processed, plus général, ne doit pas masquer le type de preuve lorsque celui-ci a une importance décisionnelle.

Modifier sans casser la signature

Le contrôle Modify Certification Request permet à une RA de demander le remplacement ou la suppression de champs. La requête interne demeure celle que l’entité finale a signée ; la modification est portée par une enveloppe externe attribuable.

Cette souplesse répond à de vrais besoins : normaliser un nom, retirer une extension non autorisée ou transcrire un résultat d’identité dans un format accepté par la CA. Elle exige néanmoins une trace précise du body part concerné, de l’ancienne valeur, de la nouvelle, de la règle appliquée et de la RA responsable.

Pour des couches imbriquées, les modifications s’appliquent de l’intérieur vers l’extérieur. En revanche, RFC 10002 ne fixe pas l’ordre de plusieurs contrôles placés dans une même couche. Une procédure qui dépend de l’ordre d’un tableau dépend d’une bibliothèque, non d’une garantie interopérable. Il faut produire une décision composite non ambiguë ou utiliser des couches distinctes lorsque la préséance compte.

La CA garde enfin sa propre compétence. Elle n’est pas tenue d’inclure toutes les extensions demandées par l’entité finale ou la RA. Elle peut en omettre ou en modifier selon sa politique, sans inverser le sens d’une restriction demandée par le client. Le certificat est ainsi une nouvelle décision signée par la CA, non une photocopie authentifiée de la requête.

Une piste correcte compare trois états : l’objet signé initial, les changements demandés par chaque RA et le certificat émis. Chaque différence matérielle reçoit un auteur et une justification. La signature de la CA indique qui a signé le résultat ; elle ne raconte pas à elle seule l’origine de chaque valeur.

Le succès du transport n’est pas la fin de la transaction

RFC 10003 prévoit le fichier, le courrier électronique et HTTP. En HTTP, le client utilise POST ; HTTPS protège le canal contre l’écoute. Ni TLS ni un code 2XX ne prouvent que les contrôles CMC ont été compris ou que l’émission est définitive.

Une opération complète peut rester en attente ou n’être que partiellement traitée. Query Pending permet de reprendre la consultation, et Confirm Certificate Acceptance prolonge l’état au-delà de la réception du certificat. Un serveur final incapable de reconnaître ou d’exécuter un contrôle obligatoire doit faire échouer tout le PKIData, au lieu d’effacer le contrôle et de produire un succès trompeur.

L’identifiant de transaction relie les messages successifs. Les nonces d’émetteur et de destinataire contribuent à la corrélation et à la protection contre le rejeu. Ils ne remplacent pas l’idempotence métier, mais leur perte empêche de distinguer une relance après réponse perdue d’une nouvelle demande.

La matrice de RFC 10004 confirme que ces fonctions sont centrales : une RA doit prendre en charge Modify Certification Request, Control Processed et RA Identity Proof Witness ; une CA conçue pour travailler avec des RA doit savoir les recevoir. Cela établit un plancher de capacité, pas la preuve qu’un déploiement a correctement traité une transaction particulière.

Après l’émission, RFC 5280 encadre le certificat X.509 que les parties utilisatrices valideront. Il reconnaît que des domaines spécialisés peuvent ajouter leurs exigences et rappelle l’importance de la politique de certification. RFC 7030, qui définit EST, montre par ailleurs qu’une organisation dispose d’autres architectures d’enrôlement : le choix de CMC ne saurait devenir une légitimité abstraite.

Une preuve exploitable après compromission

Le dossier d’émission doit commencer par les octets canoniques et le hachage de la requête originale. Il associe le format, la clé publique, les attributs protégés, le résultat de signature et l’identité de la clé. Chaque contrôle POP ou d’identité conserve sa méthode, sa cible, son vérificateur initial, son résultat, sa date et sa version de politique.

Chaque enveloppe RA doit rester disponible avec sa signature, le certificat de la RA, son périmètre, les contrôles ajoutés, les couches éventuellement retirées et le destinataire suivant. Toute modification reçoit une cible et un avant/après ; tout témoignage indique le type de preuve qu’il représente. Les secrets partagés et clés privées ne doivent pas être copiés dans les journaux.

La CA enregistre ensuite sa décision pour chaque champ, ainsi qu’un diff entre demande, chaîne RA et certificat. Identifiant de transaction, nonces, relances, états d’attente, acceptation, publication et activation restent liés.

Si une RA est compromise, la requête interne peut demeurer authentique. L’attaquant peut cependant signer une enveloppe externe malveillante avec une clé RA reconnue. L’absence de falsification de la demande ne signifie donc pas absence d’abus d’autorité.

La primauté du code en fonctionnement fournit ici un critère opératoire : un contrôle n’a d’autorité pratique que si le code valide sa couche, vérifie le périmètre de l’acteur et conserve le résultat. La spécification initiale minimale maintient les mécanismes communs étroits ; la décision locale reste à l’opérateur qui en assume les conséquences. La distinction entre couche réelle et couche symbolique empêche « signé », « attesté » ou « émis » de devenir une promesse de sécurité universelle.