Résumé

  • La RFC 9809 attribue quatre identifiants EKU distincts à la signature de configuration, au changement d'ancres de confiance, aux paquets de mise à jour et aux communications critiques pour la sécurité. Ils décrivent l'usage certifié d'une clé, pas l'approbation d'un objet ni la réussite d'une opération.
  • Une politique défendable conserve six décisions séparées : enregistrement du nom, émission du certificat, règles de combinaison, contrôle par le système vérificateur, autorisation de l'acte et preuve de son résultat.

Le cas difficile n'est pas le certificat manifestement invalide. C'est celui qui est valide pour deux missions dont l'organisation refuse qu'elles soient réunies.

Un automate peut accepter une clé pour signer ses mises à jour ordinaires et interdire à cette même clé de remplacer les ancres qui détermineront les signatures dignes de confiance demain. Le certificat portant les deux usages n'est pas nécessairement falsifié. Il est trop puissant pour ce contexte. Le rejet vient d'une règle de séparation des pouvoirs, pas d'une erreur cryptographique.

La RFC 9809, publiée sur la voie Standards Track en juillet 2025, fournit le vocabulaire nécessaire à cette décision. Elle définit id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning et id-kp-safetyCommunication. Le premier vise les configurations, le deuxième les configurations qui modifient les ancres de confiance, le troisième les paquets logiciels ou micrologiciels, le quatrième les communications pouvant affecter la vie, la santé, les biens ou l'environnement.

La notice du RFC Editor fixe la date, le statut et les auteurs, Hendrik Brockhaus et David Goltzsche. Le Datatracker de l'IETF conserve le dossier du texte. Le registre SMI de l'IANA inscrit les numéros 41 à 44 sous la branche PKIX consacrée aux usages de clé.

Cette petite opération de registre a un effet concret. Sans identifiant commun, chaque secteur encode une intention avec un OID privé, détourne un usage voisin ou dépend d'une convention difficile à auditer. Avec quatre noms stables, l'autorité de certification, la bibliothèque de validation et le journal d'audit peuvent parler du même objet. L'interopérabilité progresse sans que l'IANA prenne le contrôle d'un train, d'une usine ou d'un parc d'équipements.

La limite apparaît dans la RFC 5280. L'Extended Key Usage restreint les finalités de la clé certifiée. Si l'extension Key Usage est également présente, les deux contraintes s'appliquent. digitalSignature peut permettre l'opération cryptographique tout en laissant l'EKU décider si cette signature sert une mise à jour ou une configuration. Une signature techniquement possible n'est donc pas encore une signature recevable pour l'application.

La RFC 9809 ne déclare pas ses quatre usages incompatibles par nature. Elle confie les combinaisons permises ou interdites aux normes applicatives et aux politiques de certification. Ce choix protège la diversité des systèmes. Un équipement compact peut avoir une chaîne d'administration différente de celle d'une signalisation ferroviaire. Leur imposer une matrice universelle transformerait un registre commun en autorité de déploiement qu'il ne peut être.

L'émetteur doit placer les bons EKU et Key Usage, vérifier le demandeur et expliquer sa politique. Il ne connaît pourtant pas toutes les séparations de fonctions, fenêtres de maintenance et conséquences de panne chez les vérificateurs. Inversement, le vérificateur ne doit pas se contenter de trouver l'OID souhaité. Il doit aussi détecter un usage exclu, valider la chaîne complète et appliquer la bonne version du profil local. La RFC 9336 donne aux chemins de certification un mécanisme d'usages permis et exclus. Encore faut-il que le code l'exécute.

anyExtendedKeyUsage fragilise précisément cette frontière. Il facilite une compatibilité générale, mais dit trop peu à une organisation qui veut empêcher qu'une clé de mise à jour touche aux ancres de confiance. La RFC 9809 déconseille son emploi ordinaire. La précision du registre ne sert à rien si l'émission ou la validation réintroduit ensuite un joker.

Après le certificat commence une autre enquête. Une mise à jour a une cible, une version, des dépendances, une fraîcheur et un chemin de retour. La RFC 9019 sépare notamment l'auteur, l'auteur du manifeste, le distributeur et l'équipement. La RFC 9124 décrit les informations par lesquelles un manifeste lie une charge utile à ses conditions de traitement. L'EKU de signature de mise à jour ne remplit aucun de ces champs et ne prouve pas que l'installation a réussi.

Une configuration signée peut de même viser le mauvais groupe, arriver hors fenêtre ou contredire une limite locale. Le changement d'ancres mérite une classe distincte parce qu'il modifie les futures conditions de confiance. Le nouvel OID rend possible une garde plus forte : double approbation, clé séparée, conservation hors ligne ou procédure de retour différente. Il ne déploie pas cette garde à la place de l'opérateur.

Pour une communication critique, l'écart est encore plus net. Le certificat peut indiquer que la clé a été émise pour ce domaine. Le destinataire doit toujours vérifier le pair et le contexte, la fraîcheur, l'ordre, l'absence de rejeu et le sens du message. Les interverrouillages et le comportement sûr en cas de défaut sont des propriétés du système. Aucun OID ne constate qu'une machine s'est arrêtée ou qu'un avertissement est arrivé à temps.

La précision a enfin un coût de confidentialité. L'EKU révèle la fonction opérationnelle d'un certificat. La RFC 9809 signale son exposition possible dans TLS 1.2 et dans les journaux publics de Certificate Transparency. La RFC 5246 décrit l'échange TLS 1.2. La RFC 8446 chiffre, en TLS 1.3, les messages de poignée de main après ServerHello, dont les certificats. La RFC 9162 définit l'actuel modèle de transparence. Réduire une voie d'observation ne supprime donc ni les journaux, ni les autres protocoles, ni les inventaires internes.

L'audit utile ne se résume pas à « certificat valide ». Il conserve l'empreinte et le chemin, la politique d'émission, tous les Key Usage et EKU, la règle de combinaison et sa version, le résultat exact du vérificateur, l'identité et la fraîcheur de l'objet, l'autorité ayant décidé l'activation, puis la télémétrie ou le reçu du pair. La preuve doit montrer où chaque pouvoir s'arrête.

Dans Les couches de réalité, Heng Lu sépare le symbole, l'état technique, l'acte opérationnel et le résultat. La primauté du code exécuté donne priorité à la règle réellement appliquée et au comportement observé. La spécification initiale minimale explique l'équilibre de la RFC 9809 : un petit vocabulaire commun, puis des décisions futures localisées.

Les quatre OID ne valent donc pas quatre laissez-passer. Ils offrent quatre frontières que les organisations peuvent enfin nommer, tester et défendre.

Sources