Résumé

  • HP-Outer atteste, à l’intérieur de l’enveloppe chiffrée, les valeurs d’en-tête que l’auteur a volontairement laissées à l’extérieur ; il ne prétend pas observer tout le trajet du message.
  • Le paramètre hp décrit une intention de composition, tandis que les couches MIME reçues déterminent l’état cryptographique réel ; aucune icône globale ne peut remplacer cette distinction.
  • En cas de divergence entre les champs From, l’affichage, la validation d’identité et l’adresse utilisée pour répondre obéissent à des preuves différentes afin d’éviter à la fois l’usurpation et la fuite.

La scène critique ne se produit pas forcément à l’ouverture du courriel. Elle survient lorsque le destinataire clique sur « répondre ».

Le corps a été déchiffré. L’interface a affiché un cadenas. Pourtant, deux adresses d’expéditeur coexistent : l’une dans l’en-tête extérieur que les serveurs ont vu, l’autre dans la partie protégée de bout en bout. Si un intermédiaire a modifié la première, la reprendre comme destinataire de la réponse peut lui livrer la conversation. Si l’auteur malveillant a placé une fausse identité dans la seconde sans signature correctement liée, l’afficher comme vérité crée un autre canal d’usurpation.

Le RFC 9788 est précisément intéressant parce qu’il n’essaie pas de résoudre ces questions avec un adjectif unique comme « sécurisé ». Il oblige le logiciel à conserver la provenance des affirmations.

Une structure cryptographique, pas une couleur d’interface

Le RFC 9787 décrit un message S/MIME ou PGP/MIME comme une succession ordonnée de couches MIME. Une couche de signature apporte intégrité et authenticité selon la validation réalisée. Une couche de chiffrement apporte confidentialité, avec des propriétés d’intégrité qui dépendent du format. Leur ordre change le sens : signer puis chiffrer n’est pas chiffrer puis signer.

L’enveloppe cryptographique est le plus grand ensemble continu de couches partant du type MIME extérieur. Dès qu’une partie non cryptographique interrompt la continuité, les objets cryptographiques plus profonds ne peuvent plus donner leur statut à l’ensemble du message. Le contenu protégé est la première partie non cryptographique à l’intérieur de cette enveloppe.

Cette topologie est la réalité reçue. Elle doit primer sur le pictogramme, le nom commercial d’une fonction ou l’intention déclarée. Le RFC 9788 applique cette discipline aux en-têtes, longtemps laissés à l’extérieur alors que le corps était protégé. Un attaquant pouvait modifier le sujet ou l’auteur apparent sans nécessairement casser le chiffrement du corps.

Le mécanisme ancien du RFC 8551 plaçait un message message/rfc822 complet dans l’enveloppe. Des logiciels historiques l’ont mal rendu ou mal interprété. Le RFC 9788 remplace ce montage : les champs connus du compositeur sont copiés directement dans la charge cryptographique. Pour un message chiffré, chaque champ non structurel peut rester identique dehors, être masqué, ou être supprimé.

Ces trois gestes ne produisent pas la même confidentialité. Une copie chiffrée ne retire pas magiquement la copie claire déjà offerte au transport.

Le reçu que transporte HP-Outer

Le nouveau champ HP-Outer réside dans la charge chiffrée. Pour chaque en-tête non structurel volontairement exposé à l’extérieur, le logiciel émetteur doit y consigner le nom et la valeur extérieure qu’il a choisis au moment de l’injection.

Si Subject a été remplacé par [...], ce remplacement figure dans le reçu protégé. Si Date est resté identique, sa valeur claire est également enregistrée. Si un champ présent dans la partie protégée n’a aucun HP-Outer correspondant, le compositeur affirme qu’il n’en a placé aucune occurrence à l’extérieur.

Cette affirmation est bornée. Elle prouve la décision du compositeur parce que le reçu partage les garanties cryptographiques du message. Elle ne prouve pas qu’un relais n’a rien ajouté, effacé ou réécrit ensuite. Elle ne prouve pas non plus qu’un adversaire ne puisse déduire la même information par l’adresse de livraison, les identifiants de clés, l’ordre d’une boîte aux lettres ou les champs Received.

Le reçu empêche toutefois une erreur subtile. Supposons que l’auteur laisse Cc en clair tout en le copiant dans la charge protégée. Un intermédiaire retire ensuite le Cc extérieur. Un client naïf, comparant seulement l’état final, conclurait que le champ a toujours été caché. Le HP-Outer signé révèle au contraire l’exposition initiale. Pour l’affichage, le champ ne mérite pas le statut « chiffré » ; pour une future réponse, le client doit néanmoins éviter de le republier en clair.

La nuance n’est pas du formalisme. Elle sépare le constat, l’acte enregistré et la conséquence. C’est la discipline des couches de réalité : un reçu vaut pour ce qu’il a observé, pas pour la totalité du monde autour de lui.

Une politique dont le nom ne circule pas

Le RFC appelle HCP la politique de confidentialité des en-têtes. Elle prend un nom et une valeur, puis renvoie la valeur inchangée, une valeur masquée ou null, c’est-à-dire la suppression du champ extérieur.

La politique recommandée hcp_baseline choisit un compromis conservateur. Elle remplace le sujet par [...], enlève Comments et Keywords, et laisse les autres champs passer. hcp_shy va plus loin : elle retire les noms d’affichage dans From, To et Cc, et convertit la date en UTC. Cette seconde option protège davantage de métadonnées lisibles par un humain, mais exige une analyse plus sophistiquée et peut gêner le rendu ou la délivrabilité.

Le nom de la politique n’est jamais transmis. Le destinataire en voit seulement les décisions via HP-Outer. Le registre de l’IANA fournit des descriptions stables et indique lesquelles sont recommandées. Une ligne de registre ne certifie ni un logiciel installé, ni la configuration d’un compte, ni le traitement d’un message donné.

Cette architecture garde la couche commune mince. Elle normalise une syntaxe et des fonctions testables, tout en laissant l’adoption de politiques plus ambitieuses aux environnements capables d’en assumer le coût. Effacer To, Cc, References ou In-Reply-To peut réduire l’exposition, mais casser le filtrage, les listes, les fils de discussion ou le diagnostic. La confidentialité supplémentaire doit être mesurée dans le code qui fonctionne.

hp raconte le projet, les couches racontent l’arrivée

Le paramètre MIME hp précise l’intention d’origine. cipher signifie que le compositeur a voulu protéger les en-têtes dans un message chiffré ; clear accompagne une construction seulement signée. Il ne remplace pas l’inspection de l’enveloppe reçue.

Un message uniquement signé qui porte à tort hp=cipher reste uniquement signé. Le logiciel ne doit pas gonfler son estimation de la confidentialité. À l’inverse, un intermédiaire peut entourer de chiffrement un message initialement signé sans chiffrement. Le destinataire voit alors une couche chiffrée que l’auteur n’avait pas créée.

Dans ce cas, l’absence de HP-Outer ne permet pas de conclure que tous les en-têtes étaient cachés lors de la composition. Les couches décrites par le RFC 9787 établissent ce qui est arrivé ; hp documente ce que le compositeur semble avoir tenté ; les champs extérieurs indiquent ce que le dernier état expose. Aucun de ces éléments ne peut absorber les deux autres.

Une journalisation qui conserve seulement encrypted=true rend l’enquête impossible. Il faut garder l’arbre MIME, l’ordre des couches, la valeur hp, les reçus HP-Outer, les en-têtes extérieurs réellement reçus et la décision de rendu.

Deux From, trois questions

Le champ From met en contact l’authentification du transport et celle de bout en bout. Le système de transport peut évaluer l’adresse extérieure. Une signature peut protéger l’adresse intérieure. Mais protéger des octets ne suffit pas : le certificat doit être valablement lié à cette adresse.

Le RFC 9788 définit une divergence lorsque les addr-spec intérieur et extérieur diffèrent. Si cette divergence coïncide avec l’absence d’une signature valide et correctement liée, le client devrait afficher un avertissement comparable à celui d’une tentative d’hameçonnage et présenter les deux valeurs.

Pour le rendu, un client qui dépend de l’évaluation réalisée par le transport devrait revenir à l’adresse extérieure effectivement vue par celui-ci. Cela évite d'offrir à un compositeur malveillant une nouvelle identité prestigieuse simplement parce qu’elle se trouve dans une zone chiffrée.

Pour répondre, le choix s’inverse : seuls les champs protégés doivent alimenter les destinataires. Une adresse extérieure modifiable ne doit pas pouvoir détourner une réponse confidentielle. Affichage et action ne posent donc pas la même question. Le premier cherche une représentation prudente ; la seconde refuse qu’un intermédiaire commande la destination.

Le nom humain affiché constitue encore un niveau distinct. Le RFC 9787 rappelle qu’un nom n’est pas globalement unique et peut ne pas être couvert par la liaison entre certificat et boîte aux lettres. Une interface qui grossit le nom et cache l’adresse peut annuler la précision cryptographique du protocole.

La confidentialité dépend de l’observateur

Un en-tête peut être protégé contre les relais et visible à tous les destinataires. Il peut être absent de l’extérieur mais déductible de la destination SMTP ou des identifiants de clés. Il peut être masqué à haute résolution alors que les champs ajoutés pendant le transport restituent l’heure. Il peut révéler au destinataire une version de logiciel par User-Agent ou un nom de machine par Message-ID.

Le cas Bcc rappelle la limite la plus simple : le chiffrement ne cache rien au destinataire auquel les données sont remises. Une mauvaise construction peut placer la liste cachée dans la charge destinée à la mauvaise personne. Le cryptosystème livre fidèlement l’erreur.

Les listes de diffusion ajoutent d’autres champs après la composition. Ceux-ci peuvent servir à l’interface mais restent extérieurs à la garantie de bout en bout. Une réponse ou un transfert peut enfin recopier un sujet ou une citation déchiffrés dans un message clair.

La conclusion n’est pas que la protection des en-têtes échoue. Elle est plus exigeante : chaque champ, chaque observateur et chaque action nécessitent leur propre preuve.

Sources

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — Primauté du code en fonctionnement
  10. Heng Lu — Spécification initiale minimale et décision future localisée
  11. Heng Lu — Couches de réalité et pouvoir symbolique