Résumé

  • L’IESG a ouvert le 2 septembre 2026 le Last Call de draft-ietf-lamps-csr-attestation-29, jusqu’au 16 septembre ; le texte vise le statut Proposed Standard mais n’est pas un RFC approuvé.
  • Le projet définit un conteneur ASN.1 pour transporter plusieurs Evidence, Endorsements ou Attestation Results dans des demandes PKCS#10 ou CRMF. Il ne crée pas un verdict universel.
  • Une CA/RA peut traiter ces éléments pour appliquer sa politique d’émission ou les écarter. Si elle les utilise, elle répond de leur lien avec la clé, de leur cohérence de plateforme et de leur fraîcheur.
  • La copie d’informations sensibles sur le matériel, les correctifs ou la propriété dans le certificat public est déconseillée. Le certificat ne raconte donc pas, à lui seul, l’évaluation privée.
  • Un reçu d’émission protégé peut préserver cette décision sans exposer le dossier technique. Il s’agit d’une proposition de Daniel Kade, pas d’une exigence de l’IETF.

La pièce publique arrive à la fin du raisonnement

Quand un auditeur ouvre un certificat de signature de code, il peut vérifier sa chaîne, sa période de validité, ses extensions et sa signature. Il ne peut pas nécessairement savoir si la CA a reçu une attestation distante, si un vérificateur l’a évaluée, si elle était fraîche, ni quelle politique a transformé le résultat en autorisation d’émettre.

Le Last Call envoyé par l’IESG le 2 septembre place précisément ce mécanisme dans la phase de commentaires à l’échelle de l’IETF, avec une échéance au 16 septembre. La fiche Datatracker indique In Last Call et une analyse IANA encore requise. L’historique ajoute le 6 septembre l’attribution d’une revue ARTART. Aucune de ces mentions ne vaut adoption, mise en production ou contrôle d’une CA.

La version 29 fournit les structures permettant d’insérer une ou plusieurs déclarations d’attestation dans une demande de certificat. Le conteneur accepte des formats normalisés ou propriétaires. Il peut porter de l’Evidence produit par un Attester, des Endorsements ou un Attestation Result émis par un Verifier, ainsi que des certificats utiles à leur validation.

Le support n’est pas le jugement. PKCS#10 et CRMF décrivent deux formes de demande ; le projet ajoute un moyen commun d’y joindre les déclarations. Il ne rend pas obligatoire leur présence et n’impose pas à chaque autorité de les consommer.

La lecture de la version 28 et du différentiel officiel 28–29 évite une fausse nouveauté : la révision courante affine le texte et ses références, mais n’invente pas cette frontière. L’événement est le passage au Last Call, non la naissance du choix laissé à la CA.

Recevoir ne signifie pas examiner

La section de sécurité énonce une liberté décisive. La CA/RA peut vérifier les attestations pour déterminer si une politique d’émission est satisfaite, ou laquelle parmi plusieurs l’est. Elle peut aussi supprimer les informations supplémentaires sans les traiter. Lorsqu’une CA accepte ou exige ces éléments, elle devrait décrire ses exigences dans sa Certification Practice Statement.

Il faut donc distinguer l’état d’entrée, l’état de décision et l’état publié. Le CSR prouve ce qui a été fourni à un instant donné. Le système de la CA sait ce qui a été évalué. Le certificat montre ce qui a été signé. Une interface qui déduit le deuxième état du troisième fabrique une provenance inexistante.

L’architecture RATS de RFC 9334 explique pourquoi. Le Verifier évalue l’Evidence selon une politique d’évaluation des preuves. Le Relying Party applique ensuite sa propre politique aux Attestation Results pour prendre une décision propre à l’application. La confiance est un choix, pas une propriété transmise automatiquement avec les octets.

Les Code Signing Baseline Requirements du CA/Browser Forum donnent un contexte concret aux contrôles de clé dans un module cryptographique. Ils proposent plusieurs méthodes de vérification. Ils ne prouvent pas qu’une méthode précise a servi pour un certificat donné, et le projet IETF ne transforme pas cette politique privée en audit public.

Trois déclarations exactes peuvent viser trois objets différents

Le projet illustre la difficulté par un assemblage. Une première déclaration affirme que la paire de clés a été créée dans un HSM. Une deuxième rattache une plateforme à l’entreprise. Une troisième décrit cette plateforme comme étant dans un état connu comme bon.

Chaque phrase peut être vraie isolément. La conclusion voulue n’est valide que si la première vise la clé publique du CSR et si les deux autres visent la plateforme qui contient ce même HSM. La CA/RA doit vérifier cette composition. Le nombre de déclarations ou la validité de leurs signatures ne suffit pas.

Le conteneur prévoit qu’au moins une déclaration devrait être liée cryptographiquement à la clé publique objet du CSR. Ce minimum n’établit pas, à lui seul, la liaison de toutes les autres assertions. Un reçu utile doit indiquer quelle jointure a été testée, quels identifiants ont été comparés et quel résultat a gouverné l’émission.

La fraîcheur suit la même logique. Une CA/RA peut ignorer une preuve périmée ou dont la fraîcheur reste indéterminée. Le projet complémentaire sur la fraîcheur, version 08, décrit la demande d’un nonce via CMP, EST ou CMC. Il laisse hors champ le nombre de nonces exigé, leur transmission vers l’Attester, le choix de l’émetteur et les autres méthodes. La présence d’un nonce ne raconte donc pas toute l’évaluation.

Ne pas publier la preuve n’oblige pas à perdre la décision

Le matériel d’attestation peut révéler le modèle de l’équipement, son niveau de correctif ou son propriétaire. La version 29 déconseille de le copier dans le certificat publié. Si une CA choisit de le faire, elle devrait examiner le contenu et retirer les données sensibles. La variante d’extension CRMF est elle aussi déconseillée dans les certificats X.509 pour des raisons de vie privée.

Cette retenue est proportionnée. Un certificat circule bien au-delà du dialogue d’inscription, reste dans des archives et devient corrélable. Inscrire l’état détaillé d’une machine dans cette enveloppe durable transformerait un besoin d’assurance ponctuel en exposition générale.

Il reste possible de conserver une trace à deux niveaux. Le reçu protégé relierait l’empreinte du CSR au numéro de série ou à l’empreinte du certificat, aux identifiants des formats, aux condensats confidentiels des preuves, aux rôles d’Attester, de Verifier et de CA/RA, aux résultats de liaison, à la méthode de fraîcheur, aux versions des politiques d’évaluation et d’émission, au sort de chaque déclaration et à la décision signée dans le temps.

La projection publique pourrait se limiter à un identifiant de reçu, une référence au certificat, une formulation bornée de la propriété admise, la politique applicable et une voie de correction. Les détails de l’appareil, les valeurs de référence et les pièces de propriété resteraient sous contrôle d’accès.

Ce reçu est ma proposition éditoriale. Il n’apparaît ni dans la version 29 ni dans RFC 9334. Il ne crée aucune obligation d’attestation et ne présume pas qu’une CA a négligé son devoir. Il empêche seulement que la vie privée serve, par défaut, à effacer le motif d’une décision.

The Policy Mirror invite à localiser le commutateur qui change un fait en autorité : ici, la politique de la CA qui convertit une évaluation privée en signature. Running Code Primary exige ensuite la trace de l’exécution. Une CPS décrit ; un certificat atteste l’émission ; le reçu montre le chemin réellement parcouru.

Sources

  1. Last Call de l’IESG
  2. Fiche Datatracker du projet
  3. Historique du projet
  4. Version 29
  5. Version 28
  6. Comparaison officielle 28–29
  7. Architecture RATS, RFC 9334
  8. PKCS#10, RFC 2986
  9. CRMF, RFC 4211
  10. Projet sur la fraîcheur, version 08
  11. Code Signing Baseline Requirements
  12. Lu Heng — The Policy Mirror
  13. Lu Heng — Running Code Primary