Résumé

  • Le brouillon draft-birkholz-did-x509-03 demande au résolveur de valider une chaîne présentée feuille en premier, en utilisant son dernier certificat comme ancre de l’algorithme, puis de contrôler l’empreinte d’un certificat non-feuille et les prédicats de la feuille.
  • Cette ancre de calcul n’entre pas d’elle-même dans le magasin de confiance du destinataire. Une politique locale doit encore accepter l’autorité, le DID et le contexte d’usage.
  • Résolution, confiance, vérification de signature, habilitation, écriture durable et effet observé réclament des preuves séparées. La révision 03 est un Internet-Draft informatif en soumission indépendante, pas une norme de l’IETF.

Imaginons un contrôle d’accès qui affiche deux voyants. Le premier indique que le badge a été fabriqué selon une chaîne cohérente et que toutes les mentions visibles correspondent. Le second indique que l’établissement reconnaît l’émetteur du badge. Dans une bonne architecture, le premier voyant ne peut pas allumer le second.

Le mécanisme did:x509 décrit dans la révision 03 se situe exactement à cette jointure. Il associe la compacité d’un identifiant décentralisé à une chaîne de certificats X.509, sans registre persistant de documents DID. Le résolveur peut reconstruire de manière déterministe une clé et des relations de vérification. Sa réussite atteste une relation entre une chaîne et un identifiant ; elle n’exprime pas le consentement institutionnel de celui qui reçoit le résultat.

Le DID désigne une classe de certificats

La syntaxe commence par did:x509:0, puis nomme un algorithme d’empreinte, une empreinte et au moins un prédicat. SHA-256, SHA-384 et SHA-512 sont admis. L’empreinte porte sur un certificat qui n’est pas la feuille — autorité intermédiaire ou ancre terminale — tandis que les prédicats s’appliquent à la feuille.

Quatre familles sont décrites. subject exige qu’un ensemble d’attributs choisis soit inclus dans le sujet. san recherche une adresse électronique, un nom DNS ou une URI dans les Subject Alternative Names. eku exige un OID d’usage étendu. fulcio-issuer compare l’extension d’émetteur Fulcio après restitution du préfixe https://, à condition que cette extension existe et ne soit pas critique.

Ce dessin rend possible le renouvellement des certificats feuilles : plusieurs chaînes peuvent satisfaire le même DID. Mais la stabilité ne vient pas gratuitement. Un sous-ensemble subject trop pauvre peut englober des certificats que l’auteur de la politique n’avait jamais envisagés. La présence d’un EKU ne délègue pas une fonction métier. Un domaine contenu dans un SAN ne prouve ni la maîtrise actuelle de ce domaine ni le droit de signer une mise en production.

Autrement dit, le prédicat sélectionne. Il n’autorise pas.

Une validation fermée sur la chaîne reçue

L’option de résolution x509chain transporte des certificats DER complets, encodés en base64url et séparés par des virgules. La feuille vient d’abord, les intermédiaires suivent, et le dernier certificat sert d’ancre à la validation. Une chaîne de moins de deux certificats est refusée.

Le résolveur applique la validation de chemin de la RFC 5280 : signatures, contraintes, noms, politiques, usages de clé, extensions critiques, algorithmes et instant de référence. Il compare ensuite l’empreinte du DID à un certificat non-feuille et vérifie chacun des prédicats sur la feuille. Si tout concorde, il dérive un JWK de la clé publique de la feuille et construit le document DID.

Cette boucle est cohérente parce que le dernier certificat est accepté comme ancre pour cette exécution. La question différente est de savoir qui a choisi cette ancre pour l’organisation. Le chemin peut être valide relativement au certificat terminal présenté par l’expéditeur, alors même que ce certificat est absent du magasin de confiance du destinataire.

La RFC 9360, dans le contexte voisin des chaînes transportées avec COSE, formule le garde-fou : recevoir des certificats ne doit pas modifier silencieusement les ancres configurées par l’application. Une pièce jointe peut fournir la matière d’un calcul ; elle ne peut pas s’octroyer le statut de constitution.

Étape conservée Conclusion défendable Conclusion prématurée
Analyse du DID La syntaxe et les octets des prédicats sont lisibles Les attributs décrivent une identité légitime
Validation de la chaîne La feuille aboutit au dernier certificat fourni selon les paramètres retenus L’organisation fait confiance à ce certificat
Empreinte et prédicats La chaîne appartient à la classe décrite par le DID Cette classe est autorisée pour l’opération
Politique locale Le destinataire accepte cette ancre dans ce contexte Le message particulier est authentique
Vérification de signature Les octets couverts vérifient sous la clé résolue Le signataire peut décider ou agir
Autorisation et effet Une règle permet l’action et un reçu atteste son exécution Le résultat externe annoncé s’est nécessairement produit

Lire la chaîne de caractères n’est pas résoudre l’identité

Parce que les prédicats sont visibles, un développeur peut vouloir lire directement l’organisation, le courriel ou le domaine dans le DID. La révision 03 interdit ce raccourci pour l’autorisation. Avant résolution, ces caractères sont une affirmation non signée.

N’importe qui peut composer un identifiant syntaxiquement correct avec un nom prestigieux. Tant que la chaîne n’a pas été validée et que les prédicats n’ont pas été comparés à la feuille, aucun émetteur n’a endossé l’affirmation. Même après cette comparaison, le destinataire doit encore accepter l’émetteur. Cette double frontière — preuve de cohérence, puis politique de confiance — protège le système d’une confusion très banale entre ce qui est écrit et ce qui est reconnu.

Le temps et la révocation changent le verdict

La validation demande un instant. Le brouillon permet l’heure courante ou un instant pertinent pour le contexte, par exemple l’heure de signature d’un artefact. Le résultat peut donc différer pour une même chaîne. Une valeur iat issue d’un JWT ou d’un CWT, tels que définis par les RFC 7519 et RFC 8392, n’est pas une horloge fiable par simple présence : son intégrité et son admissibilité doivent être établies.

La révocation est appliquée si l’application l’exige, au moyen de listes, d’OCSP ou d’un autre dispositif. Transparence des certificats, endossements et interdiction d’algorithmes faibles peuvent compléter la politique. Il faut donc enregistrer l’instant choisi, la politique de révocation, les réponses consultées et les règles algorithmiques. Le booléen « valide » ne permet pas de rejouer la décision.

Les mécanismes de reçus abordés par les RFC 9597 et RFC 9943 rappellent le même principe : transporter une preuve ne définit pas la politique qui lui donnera effet.

La permanence apparente déplace le pouvoir vers l’autorité de certification

did:x509 ne possède ni opération de mise à jour du document DID, ni autorisation de mise à jour. Il ne définit pas davantage une opération de désactivation. La création est locale et la résolution dépend du DID et de la chaîne fournie.

L’expiration ou la révocation de toutes les feuilles connues peut rendre l’identifiant inutilisable. Ce n’est pourtant pas une désactivation irréversible : une autorité capable d’émettre une nouvelle feuille satisfaisant les mêmes prédicats peut rétablir la résolution. Le véritable levier de continuité se trouve donc dans la gouvernance de l’autorité, la précision des prédicats et la politique des destinataires.

Lorsque plusieurs chaînes valides conduisent au même DID, les clés résolues peuvent varier. Un journal qui ne garde que le DID stable efface la clé effectivement utilisée. Il faut conserver la chaîne exacte avec l’objet signé.

Ce que les implémentations prouvent — et ce qu’elles ne prouvent pas

La révision 03 décrit une méthode mise en œuvre par Microsoft et cite d’autres projets ainsi que des usages liés à la signature, à SCITT, à CCF et aux conteneurs confidentiels. Le README Microsoft, la spécification du dépôt et les vecteurs de test donnent du code et des cas concrets à comparer.

Le brouillon relève aussi des différences visibles avec l’implémentation Nuts sur la couverture de eku et d’un SAN otherName. Ce n’est pas un détail embarrassant à masquer : c’est la frontière d’interopérabilité à tester. Les mentions d’implémentation sont fournies par des contributeurs ; elles ne constituent ni une validation de l’IETF ni un inventaire exhaustif.

La trajectoire éditoriale est elle-même une information. La révision 02 annonçait Standards Track. La révision 03 adopte le statut Informational et développe précisément le modèle de confiance, les opérations, la résolution, la vie privée et l’état des implémentations. Le dossier Datatracker, son historique et l’annonce I-D montrent une soumission indépendante en cours, pas un RFC ni un produit de l’IETF.

Le cadre général du DID Core du W3C et les registres DID aident à situer documents et relations de vérification. Ils ne confèrent aucun statut supplémentaire à cette méthode particulière.

Le reçu complet

Un dossier exploitable doit contenir le DID exact, la version et les octets décodés ; chaque certificat DER dans son ordre ; le résultat de construction et de validation ; l’instant retenu ; les décisions sur noms, politiques, contraintes, usages et algorithmes ; la révocation et la transparence effectivement contrôlées ; le certificat dont l’empreinte correspond ; le résultat de chaque prédicat ; la règle locale qui accepte ou refuse l’ancre ; le document DID et le JWK produits ; l’objet signé et les octets couverts ; le résultat cryptographique ; l’autorisation métier ; l’identifiant d’écriture durable ; enfin, l’effet constaté.

Une vérification non effectuée doit rester vide ou explicitement marquée. revocation_non_requise n’est pas certificat_non_révoqué. confiance_locale_non_évaluée n’est pas autorité_approuvée.

La Spécification initiale minimale de Lu Heng invite à partager la mécanique minimale sans absorber les décisions futures. La primauté du code en fonctionnement exige des traces interopérables et des effets. Le miroir de la politique montre que le magasin de confiance est l’institution cachée derrière le résultat. Les couches de réalité empêchent enfin de confondre chaîne de caractères, certificat, jugement, signature et conséquence.

Sources