Résumé
- Le groupe OpenPGP consulte jusqu’au 18 septembre sur l’adoption d’un projet qui signale qu’un secret est externe et permet à une clé secrète transférable d’emporter un indice de localisation facultatif. Aucune issue à l’appel n’est encore rapportée.
- Cet indice n’est qu’un conseil. Un logiciel peut l’ignorer s’il ne le comprend pas et tenter une recherche au mieux. La révision 03 ne définit aucun schéma d’indice, tandis que les registres IANA publics ne contiennent pas encore la valeur
Externalproposée. - Le substitut transporte une identité cryptographique, non la capacité opérationnelle. La découverte locale, l’autorisation, le résultat et la reprise doivent être constatés à part, sans publier d’identifiants sensibles du matériel.
Une consultation ouverte, pas une norme acquise
Stephen Farrell a ouvert l’appel le 4 septembre, après une présentation à l’IETF 126. La question soumise au groupe n’est pas encore de choisir un fabricant ou une méthode d’authentification. Elle consiste à savoir si OpenPGP doit prendre en charge un document individuel qui décrit comment représenter une clé secrète conservée hors du fichier.
Le Datatracker inscrit Call For Adoption By WG Issued côté groupe de travail et I-D Exists côté IESG. Il présente toujours la révision 03 comme un Internet-Draft individuel, sans aval de l’IETF, daté du 22 juillet 2026 et expirant le 23 janvier 2027. L’appel doit se terminer le 18 septembre.
Daniel Kahn Gillmor, Andrew Gallagher et Heiko Schäfer ont publiquement soutenu l’adoption. Paul Schaub s’est proposé comme coauteur si le texte est repris. Ces réponses renseignent sur la participation et sur les compromis perçus ; elles ne constituent ni un scrutin ni la décision finale du président.
Cette précision vaut aussi pour IANA. Le projet propose l’octet d’usage S2K 252, encore marqué TBD, et la création d’un registre d’indices. Le registre OpenPGP en vigueur ne contient aujourd’hui ni ligne External à 252 ni registre d’indices de localisation externes.
Le fichier sait quelle clé chercher
Dans le modèle de RFC 9580, une clé secrète transférable assemble les paquets nécessaires à son échange entre logiciels. La révision 03 introduit une forme particulière : le paquet conserve les paramètres publics, mais remplace les paramètres secrets par le signal External et, éventuellement, par un indice.
Le rapprochement s’effectue à partir de la matière publique correspondante. Un logiciel peut donc demander aux sous-systèmes qu’il connaît lesquels déclarent la clé publique recherchée. Cette propriété évite de réduire l’identité de la clé à une étiquette locale inventée par l’administrateur.
Pourtant, le document refuse de transformer l’indice en adresse impérative. Sans indice, la recherche se fait au mieux. Si l’indice est inconnu ou conduit à une impasse, le logiciel peut sonder les autres mécanismes dont il dispose. Il peut même choisir cette recherche alors qu’un indice est présent.
Ce choix est cohérent avec la mobilité réelle. Une même clé peut résider sur plusieurs appareils. Une carte USB change de chemin lorsqu’elle passe d’un concentrateur à l’autre. Un poste sait parler à une carte OpenPGP, un autre à un TPM, un troisième à un HSM distant. Une URI PKCS #11 est précieuse dans son domaine, mais ne saurait devenir silencieusement le vocabulaire exclusif de tous les environnements.
« Trouvé » ne veut pas dire « autorisé »
Le meilleur effort produit une observation locale. Il ne produit pas un titre de propriété. Lorsqu’un sous-système expose la partie publique correspondante, le logiciel sait seulement qu’un candidat accessible affirme détenir le secret lié. Il ne sait pas, par ce fait, qui en est le détenteur légitime, quelle politique permet l’opération ni s’il existe une autre copie.
L’échec est tout aussi borné. Aucun appareil peut n’être branché. Le pilote peut manquer. Le dispositif peut être verrouillé, refuser l’usage après avoir listé la clé, attendre une pression sur un bouton ou dépasser le délai. La conclusion juste est « cette mise en œuvre n’a pas obtenu cette capacité dans ces conditions », non « la clé n’existe plus ».
Le projet traite concrètement ces frictions. L’énumération et la vérification d’une correspondance ne devraient pas exiger d’autorisation. L’opération secrète peut, elle, demander un code, un mot de passe, un geste biométrique ou une action physique. Avec deux dispositifs équivalents, tenter d’abord celui qui n’exige pas de défi peut éviter le verrouillage provoqué par des codes erronés. Le logiciel doit rester réactif, annoncer l’interaction attendue et afficher les erreurs utiles.
La portabilité du fichier et celle du service sont donc deux contrats. Une archive d’entreprise peut préserver chaque octet du substitut, toutes les certifications et le bon fingerprint. Elle n’a pas sauvegardé pour autant le jeton, le pilote, le compte HSM, les droits de l’employé ni la procédure de reprise.
Le matériel réduit un risque, pas tous les risques
Le texte décrit les avantages possibles sans les absolutiser. Un dispositif peut empêcher l’extraction du secret, limiter la fréquence des opérations, imposer une action visible ou attester une génération interne. Un jeton amovible permet aussi de changer de poste sans recopier la matière secrète.
Mais le matériel peut être vulnérable à des fautes de conception ou à des attaques physiques. Un hôte compromis peut voler le texte clair ou la clé de session après le déchiffrement. Lors d’une signature, l’utilisateur appuie peut-être consciemment sur le bouton tandis que le logiciel compromis soumet au dispositif un autre objet que celui affiché.
Dans sa réponse, Gillmor estime que le compromis matériel n’est pas raisonnable pour la grande majorité des utilisateurs, tout en souhaitant une représentation simple et standard pour ceux qui le choisissent. Schäfer répond que certains contextes en ont effectivement besoin. La norme n’impose pas le choix ; elle cherche à rendre son résultat interopérable.
Un reçu distinct pour la remise opérationnelle
Le paquet OpenPGP ne doit pas devenir un inventaire d’entreprise. Y inscrire séries, comptes, propriétaires et procédures de secours rendrait le fichier bavard, sensible et rapidement obsolète. En revanche, la migration locale a besoin d’une preuve séparée : un reçu de remise de clé externe. C’est ma proposition éditoriale, non une exigence de l’IETF.
Dans un espace protégé, le reçu peut relier le fingerprint du certificat et de la sous-clé concernée, la version du projet ou du futur RFC, l’état réel du codepoint, le schéma d’indice compris, le logiciel et la classe de sous-système testés, l’instant, la méthode de rapprochement, le défi d’autorisation, l’opération demandée et son résultat. Un remplacement doit relier l’ancienne observation à la nouvelle plutôt que d’effacer la trace.
La version publique doit rester minimale : identifiant opaque, classe de capacité et issue vérifiée peuvent suffire. Numéro de carte, partition HSM, PIN, biométrie et topologie restent sous contrôle d’accès. Le reçu constate une capacité à un moment ; l’autorité d’utiliser la clé vient toujours de l’organisation compétente.
Le Policy Mirror de Heng Lu sépare acteur, règle et preuve. La spécification initiale minimale permet ici de garder un noyau mondial étroit et des preuves locales adaptées. Why BTW Media Exists fixe enfin la limite journalistique : l’appel est ouvert, le codepoint est proposé, l’interopérabilité reste à démontrer.
Le substitut voyage parce qu’il ne prétend pas transporter tout le reste. Sa valeur est de dire honnêtement où s’arrête le fichier. La gouvernance commence à cette limite.
Sources
- Appel à l’adoption du groupe OpenPGP
- Fiche Datatracker actuelle
- OpenPGP External Secret Keys, révision 03
- Présentation à l’IETF 126
- Réponse de Daniel Kahn Gillmor
- Réponse d’Andrew Gallagher
- Réponse de Heiko Schäfer
- Réponse de Paul Schaub
- Registre OpenPGP d’IANA
- RFC 9580 — OpenPGP
- RFC 8126 — politique de registre
- RFC 7512 — URI PKCS #11
- Heng Lu — The Policy Mirror
- Heng Lu — Minimum Initial Specification
- Heng Lu — Why BTW Media Exists
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

