Résumé

  • Le 2 septembre 2026, l’IESG a lancé le Last Call de la révision 29 de Use of Remote Attestation with Certification Signing Requests, jusqu’au 16 septembre. Ce texte vise le statut Proposed Standard, mais reste un Internet-Draft, sans preuve d’adoption ni de déploiement.
  • Le paquet transporte plusieurs attestations dans une demande PKCS #10 ou CRMF. Il appartient néanmoins au CA ou au RA de relier la clé publique, le HSM, la propriété de la plateforme, son état et le contexte de fraîcheur à une seule opération d’enrôlement attribuable.

L’exemple le plus utile de la révision 29 ne porte pas sur une signature cassée. Il porte sur trois déclarations parfaitement plausibles. La clé a été générée dans un HSM. La plateforme appartient à l’entreprise. La plateforme se trouve dans un état connu comme bon. Ces phrases ne disent pas encore que le HSM contenant la clé du CSR est installé sur la plateforme possédée et mesurée.

Le projet propose un véhicule commun. Un AttestationStatement associe un OID de type à une déclaration opaque. Un AttestationBundle contient au moins une déclaration, peut en regrouper plusieurs et peut fournir des certificats. Un seul paquet de premier niveau accompagne la demande sous id-aa-attestation, dans un attribut PKCS #10 ou une extension CRMF.

Ce choix résout la livraison des preuves, pas leur cohérence. Les certificats facultatifs peuvent aider à construire un chemin de validation. Ils ne fixent ni l’ordre d’autorité, ni la bonne ancre de confiance, ni la politique métier applicable. Recevoir un certificat, valider un chemin et autoriser une émission sont trois opérations distinctes.

Le projet ne définit d’ailleurs aucun format d’attestation concret et ne crée pas de nouveau registre. Les formats et leurs OID viennent d’autres normes ou de fournisseurs. L’OID sert donc à aiguiller, non à certifier la vérité. Décoder n’est pas vérifier une signature ; vérifier n’est pas choisir une confiance ; faire confiance au signataire n’est pas relier son affirmation à la clé publique en cours d’examen.

L’aiguillage peut lui-même devenir ambigu lorsque plusieurs Verifiers comprennent le même OID. Le texte recommande alors des OID distincts ou un indice d’enveloppe défini par le format. Cet indice doit être protégé par l’attestation. Sinon, une erreur d’intégration ou une manipulation pourrait envoyer une preuve vers le Verifier le moins exigeant.

La chaîne de décision commence avec la clé publique du CSR. La proof of possession démontre un contrôle de la clé privée dans le protocole de demande. Elle ne prouve pas l’emplacement de génération, la non-exportabilité, le propriétaire du matériel, la santé de la plateforme ou le droit d’obtenir le certificat.

Une déclaration de HSM peut répondre à une partie de la question. Il faut encore un identifiant stable qui rattache ce HSM à la plateforme. Le registre de propriété doit couvrir cette même plateforme et le moment pertinent. La mesure d’intégrité doit viser le même objet, avec son époque et ses valeurs de référence. Une ressemblance de noms ou un fournisseur commun ne constitue pas cette preuve.

La fraîcheur réduit la fenêtre de rejeu mais ne fabrique pas l’identité. Le projet compagnon utilise le contexte de transaction dans CMP. Avec EST, il prévoit la même session TLS ou un état HTTP conservé. Si le CA/RA ne peut pas associer le CSR à l’échange de nonce antérieur, il ne doit pas les considérer comme liés.

Lorsqu’elle est demandée, la valeur de nonce compte de 8 à 64 octets ; une longueur nulle indique qu’aucune fraîcheur n’est requise. Un Attester principal peut distribuer un même nonce à plusieurs sous-Attesters. Plusieurs Evidence répondent alors au même défi temporel, sans que cela prouve qu’elles décrivent la même clé ou la même machine.

La limite temporelle demeure. RFC 9334 présente la fraîcheur comme une réduction de l’incertitude de rejeu, non comme une garantie d’état continu. Une plateforme peut changer de logiciel, de propriétaire ou de condition de sécurité après la mesure. L’attestation possède une époque ; le certificat vit souvent bien au-delà.

Le CA/RA conserve donc la décision qui produit la conséquence. Il choisit les formats acceptés, les ancres de confiance, les valeurs de référence, les règles d’appréciation et le profil d’émission. Il peut comparer le paquet à l’une de plusieurs politiques ou écarter l’information si elle ne sert pas la politique applicable. Le projet recommande d’inscrire les exigences dans la certification practice statement.

La version de cette politique est une pièce de preuve. Une trace exploitable conserve le condensat et la clé du CSR, les octets des déclarations, les signataires, les versions des Verifiers, les valeurs de référence, le nonce et son contexte, le titre de propriété, le résultat d’appréciation, la politique choisie et l’acteur ayant autorisé l’émission.

Cette trace ne doit pas être confondue avec le certificat public. Les attestations peuvent révéler identifiants matériels, micrologiciels, correctifs, propriété et état de la chaîne d’approvisionnement. Le projet déconseille de les recopier dans le certificat. Le risque demeure toutefois dans les journaux d’enrôlement, les paquets archivés et les dossiers des Verifiers.

La séparation des couches de réalité défendue par Heng Lu empêche enfin le glissement institutionnel. La publication d’un projet, la syntaxe correcte, la signature valide, l’appréciation favorable, l’émission, le déploiement puis l’acceptation par une partie utilisatrice sont des faits distincts. Une enveloppe normalisée coordonne les preuves ; elle ne reçoit pas le pouvoir symbolique de décider à la place de l’opérateur.

Sources