Résumé
- Avec
multipart/signed, la RFC 2015 a laissé le corps MIME lisible dans une première partie et placé la signature PGP détachée dans une seconde, sans retirer les en-têtes MIME du périmètre signé. - La contrepartie était stricte : CRLF, encodage sept bits, espaces de fin de ligne et lignes commençant par
Fromdevaient être stabilisés avant la signature. - Une vérification réussie relie des octets, une signature et une clé ; elle ne prouve seule ni l’identité civile, ni l’intention, ni la livraison, ni l’autorité du signataire.
La difficulté n’était pas seulement de greffer PGP sur le courrier électronique. Une ancienne forme application/pgp obligeait le logiciel à comprendre les structures propres à PGP pour retrouver le texte signé. La RFC 2015 a repris le cadre indépendant du protocole défini par la RFC 1847 : deux parties exactement, le message MIME signé d’abord, les données de contrôle ensuite. Un agent MIME pouvait ainsi reconnaître et afficher la structure même s’il ne savait pas vérifier PGP.
Cette séparation rendait le corps accessible, mais non interchangeable. Pour un texte, l’expéditeur choisissait d’abord sa représentation, normalisait les fins de ligne en CRLF, appliquait un Content-Transfer-Encoding, ajoutait les en-têtes de contenu, puis calculait la signature sur l’ensemble. Signer aussi les en-têtes empêchait un intermédiaire de modifier le type ou l’encodage du contenu tout en conservant un corps apparemment inchangé.
Le transport SMTP expliquait la règle des sept bits. Une passerelle pouvait convertir un contenu huit bits en Quoted-Printable ou en Base64 afin de franchir un prochain saut plus ancien. La conversion sauvait la livraison mais changeait l’entrée du hachage. La représentation sûre pour le transport devait donc devenir la représentation signée, avant le départ.
L’exemple de la RFC 2015 désigne deux fragilités modestes. Une ligne commençant par From pouvait recevoir un caractère > dans certains formats de boîte aux lettres. Des espaces finaux pouvaient disparaître, notamment lors d’un passage par des systèmes comme BITNET. Le lecteur voyait encore la même phrase ; le vérificateur, lui, recevait d’autres octets. La RFC 3156 a ensuite précisé la restauration de CRLF, la protection des espaces et le cas délicat de la dernière ligne.
Le chiffrement seul disposait d’une marge différente : son objet opaque pouvait conserver du huit bits. Une signature détachée, en revanche, demandait au destinataire de recalculer le hachage sur une première partie lisible et donc exposée aux « améliorations » du chemin. Même un objet signé puis chiffré devait préserver la forme sept bits de l’objet signé intérieur.
La RFC 2480 a formulé le choix opérationnel des passerelles. Vers un environnement non-MIME, elles devaient pouvoir soit transporter le multipart de sécurité sans le modifier, soit démonter multipart/signed pour rendre le contenu utilisable. Dans ce second cas, la signature ne restait plus valide : elle devait être conservée avec un avertissement. Vérifier ou re-signer à la passerelle ajoutait un nouveau dépositaire de clés et devait rester désactivé par défaut.
La portée probatoire demeure volontairement limitée. Un succès indique que le vérificateur a reconstruit l’entité MIME attendue et validé la signature avec une clé donnée. Une politique distincte doit relier cette clé à une personne ou à un rôle. Rien dans ce résultat n’établit à lui seul qui a rédigé les mots, si le signataire avait mandat, si le destinataire les a vus, ni si une action annoncée a eu lieu. Un échec ne nomme pas davantage un attaquant : il peut venir d’une conversion, d’un mauvais stockage, d’une clé erronée ou d’une construction défectueuse.
La leçon durable de la RFC 2015 est donc antérieure à la cryptographie : il faut décider quelle représentation le réseau n’a plus le droit de réécrire.
Sources
- RFC 1847 — multiparts de sécurité pour MIME
- RFC 2015 — sécurité MIME avec PGP
- RFC 2480 — passerelles et multiparts de sécurité MIME
- RFC 3156 — sécurité MIME avec OpenPGP
- Fiche Datatracker de la RFC 1847
- Fiche Datatracker de la RFC 2015
- Fiche Datatracker de la RFC 2480
- Fiche Datatracker de la RFC 3156
- Errata de la RFC 1847
- Errata de la RFC 2015
- Errata de la RFC 2480
- Fiche RFC Editor de la RFC 3156
- Errata de la RFC 3156
- Fiche RFC Editor de la RFC 1847
- Fiche RFC Editor de la RFC 2015
- Fiche RFC Editor de la RFC 2480
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
