Résumé

  • La RFC 9925, norme proposée de l’IETF publiée en février 2026, crée id-alg-unsigned, avec paramètres absents et valeur de signature de longueur nulle.
  • L’objet transporte des informations sur un sujet, mais aucune preuve provenant d’un émetteur. Un champ émetteur identique au sujet peut subsister pour la compatibilité ; il reste un espace réservé.
  • Un logiciel peut accepter cet objet lorsqu’il ne vérifie pas de signature X.509. En revanche, tout validateur de chemin de certification doit le rejeter à la place d’une signature.
  • Supprimer une auto-signature décorative peut réduire le poids post-quantique, éviter la réutilisation d’une clé entre protocoles et accueillir une clé KEM incapable de signer.
  • La confiance doit être prouvée ailleurs, au moyen d’un reçu d’origine et de portée qui relie les octets, la source, l’autorité d’installation, le magasin, l’usage et le retrait.

Le zéro qui clarifie le fichier

La RFC 9925 ne propose pas un certificat dont la vérification aurait été oubliée. Elle décrit une absence volontaire. Les deux champs d’algorithme utilisent l’identifiant 1.3.6.1.5.5.7.6.36 et la valeur de signature est une chaîne de bits vide. Un logiciel sait ainsi qu’il se trouve devant une non-signature, pas devant une signature endommagée ou un algorithme mystérieux qu’il pourrait accepter par indulgence.

Cette différence donne à l’objet une double nature. Sa forme X.509 reste utile pour transporter un nom, une clé et les indications relatives au sujet. Mais il est invalide comme preuve d’un lien d’émission. Dans un contexte qui ne vérifie pas la signature — par exemple lorsqu’un autre mécanisme a déjà authentifié les données — le consommateur peut le lire. Dans un chemin de certification, il doit échouer.

La règle est saine parce qu’elle empêche la syntaxe de se substituer à la cryptographie. Le risque naît plus loin, quand une interface présente tout fichier X.509 comme un certificat délivré, quand un inventaire lui attribue automatiquement un émetteur, ou quand le souvenir d’une installation locale se transforme avec le temps en prétendue validation par une autorité de certification.

Un nœud, sans l’arête

Le texte fournit sa propre image conceptuelle. Dans un graphe d’infrastructure à clés publiques, un certificat ordinaire relie les informations sur le sujet à une preuve donnée par l’émetteur. Les entités sont des nœuds ; le certificat signé est l’arête.

Or certaines applications ont besoin d’un nœud isolé. Une ancre de confiance ouvre le chemin : elle ne reçoit pas sa confiance d’un certificat situé au-dessus. Un système TLS fermé peut connaître une clé ou une empreinte par provisionnement. Une clé de encapsulation post-quantique peut devoir être transportée dans un conteneur familier alors qu’elle ne sait pas signer.

L’auto-signature traditionnelle ne répond pas à la question décisive. Elle montre tout au plus que la clé correspondante a signé sa propre représentation. Elle ne prouve ni que le nom est juste, ni que l’administrateur devait installer la clé, ni qu’elle doit être valable pour toutes les applications. La RFC 5280 place déjà l’ancre hors du chemin prospectif : ses données sont des entrées fournies par une procédure de confiance hors bande, et le choix de l’ancre reste local.

La RFC 9925 retire donc une arête fictive. Elle rend la représentation plus fidèle. Mais la décision externe devient d’autant plus importante : quel acteur a donné à ce nœud un pouvoir local, et dans quelles limites ?

Le champ émetteur ne doit pas produire un émetteur

Le format X.509 impose un champ émetteur non vide. Pour ne pas casser des logiciels anciens, la RFC autorise la répétition du nom du sujet. Elle offre aussi un nom court spécialement réservé au cas non signé. Dans les deux cas, le texte insiste : il s’agit d’un substitut syntaxique. L’objet n’est ni auto-signé ni auto-émis.

Cette petite contrainte est un test du « miroir de politique » de Lu Heng. Un registre fidèle doit refléter le pouvoir qui existe réellement. Afficher « émis par le sujet » transforme une nécessité d’encodage en fait institutionnel. Dessiner une boucle dans un graphe invente précisément la relation que la norme a supprimée.

Les extensions suivent la même logique. L’identifiant de clé d’autorité et le nom alternatif de l’émetteur n’ont normalement pas leur place. Les contraintes de base et l’usage de clé peuvent décrire si le sujet est destiné à agir comme autorité ou comme entité finale. Cette capacité déclarée n’est toutefois pas une autorisation d’installation.

Une inscription IANA n’est pas une validation

IANA conserve l’identifiant de l’algorithme et les nouveaux arcs PKIX. Cela permet à deux implémentations indépendantes de reconnaître le même état. L’inscription ne garantit pas le sujet, ne valide pas la clé et n’ordonne pas à un magasin de confiance de l’accepter.

Ici, la fonction du numéro est même de permettre un refus précis. Un validateur inchangé devrait rencontrer un algorithme invérifiable et fermer le chemin. Seules les applications qui savent pourquoi elles ne vérifient pas cette signature ont besoin d’un traitement particulier.

La RFC avertit qu’accepter id-alg-unsigned là où une signature est attendue contournerait le contrôle. La discipline rejoint celle de la RFC 8725 : un logiciel cryptographique doit limiter les algorithmes autorisés et vérifier que l’opération accomplie correspond à l’algorithme déclaré. La reconnaissance d’un code ne constitue jamais la réussite de l’opération.

Pourquoi l’absence peut être plus sûre

Le mot « non signé » évoque spontanément un affaiblissement. Dans le périmètre prévu, l’auto-signature pouvait n’être qu’un geste imposé par la forme. Si personne ne la vérifie, elle n’est pas la source de confiance. Avec des signatures post-quantiques volumineuses, elle ajoute des octets. Avec une clé d’entité finale, elle peut réutiliser la même clé dans deux protocoles. Avec une clé KEM, elle peut être impossible.

Nommer l’absence réduit alors le théâtre. La clé reste dédiée à sa fonction. Le validateur peut échouer sans ambiguïté. L’application locale peut utiliser les informations sur le sujet parce qu’elle possède déjà une autre preuve.

La meilleure défense de la norme est donc sa modestie. Elle ne prétend pas produire une chaîne. Elle ne promet pas une identité universelle. Elle fournit un conteneur et une règle de refus. Rien dans cette défense n’autorise toutefois à résumer la preuve externe par les mots « hors bande ».

Une empreinte comparée en personne, une image de micrologiciel signée, un dépôt de configuration protégé, une transaction d’administration et un choix manuel ont des autorités et des possibilités de récupération différentes. Le canal doit être relié à une personne ou un rôle compétent, à un périmètre et à un état de vie.

Le pouvoir réel appartient à l’installation

La RFC 6024 permet de décomposer ce pouvoir. Une ancre associe une clé publique à des contraintes. Un gestionnaire agit sur un ou plusieurs magasins. Une opération peut ajouter, retirer ou remplacer ; elle doit authentifier la source et vérifier que celle-ci est autorisée à fournir l’information. La portée peut être limitée à une application ou à un sous-ensemble d’appareils.

Ainsi, l’administrateur qui importe un objet non signé n’effectue pas une simple copie. Il accomplit la décision qui rend la clé opérante. La possession de privilèges techniques ne suffit pas toujours à prouver le mandat politique. Un canal sécurisé prouve un interlocuteur, pas nécessairement sa compétence pour élargir un espace de noms. Une empreinte prouve l’identité des octets, pas leur portée. Un test de chemin réussi prouve que la configuration fonctionne, pas qu’elle était autorisée.

Cette chaîne mérite un reçu.

Un reçu d’origine et de portée

Le premier bloc enregistrerait le condensat des octets, la clé du sujet, son rôle déclaré, l’identifiant non signé et l’interdiction explicite d’employer l’objet comme signature de chemin. Le nom du fichier serait secondaire.

Le deuxième décrirait l’acquisition : source, canal, preuve externe d’intégrité, identité de la partie qui a fourni l’objet et règle qui l’autorisait à proposer une confiance. Une simple mention « téléchargé » ne suffirait pas.

Le troisième fixerait la décision : rôle approbateur, instant, magasin ciblé, applications et population concernées, noms, politiques, usages et période acceptés. La présence dans un magasin général ne devrait pas élargir silencieusement l’autorité.

Le dernier préserverait la vie de l’objet : version remplacée, condition de retrait, propriétaire du prochain examen, correction et récupération après compromission. La partie publique peut rester mince — condensat, portée, autorité, état, lignée et contact — tandis que les secrets opérationnels restent protégés.

Ce reçu ne signe rien. Il ne crée ni émetteur central ni registre mondial. Il rend visible la décision locale qui existe déjà.

Limite des preuves

Les sources examinées ne disent pas combien de produits déploient la RFC 9925, ni si l’un d’eux la traite mal. La charte LAMPS montre un champ de travail actif, pas une télémétrie. L’inscription IANA prouve un identifiant, pas l’adoption.

Toutes les auto-signatures ne sont pas sans usage : le texte reconnaît qu’une application peut s’en servir contre une corruption accidentelle. L’objet non signé exige alors une autre intégrité. Et tout objet non signé n’est pas forcément une ancre de confiance.

Le constat certain est plus étroit. La norme sépare les données du sujet de la preuve d’émetteur, impose le refus dans le chemin et place la confiance ailleurs. L’ingénierie a nommé correctement la moitié absente ; la gouvernance doit documenter la moitié externe.

Sources

  1. Lu Heng, « The Policy Mirror »
  2. RFC 9925, « Unsigned X.509 Certificates »
  3. RFC 5280, profil des certificats et listes de révocation X.509
  4. RFC 4158, construction des chemins de certification X.509
  5. RFC 5914, format des ancres de confiance
  6. RFC 6024, exigences de gestion des ancres de confiance
  7. RFC 8446, protocole TLS 1.3
  8. RFC 8725, bonnes pratiques pour JSON Web Token
  9. IANA, numéros SMI
  10. IETF, charte du groupe LAMPS