Résumé

  • La RFC 9908 est une norme proposée par l’IETF, publiée en janvier 2026, qui met à jour les RFC 7030 et 9148.
  • Elle clarifie l’encodage des attributs CSR en séparant l’OID d’attribut de la valeur attendue, notamment pour les extensions X.509.
  • CertificationRequestInfoTemplate permet au serveur EST de contraindre certaines parties de la demande tout en laissant au client les valeurs explicitement non fournies.

Analyse de Theo March : le changement essentiel n’est pas l’apparition d’une décision d’approbation dans EST. Il s’agit de faire de /csrattrs une description précise de la forme de la demande. Le serveur peut envoyer un CertificationRequestInfoTemplate partiellement rempli. Il peut fournir la valeur d’un RDN, que le client est alors censé reprendre, ou inclure le RDN sans sa valeur afin que le client fournisse une valeur appropriée. Le champ subject est optionnel : il est présent lorsque le serveur impose des exigences sur les RDN.

La même discipline de présence et d’absence concerne les informations de clé publique. subjectPKInfo est absent lorsque le serveur n’a aucune exigence de clé ; lorsqu’il est présent, son algorithme indique le type de paire de clés attendu. subjectPublicKey est normalement absent. L’exception particulière est un paramètre fictif servant à exprimer une exigence de longueur de module RSA. Ce paramètre n’est pas la clé publique finale du client et ne doit pas être traité comme telle.

Le besoin est concret pour l’enrôlement ACP et BRSKI décrit par les RFC 8994 et 8995 : le serveur doit pouvoir transmettre un subjectAltName précis via /csrattrs. La RFC 9908 clarifie l’encodage de cette exigence ainsi que celui des extensions X.509. Le modèle impose une contrainte sur les informations de la CSR ; il ne constitue ni une signature de CSR, ni une approbation de certificat, ni une authentification, ni une politique d’AC. L’authentification de l’enrôlement EST et la décision de l’AC restent distinctes.

L’interopérabilité doit être vérifiée au niveau des octets. Comparer l’OID encodé et sa valeur associée ; contrôler la présence ou l’absence ASN.1 de subject, subjectPKInfo et subjectPublicKey ; vérifier qu’une valeur de RDN est réellement encodée ou volontairement omise ; et s’assurer que le paramètre de longueur RSA n’est pas réutilisé comme clé générée. Produire ensuite la CSR et comparer son CertificationRequestInfo DER aux exigences du modèle, notamment au subjectAltName, avant d’examiner la chaîne de certificats.

Parcours de décision de l’opérateur : conserver les octets de la réponse /csrattrs et son contexte authentifié. Énumérer chaque valeur fixe, chaque blanc destiné au client et chaque structure absente dont la sémantique compte. Refuser un client qui modifie une valeur de RDN fournie, qui transforme une valeur omise en valeur imposée ou qui convertit le paramètre RSA en clé publique. Enfin, vérifier la CSR et le certificat délivré. Le simple fait de décoder le modèle ne suffit pas.

Sources