Résumé

  • draft-mittal-est-coap-ca-certs-00 décrit un mécanisme par lequel une ancre constructeur installée en usine vérifie un paquet CMS de certificats d’autorité opérationnels. C’est un Internet-Draft individuel en révision 00, non une norme, un RFC ou une preuve de déploiement.
  • La connexion de récupération peut rester non authentifiée. La signature porte sur l’objet ; elle ne prouve ni l’identité du serveur de transport, ni la fraîcheur, ni l’acceptation par la politique de l’exploitant.
  • Après validation de la signature, de l’alias, de la séquence, des dates et de la politique locale, le client peut modifier son magasin de confiance. Il doit ensuite créer une nouvelle session TLS ou DTLS et authentifier le serveur avant tout enrôlement.

Le mot « confiance » masque souvent plusieurs décisions. Dans une chaîne d’initialisation, il peut désigner une clé placée en usine, la validité cryptographique d’un objet, l’acceptation d’une nouvelle autorité, l’identité d’un serveur ou le droit d’émettre un certificat. Fusionner ces décisions donne un tableau de bord simple et une enquête d’incident presque impossible.

Le projet individuel draft-mittal-est-coap-ca-certs-00 part d’un problème concret. Un capteur ou un compteur quitte l’usine avant que son futur exploitant ait choisi son infrastructure de certification. Il connaît une ancre du fabricant, mais pas encore l’autorité qui permettra de vérifier le serveur EST de production. Le texte propose donc un objet contenant les nouveaux certificats d’autorité, signé par le fabricant ou par un signataire qu’il a autorisé.

Le serveur qui distribue cet objet n’a pas besoin de détenir la clé du fabricant. Il peut publier une réponse pré-calculée sous un alias propre au domaine constructeur. Plus surprenant encore, le client peut la récupérer par une connexion TLS ou DTLS dont le certificat serveur n’est pas encore accepté. Pour du contenu considéré comme public, un transport HTTP ou CoAP en clair est même envisagé.

La cohérence est possible parce que la preuve porte sur l’objet et non sur la socket. Mais cette solution ne reste sûre que si le logiciel refuse d’élargir la conclusion. Une réponse signée n’authentifie pas le serveur qui l’a remise. Une connexion chiffrée dont le pair n’est pas validé n’est pas une session EST autorisée. Une nouvelle racine installée n’est pas un certificat de dispositif déjà obtenu.

Le distributeur peut être un relais sans devenir une autorité

La structure proposée, ManufacturerSignedCACerts, contient une version, un alias, un numéro de séquence croissant, une date de début, une date de fin et un ou plusieurs certificats d’autorité. CMS SignedData protège l’ensemble. Le client construit le chemin du certificat signataire jusqu’à l’ancre constructeur stockée localement et vérifie que ce signataire est autorisé spécifiquement à signer des réponses d’amorçage.

Le résultat répond à une question étroite : cette clé reconnue a-t-elle protégé ces octets précis, pour cet usage ? Il ne dit pas qui administre le nom DNS, l’adresse ou le service qui les a envoyés. Un cache, un miroir ou un attaquant peut relayer un objet authentique. Ce relais peut convenir à la distribution d’un objet public et immuable ; il ne peut recevoir un CSR, un identifiant durable ou une clé privée par simple contagion de confiance.

Le projet limite donc le canal à la récupération de certificats. Une session HTTPS provisoire ne doit transporter ni demande d’enrôlement, ni informations d’identification du client, ni données sensibles. En EST-coaps, le même principe vaut pour /crts. La confidentialité DTLS peut empêcher l’écoute passive tout en laissant l’identité du serveur non établie. Chiffrement et authentification du pair sont deux colonnes différentes.

Cette séparation permet de garder la clé constructeur hors ligne. Le serveur peut distribuer la même réponse statique à tous les appareils du domaine de confiance correspondant. Il ne doit signer dynamiquement que s’il possède un titre explicite ou un service approuvé. Les journaux du serveur prouvent une livraison ; ceux du signataire prouvent l’autorisation de l’objet. Aucun ne remplace l’autre.

L’alias conduit vers un contexte, il ne donne pas d’ordre

Le chemin peut prendre la forme /.well-known/est/{manufacturer-alias}/cacerts, avec /crts pour la variante CoAP. Un profil peut dériver l’alias d’un numéro d’entreprise IANA, mais le projet n’impose pas une méthode unique et ne demande aucune nouvelle inscription IANA.

Le risque est de laisser le routeur d’URL décider de la confiance. Le texte l’interdit : l’alias seul ne suffit jamais à installer les certificats. L’alias figure aussi dans l’objet signé, et le client doit vérifier qu’il correspond à la requête ou à une équivalence locale explicitement configurée.

Ainsi, un paquet parfaitement signé pour un constructeur ne peut pas être injecté dans le domaine d’un autre. Cette règle illustre une architecture utile : le chemin sélectionne, la signature lie, la politique locale accepte. Quand un système résume les trois par « origine approuvée », il transforme un nom de routage en mandat.

Un reçu exploitable doit garder l’alias configuré, l’URI demandée, l’alias protégé, la règle d’équivalence et le résultat. « Signature CMS valide » ne suffit pas à expliquer une mutation de confiance. « Bon endpoint » ne prouve pas le contenu.

Une signature valable peut protéger un paquet périmé

La cryptographie conserve les attestations ; elle ne les rend pas actuelles. Après une compromission d’autorité opérationnelle, un ancien paquet reste signé. Un dispositif réinitialisé peut oublier la génération déjà acceptée et revenir vers des racines retirées.

Le numéro de séquence et l’intervalle notBefore/notAfter tentent de fermer cette voie. Le client devrait mémoriser, par alias, la plus haute séquence acceptée et refuser les valeurs inférieures. Avec une horloge fiable, il doit vérifier l’intervalle. Sans heure fiable au premier démarrage, il peut s’appuyer provisoirement sur la monotonie, puis réexaminer les dates quand une source authentifiée devient disponible.

Cette disposition fait de la mémoire de séquence un actif de sécurité. Si un retour aux paramètres d’usine l’efface, la protection anti-recul disparaît précisément lors d’une phase vulnérable. Il faut décider où l’état survit, comment traiter deux objets différents avec la même séquence et qui peut autoriser une récupération d’urgence.

Le cache ajoute une seconde horloge. Il réduit le coût d’un déni de service, mais peut continuer à servir une génération retirée. La preuve doit donc joindre le hash de l’objet, la séquence protégée, la séquence précédente, la confiance dans l’heure, l’âge du cache, la version de politique et le hash du nouvel ensemble d’ancres.

La politique locale doit rester une décision réelle

Le projet permet à un paquet validé d’ajouter, de remplacer ou d’étendre les ancres opérationnelles. Il exige aussi l’application de la politique locale de gestion des ancres. La deuxième clause empêche la première de devenir un pouvoir universel du fabricant.

Une signature constructeur montre qu’une proposition provient d’une relation établie à la fabrication. Elle ne tranche pas si l’exploitant accepte la suppression d’une ancienne racine, exige une période de chevauchement, refuse une autorité externe ou impose une fenêtre de maintenance. L’entreprise qui supporte le risque opérationnel doit conserver ce veto.

Le principe de spécification initiale minimale de Lu Heng donne ici un test concret. Les règles communes doivent rendre la preuve déterministe : chemin du signataire, usage dédié, octets exacts, alias, séquence et dates. Le choix futur de l’autorité de production, du calendrier de rotation et des conditions de retrait reste local.

Si toute signature constructeur déclenche automatiquement l’installation, l’amorçage devient un plan de contrôle permanent. La clé du fabricant décide alors quelles institutions le dispositif croira pendant toute sa vie. Ce pouvoir dépasse le problème initial de distribution.

Avant mutation, le logiciel devrait calculer les hashes avant/après, présenter les ajouts et retraits, appliquer des règles propres à la flotte et écrire un reçu append-only. Un refus ne doit jamais conduire à poursuivre sur le serveur non authentifié ; il doit arrêter l’enrôlement.

La nouvelle session est l’épreuve d’identité

Une fois les nouvelles racines installées, le client doit ouvrir une nouvelle connexion. C’est dans cette poignée de main que les ancres opérationnelles servent enfin à valider le nom et la chaîne du serveur.

Poursuivre la connexion provisoire brouillerait les époques. Le pair est apparu avant la modification du magasin. Même si une bibliothèque sait réexaminer son certificat, les paramètres négociés et l’état de canal appartiennent au contexte initial. Une nouvelle session crée une frontière vérifiable entre transport d’amorçage et service authentifié.

RFC 7030 autorise déjà une poursuite provisoire de TLS pour obtenir /cacerts, puis demande une autorisation hors bande et une connexion authentifiée. Le projet remplace l’autorisation manuelle du paquet par une signature fabricant ; il ne supprime pas la reconnexion.

RFC 9148 transpose EST dans CoAP et DTLS, notamment /cacerts vers /crts. Il rend le transport possible sur des appareils contraints sans transformer le serveur qui répond en autorité opérationnelle. Le reçu de nouvelle session doit indiquer le nom attendu, les empreintes de chaîne, l’ancre acceptée, la politique et le résultat.

L’enrôlement reste une transaction indépendante

Même un serveur correctement authentifié peut refuser une demande. Le dispositif doit encore prouver la possession de sa clé, présenter l’identité attendue et satisfaire la politique de l’autorité. Le certificat émis peut ensuite être mal profilé ou inutilisable sur le service visé.

Révision 00 dit expressément qu’elle ne change pas la sémantique EST, la preuve de possession ou la politique de certification. Son objet est la distribution de CA opérationnelles. Il ne valide pas le client, n’approuve pas le CSR et ne démontre aucun résultat réseau.

Une orchestration honnête conserve donc plusieurs états : objet reçu, signataire autorisé, fraîcheur acceptée, politique locale favorable, magasin modifié, nouvelle session authentifiée, enrôlement accepté, certificat installé et service observé. Chaque étape possède son responsable et sa restauration.

Le fabricant protège le signataire d’amorçage. L’exploitant décide du magasin. Le serveur EST répond de son identité. La CA décide de l’émission. Le système en marche produit le résultat. Une seule coche ne peut représenter leurs actes sans fabriquer une autorité fictive.

Une clé constructeur concentre un risque de flotte

Le projet reconnaît qu’une compromission de la clé peut fournir des CA malveillantes à tous les appareils qui reconnaissent l’ancre correspondante. Il recommande un HSM ou KMS, la protection contre l’export et un certificat dédié, non réutilisé pour TLS, émission de CA, firmware ou autre fonction.

La séparation d’usage réduit le rayon d’explosion et clarifie l’autorisation côté client. Une simple chaîne valide vers « le fabricant » ne suffit pas : il faut savoir que cette clé avait le rôle de signer les paquets d’ancres. Sinon, la validité PKIX masque une ambiguïté institutionnelle.

Le scénario critique commence après la suspicion. Qui désactive un alias ? Quel successeur est accepté si la clé d’origine est perdue ? Comment retrouver tous les appareils ayant installé un paquet suspect ? Que se passe-t-il si le fabricant disparaît alors que l’exploitant possède toujours les équipements ?

RFC 8995 et RFC 8366 offrent un contraste avec les vouchers de rattachement à un domaine. Leurs sujets et contrôles ne sont pas ceux de ce paquet de CA. Les invoquer ne transformerait pas le projet individuel en BRSKI, ni une signature en droit perpétuel sur les racines futures.

Un endpoint public doit rester peu coûteux

Parce qu’il reçoit des requêtes avant authentification normale, l’endpoint d’amorçage est exposé au déni de service. Le projet recommande des objets statiques, aucun lookup par client, pas de signature dynamique, des limites par adresse, préfixe, alias et instance, des cookies DTLS, GET uniquement, des bornes de taille et une désactivation indépendante des alias.

Cette liste décrit un dépôt d’objets signés plus qu’un service d’enrôlement. Tout calcul personnalisé augmente la surface. Une mise en œuvre qui demande l’identité du client ou interroge sa base avant de rendre le paquet a déjà dépassé le minimum proposé.

Le mode clair montre aussi que l’intégrité n’est pas la confidentialité. L’alias et les certificats deviennent observables. S’ils révèlent un client, un pays ou une phase de migration, l’objet n’est peut-être pas public en pratique. TLS ou DTLS peut alors protéger la confidentialité même si l’identité du pair reste non acceptée.

Huit reçus valent mieux qu’un statut « bootstrap réussi »

Reçu Éléments minimaux Ce qu’il ne prouve pas
Fabrication Empreinte d’ancre, classe d’appareil, stockage, règle d’alias Contrôle actuel du fabricant
Autorité du paquet Hash CMS, chaîne, usage du signataire, résultat Identité du serveur ou fraîcheur
Portée et fraîcheur Alias, séquence, dates, confiance dans l’heure Acceptation locale
Décision locale Politique, différences d’ancres, hashes avant/après Authentification du serveur
Transport initial URI, certificat présenté, chiffrement, cache Autorisation EST
Nouvelle session Nom, chaîne, ancre opérationnelle, résultat Acceptation de l’enrôlement
Enrôlement CSR, identité, preuve de possession, décision CA Disponibilité du service
Résultat Certificat installé, santé, observation nommée Validité d’un prochain paquet

Ces reçus rendent la récupération sélective. Une substitution d’alias n’oblige pas à accuser la CA. Un serveur mal configuré n’invalide pas nécessairement le paquet. Une clé constructeur compromise peut être reliée à chaque transition concernée. Un refus d’enrôlement peut être traité sans annuler une rotation de racines correcte.

La contribution la plus utile de la révision 00 est donc une limite : l’objet signé peut traverser un transport non fiable sans rendre ce transport fiable. La confiance n’est déplacée qu’après la vérification, la fraîcheur et la décision locale. L’identité du serveur commence dans la nouvelle session.