Résumé

  • BRSKI-AE attache à la demande la preuve de possession de la nouvelle clé et la preuve d’origine fondée sur l’IDevID du pledge ; une AR distante peut donc les vérifier après stockage ou relais.
  • L’objet signé rend la décision possible, mais ne décide pas. Même si l’AR est déportée, RFC 9733 interdit de contourner le registrar dans l’acceptation du pledge au sein du domaine.
  • Voucher, autorisation, certificat, confirmation, télémétrie d’enrôlement et accès au réseau sont des constats différents. Les fusionner fabrique une réussite qui n’a pas été observée.

Dans une sous-station isolée, la liaison vers l’infrastructure de clés ne revient que quelques minutes par jour. Le nouvel équipement peut parler au registrar local, mais l’autorité d’enregistrement centrale se trouve ailleurs. Sa demande part dans une file, attend, franchit plusieurs systèmes puis reçoit une réponse après la disparition de la session qui l’a vue naître. Il faut pourtant pouvoir répondre à une question élémentaire : qui a demandé quoi, avec quelle clé ?

RFC 9733 apporte une réponse précise. La demande de certification devient un objet authentifié autonome. Elle prouve à la fois la possession de la clé privée appelée à recevoir le LDevID et l’origine de la demande au moyen de l’IDevID installé lors de la fabrication. Ces preuves ne dépendent plus seulement du premier tunnel TLS ; elles restent vérifiables par une autorité distante.

La portée de ce progrès doit rester étroite. Un objet capable de conserver son origine n’acquiert pas le pouvoir de choisir son domaine, d’approuver ses attributs ou d’ordonner à une autorité de certification d’émettre. Il transporte une preuve, pas un mandat.

Deux questions que le mot « identité » masque souvent

La preuve de possession répond à la question de la clé. Une demande PKCS #10 est généralement autosignée avec la nouvelle clé ; CRMF prévoit aussi des méthodes adaptées aux clés qui ne savent pas signer. Le résultat montre que l’émetteur de la demande contrôle le secret correspondant à la clé publique proposée.

Cette autosignature ne dit pas encore qui contrôle ce secret. Une paire de clés neuve ne possède aucune identité reconnue. La preuve d’identité — ou preuve d’origine dans RFC 9733 — lie la demande à un titre déjà authentifié. Dans BRSKI-AE, le pledge signe normalement avec le secret de son IDevID et couvre un identifiant robuste, tel que son numéro de série.

Ces vérifications ne sont pas interchangeables. Un attaquant peut posséder parfaitement sa propre clé sans être un pledge admis. Un appareil authentique peut demander un nom, un rôle ou un usage incompatible avec la politique du domaine. Une demande peut passer les deux contrôles cryptographiques et rester refusée pour des raisons d’inventaire, de propriété, de révocation ou de risque.

Le journal doit donc conserver séparément le résultat de possession, le résultat d’origine et la décision de politique. L’étiquette « signature valide » est trop pauvre pour expliquer un refus et trop large pour justifier une émission.

Sortir la preuve de la session

BRSKI s’appuie traditionnellement sur EST. EST peut relier une demande PKCS #10 à l’authentification du pledge dans la session TLS qui le connecte au registrar. Le premier pair dispose alors d’un élément utile. Mais une seconde AR, placée derrière le registrar, ne peut pas nécessairement revérifier ce lien transitoire. Elle reçoit une affirmation relayée plutôt que l’objet original de la preuve.

BRSKI-AE adopte des protocoles d’enrôlement dont les messages s’authentifient eux-mêmes. L’instanciation normative utilise CMP selon le profil léger LCMPP. La protection du PKIMessage peut établir l’origine IDevID, tandis que CRMF ou PKCS #10 établit la possession de la future clé LDevID. Le registrar peut transférer cet ensemble sans reconstruire l’identité à chaque saut.

Cette architecture convient aux sites intermittents, aux AR hors site et aux traitements asynchrones. Elle permet aussi une répartition plus nette : le registrar reste le gardien local, l’AR centrale applique une politique plus riche, l’AC produit le certificat. La preuve circule entre eux sans absorber leurs compétences.

L’indépendance vis-à-vis du transport n’abolit pas le transport. Entre pledge et registrar, RFC 9733 conserve le canal TLS ou DTLS existant. Entre registrar et PKI, le mécanisme d’échange reste hors périmètre. Les messages CMP sont authentifiés, mais pas chiffrés par nature. Sans protection complémentaire, un observateur peut apprendre quels équipements rejoignent le domaine ou bloquer sélectivement leur enrôlement.

Le voucher ouvre une confiance, pas un droit d’accès

Avant toute demande LDevID, le pledge exécute l’échange de voucher de BRSKI avec le registrar et la MASA. Le voucher lui fournit l’ancre avec laquelle il reconnaîtra le domaine cible, souvent sous la forme du pinned-domain-cert. Cette étape évite qu’un équipement confié à un domaine accepte simplement le premier serveur venu.

Mais le voucher n’est pas le certificat local du pledge. Il ne prouve ni que l’AR a accepté la demande, ni que l’AC a émis, ni que l’équipement a installé le résultat. Il établit la base de confiance à partir de laquelle la réponse d’enrôlement pourra être évaluée.

Le pledge génère ensuite son secret LDevID, forme la demande autonome et la remet au registrar. Avec CMP, la réponse doit être validée à partir de l’ancre reçue par le voucher. Les deux chaînes s’articulent : le voucher indique à quel domaine faire confiance ; la PKI de ce domaine décide si cette clé et ces attributs recevront un certificat.

Un tableau de bord qui réduit les deux à « appareil approuvé » rend les incidents inexplicables. Il faut pouvoir voir un voucher accepté suivi d’un rejet de politique, ou un certificat émis après une preuve de consentement précise.

Le registrar doit laisser sa propre trace

RFC 9733 protège explicitement le rôle du registrar. Celui-ci peut déléguer une partie ou la totalité du travail d’AR à un système distant, mais il doit participer à la décision d’accepter le pledge dans le domaine. La CA ne doit pas devenir un chemin de contournement.

Le consentement peut être implicite dans une architecture strictement gouvernée, inscrit dans une base, transmis dans un message séparé ou signé directement. Pour CMP, le texte recommande que le registrar enveloppe la demande originelle dans un message imbriqué signé avec ses propres identifiants. L’AR distante reçoit alors deux énoncés indépendants : voici la demande authentique du pledge ; voici le consentement du registrar à son traitement.

Conserver la demande initiale évite qu’un intermédiaire en donne une traduction avantageuse. Ajouter la signature du registrar évite qu’une identité d’usine soit interprétée comme une permission locale. L’AR peut encore refuser. L’AC n’émet qu’après les validations et autorisations requises. Aucun certificat valide du fabricant ne contraint automatiquement la politique du domaine opérateur.

Le temps asynchrone fait évoluer le contexte

La connectivité intermittente est un motif central de BRSKI-AE. Un objet autosuffisant peut attendre que la capacité soit disponible sans perdre sa preuve d’origine. Mais la durée ouvre un écart entre la vérité cryptographique et la décision courante.

Pendant l’attente, le propriétaire peut changer, le consentement être retiré, un profil de certificat évoluer ou une ancre tourner. La même demande peut être livrée deux fois. Une réponse peut être émise puis perdue. Une signature toujours correcte ne prouve pas que la politique qui l’entourait est toujours valable.

Le système d’exploitation doit relier durablement le voucher, l’empreinte de la clé demandée, les résultats IDevID et possession, le consentement du registrar, l’identifiant de transaction, la décision de l’AR, la réponse de l’AC et l’empreinte du certificat. Une reprise doit distinguer un résultat perdu d’une autorisation absente. L’âge de la file doit être une donnée de politique, pas un simple compteur de transport.

Après l’émission, plusieurs fins demeurent

Une réponse positive contient le certificat et peut fournir des certificats intermédiaires ou d’autres ancres. CMP autorise ensuite une confirmation facultative. Le pledge, après validation, indique si le certificat a été enrôlé correctement et correspond à son besoin. La PKI ou le registrar accuse réception de cette confirmation.

Ce dialogue ne doit pas être confondu avec la télémétrie finale BRSKI entre pledge et registrar, que RFC 9733 maintient comme phase distincte et obligatoire. La confirmation CMP informe la PKI sur l’évaluation du certificat ; la télémétrie BRSKI informe le registrar sur l’issue de l’enrôlement. Leurs destinataires et leurs responsabilités diffèrent.

Il reste enfin le monde opérationnel. Le certificat doit être installé, présenté, accepté par le contrôle d’accès et associé à une configuration utile. Un certificat émis peut rester inutilisé. Un enrôlement réussi peut précéder un refus réseau. Une admission réseau peut précéder l’échec de la fonction industrielle attendue.

La phrase honnête énumère les étapes : voucher accepté, origine et possession vérifiées, consentement du registrar enregistré, AR favorable, certificat émis, confirmation reçue, télémétrie reçue, admission non encore observée. La longueur est un avantage : elle empêche une preuve locale de coloniser les couches suivantes.

Découvrir un protocole ne découvre pas une autorité

RFC 9733 généralise les URI en /.well-known/<enrollment-protocol>/<request> et enregistre le service brski-reg-cmp pour une découverte CMP minimale. Un pledge peut tester un endpoint et lire le statut HTTP afin de connaître une fonction disponible.

Ce nom commun organise l’interopérabilité. Il ne désigne pas à lui seul le registrar légitime de ce pledge, ne garantit pas l’accès au backend et ne préjuge pas de la décision CMP. Une réponse HTTP peut attester la réception alors que l’opération interne attend ou échoue. L’endpoint, le pair TLS, l’ancre de domaine, le protocole, la transaction et le décideur doivent rester corrélés.

Aucune source gelée n’établit qu’un constructeur, un réseau ferroviaire, une sous-station ou un opérateur de recharge précis a déployé RFC 9733. Les cas d’usage expliquent le besoin ; ils ne sont pas des annonces de production. La norme apporte une mécanique et une discipline de preuve, non un inventaire du marché.

Sources