Résumé

  • La RFC 9810 distingue accepted, qui signifie que le demandeur a obtenu exactement ce qu’il voulait, de grantedWithMods, qui lui impose d’identifier les différences.
  • La protection cryptographique de l’échange prouve une provenance et une continuité de transaction ; elle ne prouve pas que l’identité, la durée, les usages de clé, les EKU, les contraintes et la politique du certificat correspondent encore à l’intention autorisée.
  • Un reçu local d’intention du certificat peut relier demande, certificat délivré, écarts matériels, autorité de modification et décision d’accepter ou de rejeter sans conserver de clé privée. Il s’agit d’une proposition éditoriale de Daniel Kade, non d’un champ CMP.

Le mot « accordé » semble clore le dossier. Dans une interface d’enrôlement, la ligne passe au vert : la réponse vient de l’autorité attendue, l’identifiant de transaction correspond et le certificat peut être décodé. Pourtant, la RFC 9810 conserve deux issues positives. L’une confirme une correspondance exacte. L’autre avertit que l’objet signé n’est pas exactement celui qui a été demandé.

Cette seconde issue n’est pas une anomalie. Une autorité de certification peut appliquer sa politique, raccourcir une période de validité, normaliser un nom, attribuer un numéro de série, refuser une extension ou construire le certificat selon un profil reconnu. Elle demeure responsable de ce qu’elle signe. Le demandeur demeure responsable de ce qu’il accepte et déploie. Le statut grantedWithMods garde cette frontière visible.

La demande est une intention, pas un ordre à l’émetteur

Publiée en juillet 2025 sur la voie des standards de l’IETF, la RFC 9810 décrit le protocole CMP pour la création et la gestion de certificats X.509. Elle organise les interactions entre entités finales, autorités d’enregistrement et autorités de certification. Elle remplace la RFC 4210 et, avec la RFC 9811, remplace aussi la RFC 9480.

Le demandeur exprime le contenu souhaité par un CertTemplate. Sa structure reprend celle de la partie signée d’un certificat, avec des champs facultatifs ou dépendants du contexte. La clé publique, le sujet, la validité et des extensions peuvent donc apparaître dans la demande. Un client peut même demander au préalable un modèle indiquant les données attendues par l’autorité.

Mais le modèle n’est pas un contrat d’identité bit à bit. La RFC dit expressément que l’autorité peut modifier des champs, même si l’émetteur de la demande les avait tous précisés. Elle fournit alors un vocabulaire honnête : accepted pour une réponse exacte, grantedWithMods pour une réponse proche dont les différences doivent être constatées par le demandeur.

Une automatisation qui traduit ces deux états par le même booléen « succès » retire une information de gouvernance que le protocole avait pris soin de transmettre. Elle attribue à un défaut d’interface le pouvoir d’accepter l’écart.

Certains écarts changent la portée du pouvoir

La RFC 5280 montre pourquoi une comparaison sémantique est nécessaire. La partie signée d’un certificat comprend notamment l’émetteur, la période de validité, le sujet, la clé publique et les extensions. Ces champs ne sont pas de simples ornements.

Key Usage limite des opérations comme la signature numérique, le chiffrement de clé, l’accord de clé, la signature de certificats ou de listes de révocation. Extended Key Usage associe la clé à des finalités. Basic Constraints peut faire d’un certificat une autorité de certification et limiter un chemin. Les noms alternatifs peuvent définir l’identité d’un service. Une politique de certificat peut indiquer le cadre dans lequel une partie utilisatrice évalue l’objet.

Il faut donc classer les écarts. Un numéro de série choisi par l’autorité est normal. Une validité plus courte peut réduire le risque. Une normalisation prévue par le profil peut être sans conséquence. En revanche, une nouvelle EKU, un autre nom de service, une clé publique différente, une contrainte élargie ou une extension critique inconnue peut transformer l’autorité opérationnelle.

La RFC 9810 donne un exemple décisif : certaines EKU pour les rôles de gestion PKI délèguent une autorisation qui appartenait initialement au certificat de l’autorité. Le texte qualifie cette délégation d’action sensible et exige une attention particulière. Une modification peut donc être licite tout en demandant une approbation beaucoup plus forte qu’un simple accusé de réception.

Authentifier le message ne résout pas le contenu

CMP lie les messages à une transaction grâce à leur protection, aux identifiants et aux nonces. La preuve de possession peut démontrer le contrôle de la clé privée. Une autorité d’enregistrement peut vérifier, autoriser, protéger ou transformer une demande selon le profil applicable.

Ces contrôles répondent à des questions indispensables : qui a envoyé le message, à quelle transaction il appartient, si la clé est détenue, si le chemin de réponse est cohérent. Ils ne répondent pas à une autre question : le certificat finalement signé correspond-il à la décision locale que le propriétaire du service voulait mettre en production ?

Quand une autorité d’enregistrement modifie une demande, le dossier utile doit séparer la valeur proposée par l’entité finale, la transformation de l’AE, la valeur signée par l’AC et la règle qui autorisait la transformation. Dire seulement que l’AE a « validé » la demande efface la chaîne de responsabilité.

La confirmation est le dernier point de retour

Le message certConf permet au client d’accepter ou de rejeter les certificats reçus. Pour un certificat indiqué, l’absence de statusInfo signifie l’acceptation. L’absence de la structure correspondante signifie le rejet ; une séquence vide peut tous les rejeter. Le client peut aussi associer le hachage du certificat à un statut explicite de rejet.

Cette étape ressemble à une fermeture de protocole. Elle est en réalité le dernier point où l’écart peut être refusé avant qu’un certificat ne devienne un état ordinaire du système. La décision doit porter sur le certificat délivré, et non seulement sur l’identifiant de la demande ou sur la présence d’une signature valide.

Le profil CMP léger décrit la séquence complète. Après une réponse accepted ou grantedWithMods, une confirmation explicite est envoyée, sauf si implicitConfirm a été demandé et accordé. L’option implicite économise un aller-retour. Elle ne transforme pas un certificat non examiné en certificat acceptable.

Dans un parc d’équipements, cette nuance est essentielle. Si l’enrôlement demande une confirmation implicite, l’évaluateur local doit avoir déjà codé les différences permises, les différences interdites et les exceptions soumises à approbation. Sinon, le gain de latence devient une acceptation anticipée de transformations inconnues.

Politique et pratique expliquent la légitimité d’une modification

La RFC 3647 distingue la politique de certification, qui fixe des exigences pour une communauté ou une classe d’applications, de la déclaration des pratiques de certification, qui explique comment une autorité met en œuvre ses procédures et contrôles. Le statut CMP ne peut pas transporter toute cette justification institutionnelle.

Une réduction de durée peut découler du profil. Une extension peut être imposée pour une flotte gérée. Une identité demandée peut être rejetée faute d’éléments suffisants. Chacun de ces changements peut être correct du point de vue de l’autorité et néanmoins incompatible avec l’usage local projeté. Le demandeur doit connaître le profil précis, sa version et la personne ou la règle capable d’accepter l’écart.

Cette discipline évite l’excès inverse : considérer tout champ choisi par l’autorité comme suspect. Le reçu doit distinguer les valeurs légitimement détenues par l’émetteur des valeurs que le demandeur avait autorisées pour son service. Il ne recherche pas l’identité binaire ; il rend les droits de décision inspectables.

La transparence de publication n’est pas une acceptation

La transparence des certificats rend l’émission observable. La RFC 9162 décrit des journaux append-only permettant de surveiller l’activité des AC et de repérer des certificats suspects. Elle précise aussi que les journaux n’empêchent pas eux-mêmes une émission erronée.

Une entrée de journal ne prouve donc ni l’acceptation par le demandeur, ni l’adéquation à l’intention locale, ni l’autorisation de déploiement. La RFC 9810 sépare même explicitement confirmation et publication dans un cas de preuve indirecte de possession : le certificat final ne doit pas être publié dans CT avant la réception du certConf qui complète cette preuve.

Un certificat peut être public et rejeté localement. Il peut être accepté puis jamais installé. Il peut fonctionner pour un service et être refusé pour un autre. L’émission, la confirmation, la publication, le déploiement et l’usage observé ont besoin d’états distincts.

Un reçu d’intention conserve la comparaison

Le reçu d’intention du certificat proposé commence par des empreintes canoniques de la demande protégée, du CertTemplate, du profil applicable et du certificat délivré. Il conserve l’identifiant de transaction et le statut, mais jamais la clé privée, le secret partagé, le paquet de clé centrale déchiffré ou des preuves d’identité inutiles.

Il produit ensuite un delta normalisé : clé publique, sujet et noms alternatifs, validité, Key Usage, EKU, Basic Constraints, politiques, contraintes de nom, criticité et extensions nécessaires à l’application. Chaque différence matérielle reçoit une qualification : attendue par le profil, approuvée par un rôle autorisé, rejetée ou non résolue. L’évaluateur et la version de politique sont enregistrés.

L’acceptation reste distincte de la publication et du déploiement. Le reçu indique si la confirmation fut explicite ou implicite, qui pouvait accepter pour cette classe de service, quelle exception expire à quelle date, quel certificat sert de retour arrière et si une révocation ou une réémission a corrigé l’état. Une correction ajoute une nouvelle décision ; elle n’efface pas l’ancienne.

Ce registre est local et à accès limité. Même lorsqu’un certificat est public, les noms internes, identifiants d’équipement, exceptions et métadonnées d’enrôlement peuvent révéler une infrastructure sensible. Le but est de préserver la filiation de la décision, non de créer un nouvel inventaire public.

Le code exécuté doit garder la nuance du protocole

La distinction proposée par Heng Lu entre spécification, décision locale, adoption, exécution et résultat observé empêche de faire d’une réponse de protocole une autorité universelle. La RFC définit les états. L’AC choisit ce qu’elle signe. Le demandeur choisit ce qu’il accepte. Le propriétaire du service choisit ce qu’il déploie. Les parties utilisatrices produisent ensuite leurs propres décisions de confiance.

La primauté du code exécuté ne signifie pas que tout certificat automatiquement installé devient légitime. Elle exige que l’exécution soit comparée à la règle annoncée. Si le logiciel fusionne accepted et grantedWithMods, il masque précisément l’événement qu’il faudrait pouvoir contrôler.

La conclusion est étroite. Les autorités peuvent modifier des demandes, et l’automatisation peut accepter sans intervention humaine lorsque les règles sont explicites. Mais elle doit automatiser la bonne question : quelle autorité a changé, pourquoi ce changement est-il permis, et qui avait le droit d’accepter le certificat réel ?

Sources