Résumé

  • RFC 9908 permet à un serveur EST de fournir des valeurs imposées, des types de champs requis et des emplacements que le client complètera dans une future demande PKCS #10.
  • Ce modèle atteste une consigne de construction ; la possession de la clé, l'authentification, l'autorisation, la décision de l'AC, le certificat délivré et son usage exigent chacun leur propre preuve.

Un automate reçoit une réponse /csrattrs. Elle impose une unité organisationnelle, demande au terminal de choisir son nom commun, exige une clé sur P-256 et laisse une adresse à compléter dans le subjectAltName. Le logiciel de supervision conclut aussitôt : « identité approuvée ». Pourtant, aucune CSR signée n'a encore été transmise et aucune autorité de certification n'a décidé de délivrer quoi que ce soit.

Cette scène est hypothétique. Elle montre cependant un défaut de gouvernance fréquent : plus une instruction est structurée, plus on lui prête volontiers le pouvoir des étapes qui viennent après elle. RFC 9908 rend la consigne plus rigoureuse. Il oblige donc les exploitants à rendre aussi rigoureuse la chaîne de décision.

Le texte met à jour EST, RFC 7030, ainsi que sa déclinaison sur CoAP, RFC 9148. EST permettait déjà au client de demander quels attributs l'autorité attendait dans sa demande de certificat. L'encodage des identifiants et surtout des valeurs d'attributs avait suscité des interprétations divergentes. RFC 9908 les clarifie et ajoute une méthode plus directe.

Le nouvel objet CertificationRequestInfoTemplate ressemble à la partie informative d'une demande PKCS #10, mais sans l'enveloppe de signature et avec des champs volontairement facultatifs. C'est un gabarit partiellement rempli. Il ne constitue ni la demande achevée, ni le certificat final.

L'absence et la présence d'un champ ont des sens précis. Si le serveur n'impose rien au nom distinctif du sujet, subject est absent. S'il demande un type de RDN, celui-ci figure dans le modèle. Une valeur fournie doit être reprise ; un type présent sans valeur doit être complété par le client. Pour subjectPKInfo, l'absence signifie qu'aucune exigence de clé n'est exprimée à cet endroit. La présence fixe l'algorithme attendu ; dans le cas d'une taille RSA, une valeur factice peut matérialiser la longueur du module.

Le nouvel attribut id-aa-extensionReqTemplate traite les extensions de la même manière. Le serveur peut nommer l'extension, fournir sa valeur entière, l'omettre ou n'en remplir qu'une partie. Il peut ainsi imposer une entrée de SAN et laisser au client un autre emplacement à renseigner. RFC 8994 explique pourquoi cette capacité est utile au plan de contrôle autonome, où une valeur précise de subjectAltName doit être transmise lors de l'enrôlement.

La compatibilité n'est pas abandonnée. La structure CsrAttrs sur le fil reste celle d'EST. La version du nouveau modèle vaut v1 ; plusieurs attributs de modèle d'extensions sont interdits, tout comme l'association simultanée de l'ancien id-ExtensionReq et du nouveau id-aa-extensionReqTemplate. Le transport contraint d'EST reçoit la même clarification.

Il serait toutefois faux de lire ce gabarit comme une délégation d'autorité. RFC 7030 indique que la demande de /csrattrs est facultative et que sa réponse ne devrait normalement pas exiger l'authentification ou l'autorisation du client. Il précise surtout que, quelle que soit cette réponse, le serveur EST et l'AC peuvent rejeter l'enrôlement ultérieur pour n'importe quelle raison. Recevoir la recette n'accorde pas le droit au produit fini.

La véritable demande introduit d'autres contrôles. Le serveur authentifie le client et vérifie son autorisation à utiliser le service demandé. La signature de la CSR sert de preuve de possession lorsque la clé privée concernée peut signer. EST peut aussi lier la demande signée à la session TLS authentifiée. RFC 5272 fournit à CMC, utilisé par EST, le cadre plus général des preuves de possession.

Ces faits ne sont pas interchangeables. La preuve de possession établit un rapport entre une clé publique et une clé privée contrôlée. L'authentification établit quelle identité de canal le serveur a acceptée. L'autorisation décide si cette identité peut obtenir un certificat portant ces noms et ces usages. Posséder une clé ne donne aucun droit automatique sur un nom DNS ; être authentifié auprès du service ne rend pas chaque SAN légitime.

La décision de l'AC demeure indépendante. RFC 7030 la soumet toujours à la politique locale de l'autorité et prévoit même une vérification manuelle, signalée au client par une réponse 202. PKCS #10 décrit pareillement une autorité qui authentifie le demandeur, vérifie la signature puis, si la demande est recevable, construit le certificat avec ses propres choix et d'autres informations disponibles.

Le certificat délivré est donc un nouvel artefact. Son empreinte, son numéro de série, sa durée, ses extensions et ses contraintes doivent être lus dans le certificat signé, non déduits du modèle. La comparaison entre modèle, CSR achevée, journal de décision et certificat permet de voir ce qui a été imposé, proposé, modifié, refusé ou ajouté.

La chaîne ne s'arrête pas à la signature de l'AC. RFC 5280 encadre le profil X.509 et la validation des chemins par les parties utilisatrices. Un certificat délivré peut ne jamais être installé, être posé sur le mauvais équipement, rester en parallèle de l'ancien ou être rejeté par une politique de confiance. Le déploiement et les poignées de main observées sont encore d'autres réalités.

Un dossier d'audit solide conserve d'abord les octets exacts de /csrattrs, l'identité du serveur, l'heure, la durée de cache et l'empreinte du modèle. Il distingue les valeurs fixées, les cases à compléter et les champs absents. Il rattache ensuite la CSR finale à cette version, puis enregistre la validation de signature, la preuve de possession, l'identité authentifiée, la politique d'autorisation, la décision de l'AC, l'empreinte du certificat, la cible d'installation et les observations réseau.

Un champ absent du modèle ne prouve rien au-delà de l'absence d'exigence exprimée par ce champ. Il ne rend pas une valeur ultérieure licite ou illicite. De même, une SAN imposée prouve que le serveur a demandé au client de la soumettre ; elle n'explique pas sur quelle preuve l'organisation s'est fondée pour l'autoriser. Cette provenance appartient au dossier de décision.

La transition vers les nouveaux attributs doit être pilotée. La compatibilité de l'encodage ne signifie pas que chaque client ancien interprétera correctement un modèle partiel. Il faut connaître les capacités du parc, interdire qu'un client ignore silencieusement une exigence et définir une voie de repli explicite vers l'ancienne forme lorsque la politique l'accepte.

Le retour arrière dépend enfin de l'étape atteinte. On peut retirer un modèle fautif, vider un cache ou refuser une CSR en attente. Une fois les certificats signés et déployés, revenir au modèle précédent ne les efface pas. Révocation, remplacement, terminaux hors ligne et comportement des parties utilisatrices deviennent des décisions spécifiques.

La primauté du code en fonctionnement formulée par Heng Lu rappelle qu'une publication n'est pas une exécution. Le minimum initial et la décision localisée empêchent aussi une sémantique commune étroite de se transformer en autorité implicite.

Les couches de réalité donnent ici la bonne grammaire : consigne, demande, possession, identité, autorisation, artefact signé et usage observé ne répondent pas à la même question. Enfin, la distinction entre capacité technique et autorité pratique ou juridique interdit de confondre la capacité d'inscrire un nom dans une CSR avec le droit de le revendiquer.

RFC 9908 améliore EST parce qu'il décrit mieux la demande attendue. La meilleure façon d'en respecter la précision est de ne pas lui attribuer les décisions suivantes. Le modèle instruit. Le client complète et signe. Le serveur authentifie. La politique autorise. L'AC délivre. L'opérateur installe. La partie utilisatrice valide. La confiance vient de cette séparation vérifiable.

Sources