Summary

  • RFC 2440 définissait de nombreux tags OpenPGP, mais ne créait pas de procédure ordinaire pour en ajouter de nouveaux de façon permanente : leurs interactions pouvaient réduire la sécurité de l’ensemble.
  • L’espace numérique disponible dans l’en-tête n’était pas une autorisation. Les valeurs 60 à 63 restaient privées ou expérimentales ; les nouvelles demandes relevaient des responsables de la sécurité à l’IESG ou d’un groupe de travail IETF compétent.
  • Dans une signature, un sous-paquet inconnu était normalement ignoré. Son bit critique permettait au signataire de préférer une erreur à la perte silencieuse de son sens. Reconnaître n’était pas implémenter ; voir une donnée non hachée ne la rendait pas probante.
  • Les versions suivantes ont formalisé les registres et les niveaux d’examen. Un numéro attribué, une analyse réussie ou une signature valide ne prouvent toujours pas la sûreté de l’ensemble ni son déploiement.

Une case vide ne tranchait rien

Un développeur trouve un tag inutilisé dans un paquet OpenPGP. Deux nouveaux clients l’écrivent et le relisent sans erreur. Les octets entrent dans le format. Mais qu’en fera un ancien vérificateur ? Un expéditeur peut-il négocier la fonction à la baisse ? Un autre paquet peut-il modifier son sens ? Une signature peut-elle rester mathématiquement valide si sa nouvelle sémantique est ignorée ? Un test local ne répond à aucune de ces questions.

C’est la difficulté inscrite dans la note de l’IESG de RFC 2440, en novembre 1998. Le texte définissait de nombreux tags, mais pas de mécanisme normal pour en ajouter. Le nouvel en-tête pouvait coder des tags jusqu’à 63 ; la spécification avertissait pourtant que les interactions, parfois subtiles, entre fonctions nouvelles et anciennes pouvaient réduire fortement la sécurité globale. Les demandes de nouvelles valeurs — par exemple pour des algorithmes de chiffrement — devaient être adressées aux directeurs de la sécurité de l’IESG ou à un groupe de travail approprié. Les valeurs 60 à 63 demeuraient privées ou expérimentales.

L’espace existait ; la procédure sûre n’en découlait pas.

OpenPGP n’assemblait pas des algorithmes indépendants. Les paquets composent clés, signatures et messages chiffrés. Une fonction peut changer la façon dont un ancien logiciel lit une séquence, dont un nouveau interprète un champ historique, ou ce qu’un destinataire croit couvert par une signature. Un tag peut être disponible dans la syntaxe alors que ses interactions restent inconnues. RFC 2440 séparait capacité d’encodage et permission protocolaire.

Les signatures rendaient la limite visible

Les sous-paquets de signature exposaient la même tension à une échelle réduite. Ignorer un sous-paquet inconnu facilitait la compatibilité : un ancien programme pouvait traiter une signature porteuse de métadonnées nouvelles. RFC 2440 recommandait donc d’ignorer les types non reconnus. Mais le silence pouvait effacer une fonction dont le signataire dépendait.

Le bit 7 du type offrait un choix. Si un sous-paquet inconnu était marqué critique, l’évaluateur devait considérer la signature comme erronée. Le signataire pouvait préférer un échec visible à une acceptation qui aurait perdu le sens de la fonction. Ce n’était pas une garantie absolue : l’évaluateur devait connaître la règle ; même reconnu, le sous-paquet pouvait ne pas être implémenté. La spécification distinguait expressément ces deux états.

Une donnée reconnue, jointe à une signature valide, n’avait pas nécessairement l’autorité de la signature. Les sous-paquets pouvaient être dans la partie hachée ou non hachée. RFC 2440 disait que les informations non hachées n’étaient pas définitives, puisqu’elles ne faisaient pas partie de la signature proprement dite. Le lecteur pouvait les voir et le vérificateur les analyser ; aucun de ces faits ne les rendait cryptographiquement couvertes. Présence, analyse, reconnaissance, implémentation et couverture restaient distinctes.

De la prudence au registre

RFC 4880, qui a remplacé RFC 2440 en 2007, a créé des registres IANA explicites et exigé le consensus de l’IETF pour les nouveaux types de paquets, considérés comme des fonctions majeures. Il a également souligné les risques de rétrogradation et de changement de niveau autour des extensions liées à la détection des modifications. La gouvernance devenait plus lisible, sans réduire l’interopérabilité, l’implémentation et l’analyse de sécurité à une seule case.

Publié en 2024, RFC 9580 remplace RFC 4880 et conserve plusieurs procédures d’allocation. Certains registres OpenPGP utilisent « Specification Required » ; les types de paquets et certains espaces de versions ou d’identifiants relèvent de « RFC Required ». Les experts doivent examiner les propriétés de sécurité attendues et l’interopérabilité avec les implémentations existantes. C’est une réponse institutionnelle au vide antérieur, pas une preuve que toute extension acceptée soit sûre partout.

Ces textes ne disent pas que chaque extension est nuisible, ni que les implémenteurs ont tous suivi une même pratique. Ils montrent une leçon plus précise : dans un protocole cryptographique, ajouter un sens peut changer le comportement des chemins déjà en place. Un entier libre n’est qu’une adresse dans le format ; il ne prouve ni compatibilité, ni couverture cryptographique, ni compréhension des utilisateurs, ni sûreté opérationnelle.

Sources