RFC 1991 : ouvrir l’enveloppe PGP ne suffisait pas à établir la preuve

Résumé

• RFC 1991 fixait une chaîne précise : signer les données littérales, comprimer l’ensemble, le chiffrer avec une clé de session, chiffrer cette clé pour chaque destinataire, puis ajouter éventuellement l’ASCII Armor.
• Le CTB, les longueurs, le CRC d’armure et les octets de contrôle de clé validaient des frontières locales. Aucun ne prouvait à lui seul l’auteur, l’autorisation, la livraison ou la complétude du traitement.
• Une signature valide portait sur des octets définis. Elle ne couvrait pas automatiquement le nom de fichier, l’heure du paquet littéral, l’itinéraire du courrier ou l’identité réelle attachée à la clé.

La preuve change avec l’ordre des opérations

La lecture la plus féconde de RFC 1991 commence non par les algorithmes, mais par l’ordre. PGP créait une signature du message et plaçait le paquet de signature devant le paquet de données littérales. Si la compression était choisie, elle englobait les deux. Le résultat était ensuite chiffré avec une clé conventionnelle éphémère. Pour chaque destinataire, un paquet distinct transportait cette clé de session chiffrée par cryptographie à clé publique. L’armure ASCII venait, si nécessaire, autour de l’objet binaire achevé.

Cet ordre donne à chaque résultat sa compétence. La signature est antérieure au chiffrement : elle atteste une relation entre une clé et les octets signés qui réapparaissent après déchiffrement et décompression. Le chiffrement ne lui ajoute ni le trajet du courriel ni les métadonnées du transport. Inversement, la réussite du déchiffrement ne prouve pas que la signature intérieure existe ou qu’elle est valable.

Le paquet littéral rend la limite très concrète. Il contient un mode, un nom de fichier suggéré, une date et les données. RFC 1991 précise que seules les données littérales entrent dans le condensat d’une signature de document. Une interface qui affiche le nom et la date à côté d’une coche « signature valide » peut donc donner à des champs non signés l’apparence d’une preuve cryptographique.

Les signatures détachées confirment cette géométrie : elles sont calculées sans l’en-tête du paquet littéral afin de rester utilisables séparément. Plusieurs signataires peuvent signer le même document indépendamment. Avec des signatures imbriquées, en revanche, un signataire ultérieur couvre le document et la signature précédente. Dire simplement « toutes les signatures sont bonnes » efface la question décisive : qui a signé quels octets, et éventuellement quelle signature antérieure ?

Le CTB sait découper, pas témoigner

Chaque paquet commence par un Cipher Type Byte, ou CTB. Ses bits indiquent le type du paquet et la taille du champ de longueur. Le parseur peut ainsi distinguer signature, données compressées, données chiffrées ou données littérales, puis avancer jusqu’à la frontière annoncée. Pour certaines données compressées, une forme sans longueur explicite court jusqu’à la fin de la structure englobante.

C’est une discipline d’interopérabilité remarquable : un fichier composé cesse d’être un bloc opaque. Mais la syntaxe ne peut témoigner au-delà d’elle-même. Un type reconnu dit « ces bits déclarent cette sorte de paquet ». Une longueur cohérente dit « le parseur a atteint la frontière déclarée ». Ni l’un ni l’autre ne garantit l’origine, la sûreté de l’algorithme, l’exhaustivité de l’objet extérieur ou le droit de l’application à exécuter le contenu.

La longueur indéfinie révèle même une dépendance souvent cachée. « Jusqu’à la fin » n’a de sens que si la fin de la structure englobante est elle-même connue. La réussite locale du parseur peut donc coexister avec une hypothèse fausse sur l’enveloppe supérieure.

L’armure protège le passage dans le courrier

Les systèmes de messagerie de l’époque ne transportaient pas toujours fidèlement un flux binaire. RFC 1991 convertissait donc trois octets binaires en quatre caractères imprimables, ajoutait un en-tête, des champs facultatifs, le corps, un CRC sur 24 bits et une ligne de fin. Le CRC était calculé sur le binaire avant la conversion radix-64.

Un bloc complet paraît officiel, mais le texte interdit justement d’y placer une information importante : les en-têtes d’armure ne font pas partie du message et peuvent être modifiés pendant le transport. Une clé d’en-tête inconnue mais bien formée doit être signalée, puis le traitement continue.

Le reçu produit par l’armure est donc étroit. Les caractères imprimables ont reconstruit un flux binaire compatible avec l’enveloppe et son contrôle d’erreur. Cela détecte certaines altérations accidentelles ; cela n’authentifie pas l’émetteur. Un adversaire peut remplacer tout le bloc et recalculer le CRC. La signature intérieure, si elle existe, relève d’une autre couche.

Déchiffrer n’est pas identifier

Le chiffré conventionnel commence par des données aléatoires dont certains octets sont répétés. Leur concordance après déchiffrement permet de supposer que la clé de session choisie est la bonne. Le paquet à clé publique ajoute aussi un contrôle de la clé de chiffrement des données. Ces mécanismes écartent rapidement une mauvaise piste ; ils n’authentifient ni l’opérateur de la clé privée ni son autorisation.

Le Key ID sur 64 bits a la même modestie nécessaire. RFC 1991 avertit que deux clés peuvent partager cet identifiant, par hasard ou intentionnellement. Il aide à sélectionner des clés candidates ; il ne constitue pas une identité unique. Un audit sérieux doit conserver la clé effectivement résolue, la méthode de sélection, son état de révocation ou de compromission et la politique qui autorisait son usage.

La date d’une signature ordinaire reste, elle aussi, une déclaration. Le RFC indique qu’elle est généralement proche de la création, sans l’exiger : l’utilisateur peut choisir la date. Une heure de confiance exige une signature notariale distincte portant sur le paquet de signature. Une validation cryptographique ordinaire ne prouve donc ni la fraîcheur ni une heure juridique.

Ce que le document apporte encore

La fiche du RFC Editor classe RFC 1991 comme document informatif d’août 1996, désormais rendu obsolète par RFC 4880. Les versions HTML, texte et la fiche de l’IETF permettent de vérifier le format historique sans transformer sa publication en preuve de déploiement universel.

L’entrée IETF du répertoire sert uniquement à la navigation institutionnelle ; elle ne prouve pas que l’organisation approuve l’interprétation de cet article.

La méthode éditoriale rejoint ici les essais de Lu Heng sur la primauté du code en fonctionnement, la spécification initiale minimale et la décision locale et les couches de réalité. Ces textes ne sont pas des sources historiques sur PGP ; ils fournissent une règle de lecture : ne pas attribuer à un reçu technique l’autorité d’un fait qu’il n’a pas observé.

L’héritage le plus robuste de RFC 1991 n’est donc pas une promesse de preuve totale. C’est l’idée qu’un objet complexe reste intelligible lorsque chaque transformation conserve sa frontière.