Résumé

  • L’IESG a approuvé draft-ietf-acme-device-attest comme Proposed Standard le 30 juillet 2026. La révision 10 attend le RFC Editor ; aucun numéro de RFC ni déploiement n’est présumé.
  • device-attest-01 peut rapprocher l’identifiant demandé, la clé attestée et la clé du CSR. La portée dépend encore du format, de l’autorité d’attestation et de la valeur signée : token seul ou key authorization liée au compte ACME.
  • Cette preuve autorise une émission. Elle ne se renouvelle pas toute seule, et un certificat respectueux de la vie privée peut ne contenir aucun identifiant matériel.

L’adjectif « attesté » cache plusieurs reçus

Une chaîne X.509 valide ne raconte pas spontanément comment elle a été obtenue. Pourtant, un tableau de bord peut présenter un certificat issu après attestation comme la preuve qu’un appareil approuvé, sain et toujours sous le même contrôle se trouve devant le service.

Le projet approuvé est plus précis. Il ajoute permanent-identifier, généralement un identifiant attribué par le fabricant, hardware-module, qui associe type et numéro de série du cryptoprocesseur, et le défi device-attest-01. Les registres IANA affichent déjà ces entrées avec une référence RFC-to-be. Ce sont des faits de normalisation, pas des statistiques d’implémentation.

Le serveur crée un token frais. Selon le format, l’attestation couvre la key authorization complète—token et empreinte de la clé du compte ACME—ou seulement le token lorsqu’une autorité externe intervient avant que la clé du compte soit disponible. Dans le second cas, la fraîcheur existe, mais pas la liaison au compte. Une colonne « attestation réussie » ferait disparaître cette différence.

Le contrôle d’émission repose sur trois rapprochements : l’autorité d’attestation doit être admise par la politique du serveur ; la clé publique attestée doit être celle du CSR ; l’identifiant attesté doit correspondre à celui de l’Order. S’il est ensuite inscrit dans le CSR et le certificat, l’identifiant doit correspondre octet pour octet, sans normalisation.

Une option proposée n’est pas une option exécutée

Pour accompagner les parcs hétérogènes, le serveur peut proposer device-attest-01 et un autre défi dans la même authorization. La réussite de l’un d’eux suffit. La migration devient possible, mais le journal doit nommer le défi effectivement accompli.

Dire qu’un compte ou un produit « prend en charge l’attestation » ne répond donc pas à la question. Même la présence du défi dans la réponse ACME ne prouve pas son exécution. Si le service aval accorde davantage de pouvoir à une émission attestée, il lui faut un reçu authentifié de ce chemin précis.

External Account Binding traite encore autre chose : l’admission préalable du compte dans une PKI d’entreprise. Il ne prouve pas que la clé demandée appartient au matériel annoncé ; l’attestation de l’appareil ne rend pas non plus l’autorisation du compte perpétuelle.

La preuve peut rester chez l’émetteur

Pour ces deux identifiants, le projet permet au client de les omettre du CSR. Un serveur peut même refuser leur présence s’il veut émettre un certificat respectueux de la vie privée. La CA utilise alors l’identité matérielle pour décider, mais remet un certificat portant uniquement une identité logique.

Cette dissociation évite d’exposer un numéro durable à chaque correspondant. Inscrit dans un certificat public ou un journal de transparence, ce numéro peut relier les renouvellements et les usages pendant toute la vie de l’appareil. La divulgation devient difficilement réversible et le remplacement d’un appareil peut se confondre avec le changement d’identité du service.

La conséquence est symétrique : le certificat seul ne permet pas au relying party de reconstituer l’attestation. Il ne révèle ni le format, ni l’autorité, ni le défi réellement utilisé, ni les attributs évalués, sauf mécanisme explicite distinct.

La posture expire avant le symbole

Une attestation peut présenter version de firmware, état de démarrage, système d’exploitation ou niveau de protection matérielle. Le serveur peut refuser une demande sur cette base. Mais le document ne définit pas la vérification de tous les formats ; TPM, TEE et keystore protégé par l’OS ne portent pas les mêmes garanties.

Surtout, ces attributs ont une date. Le certificat peut survivre à la configuration, à la version de la politique, au contrôle du compte ou à la garde physique. La révocation aide dans certains scénarios ; elle ne transforme pas ACME en contrôle continu de posture.

La discipline des couches de réalité de Heng Lu évite ce glissement. Approbation, inscription IANA, défi validé, certificat émis, posture présente et décision d’accès sont six faits distincts. Aucun ne perd de sa valeur lorsqu’on refuse de lui faire dire le suivant.

Sources