Résumé

  • RFC 9646 organise deux appels à get-bootstrapping-data, séparés par une réponse HTTP 400 qui transporte la sélection du serveur.
  • La signature du CSR prouve la possession de la clé privée correspondante ; elle ne prouve pas à elle seule l’origine, l’approbation par la CA, la livraison, l’installation ou l’usage autorisé.
  • Le message intermédiaire ne pouvant pas être signé comme les données d’amorçage de RFC 8572, ce mécanisme ne doit pas traverser un serveur d’amorçage non fiable.

Un code d’erreur qui sert de bon de travail

RFC 9646 complète l’amorçage sécurisé sans intervention afin qu’un équipement obtienne une identité destinée à son environnement de production. Son enchaînement oblige à abandonner une lecture trop simple des classes HTTP.

Lors du premier appel, le client SZTP ajoute csr-support. Il annonce sa capacité à créer une nouvelle paire asymétrique, les algorithmes de clé pris en charge et les formats de demande qu’il sait produire. Le serveur qui souhaite un CSR répond par un HTTP 400 et place dans error-info une structure csr-request. Celle-ci choisit l’algorithme, le format et, éventuellement, le contenu demandé dans le certificat.

Le client effectue alors un second appel. Il transmet un objet PKCS #10, CMC ou CMP conforme à la sélection. Le serveur, éventuellement assisté d’une autorité d’enregistrement et d’une autorité de certification, vérifie la demande. Si la politique l’accepte, l’information d’enrôlement peut rapporter le certificat signé.

Le 400 n’est donc ni un succès d’identité ni un échec final. C’est une transition attendue. Le journal doit conserver le statut HTTP et son sens dans l’état du protocole, sans autoriser l’un à effacer l’autre.

Trois messages, trois portées

csr-support décrit un éventail. Il ne prouve pas qu’une clé a été créée, que l’aléa était suffisant ou que le secret est resté dans un TPM. La sélection du serveur réduit cet éventail, mais reste une consigne. Le CSR retourné atteste l’exécution d’une partie de cette consigne ; il ne porte pas toute la décision institutionnelle qui suit.

Cette séparation rejoint la Spécification initiale minimale de Lu Heng. L’interopérabilité commune doit être assez précise pour transmettre la décision suivante, sans transformer une structure partagée en politique universelle de délivrance. RFC 9646 décrit le passage de relais. Chaque organisation conserve son autorité sur les attributs, les validations, l’installation et l’autorisation applicative.

Une plateforme qui agrège les trois étapes sous « CSR reçu » perd le diagnostic. Elle ne sait plus si l’équipement avait seulement annoncé une capacité, si le serveur avait choisi une option non annoncée, si une clé avait été réutilisée, ou si la deuxième requête correspondait bien au premier échange.

Posséder une clé ne suffit pas à établir l’origine

La preuve de possession est claire : la clé publique apparaît dans le CSR, et la demande est signée par la clé privée correspondante. Vérifier cette signature montre que le créateur de l’objet contrôlait le secret. C’est un résultat cryptographique précis.

L’origine répond à une autre question : quel équipement ou quel principal autorisé a produit la demande ? Un PKCS #10 brut n’intègre pas de mécanisme d’authentification d’origine. Il peut dépendre de l’identité TLS ou HTTP de la session. Dans ce cas, conserver le CSR sans le contexte de transport revient à perdre la moitié de la preuve.

CMC et CMP peuvent transporter une authentification d’origine fondée sur une PKI ou un secret partagé. Ils permettent aussi une étape d’autorité d’enregistrement avant la CA. Ce supplément de structure n’accorde pas automatiquement le certificat : le vérificateur doit toujours contrôler la chaîne IDevID, le secret ou la protection du protocole, puis appliquer une politique de délivrance.

Lorsque l’équipement réutilise la clé de son identité initiale, l’origine suppose de valider le chemin de certification IDevID et de constater que le CSR emploie la même paire. Avec une clé locale neuve, CMC ou CMP peut lier la nouvelle demande à l’identité du fabricant ou à un secret. Appeler ces deux parcours « CSR valide » ferait disparaître leur différence de responsabilité.

La fraîcheur est une propriété conditionnelle

RFC 9646 recommande une nouvelle clé privée pour chaque CSR. Si elle est réellement créée après la demande du serveur, son aléa joue aussi le rôle d’un nonce. Le retour d’un certificat signé contenant cette nouvelle clé publique fournit alors un indice que la réponse appartient à l’échange courant.

La propriété doit être prouvée. Un libellé key-generation ne suffit pas si l’empreinte existe déjà. Le choix change aussi lorsque l’équipement ne peut pas protéger une clé neuve aussi bien que sa clé de fabricant. Le RFC préfère alors la réutilisation de la clé intégrée mieux protégée à la création d’un secret plus exposé. La fraîcheur réduit certains risques de rejeu ; la garde matérielle réduit certains risques d’usurpation. Une décision honnête explicite cet arbitrage.

La clé dynamique doit être protégée contre la divulgation. Un HSM ou TPM est recommandé. En l’absence d’une telle protection, une rotation périodique raccourcit l’exposition. L’identité de déploiement et sa clé neuve sont des données utilisateur : une remise à l’état d’usine doit les effacer. Le reçu d’enrôlement doit donc avoir une fin de vie.

Le message non signé trace une frontière dure

RFC 8572 prévoit qu’un client puisse contacter un serveur qu’il ne considère pas encore comme fiable et s’appuyer sur des données d’amorçage signées. L’extension CSR ne peut pas reprendre cette garantie : csr-request réside dans une erreur HTTP, et cette erreur ne peut pas être signée comme ces données.

RFC 9646 en tire une conclusion nette. Le mécanisme ne peut pas être employé avec un serveur d’amorçage non fiable. Le client ne devrait pas lui envoyer csr-support; il devrait demander signed-data-preferred. Accepter malgré tout une sélection d’algorithme, de format ou de contenu reviendrait à laisser une partie non authentifiée façonner la future identité de production.

Un CSR ultérieur parfaitement formé ne répare pas cette rupture. Il peut prouver la possession d’une clé créée sous l’instruction du mauvais acteur. La validation cryptographique d’une étape ne prête pas rétroactivement son autorité au début de la chaîne.

La CA, le transport et l’usage restent séparés

Après réception, le serveur, la RA ou la CA vérifie possession et origine, puis décide. Inventaire, propriété, attributs demandés et règles de l’organisation peuvent intervenir. La signature du CSR ne remplace aucune de ces autorisations.

Le RFC ne prescrit pas comment insérer le certificat signé dans l’information d’enrôlement. Ses exemples utilisent notamment une configuration compatible avec le keystore de RFC 9642, mais le mode de transport reste hors périmètre. Délivrer et acheminer sont donc deux résultats.

Installer est un troisième résultat. Il faut associer le certificat à la bonne clé, valider le commit et vérifier que le service attendu l’a sélectionné. Le premier échange authentifié réussi constitue encore une autre observation. Une réponse 200 contenant de l’information d’enrôlement n’atteste pas à elle seule ces effets.

La Primauté du code en fonctionnement impose de privilégier les transitions exécutées. Les modules YANG rendent l’échange lisible ; ils ne racontent pas spontanément ce que la CA, le datastore et le service ont réellement fait.

Composer le reçu

Le dossier commence par l’identité du serveur, sa chaîne de confiance et les faits d’authentification TLS et HTTP. Il conserve le premier appel : nonce, identifiants matériels et logiciels, algorithmes et formats annoncés. Il enregistre ensuite le 400 comme transition, avec le csr-request exact, la sélection, le contenu demandé, l’heure et l’identifiant de corrélation.

La cérémonie de clé indique création ou réutilisation, empreinte publique, source d’aléa, frontière de protection et propriété de fraîcheur attendue. Le second appel conserve le format et le condensat du CSR. Possession et origine reçoivent deux verdicts, avec la chaîne IDevID, le secret, l’identité TLS ou l’identité HTTP qui soutient le second.

Enfin viennent la décision RA/CA, le certificat émis, son mode de transport, son installation, la première utilisation et l’effacement ou la rotation. Les couches de réalité empêchent ici l’abus le plus séduisant : transformer une couleur rouge, une signature valide ou un certificat livré en conclusion sur toute la chaîne.

Sources