Résumé

  • Le résumé du RFC 9787 agrège uniquement les couches de signature et de chiffrement contiguës autour du Crypto Payload.
  • Une signature imbriquée valide, un fragment déchiffrable ou un message transféré peuvent avoir un résultat propre sans modifier le statut du message englobant.
  • Répondre, joindre un fichier et relire une archive sont de nouvelles opérations : elles exigent leurs propres preuves et décisions.

Une indication doit nommer son périmètre

Le RFC 9787 définit l'enveloppe cryptographique comme la série continue de couches entourant une charge utile. C'est cette enveloppe, et non l'ensemble de l'écran, qui produit le résumé. Une couche située ailleurs dans l'arbre MIME est « errante » pour ce calcul.

Les formats OpenPGP/MIME, S/MIME et le socle MIME donnent une structure, pas une contagion d'autorité. Une signature intérieure peut être valide sans couvrir une introduction extérieure, un pied de liste ou une pièce jointe voisine.

Une liste de diffusion illustre le changement d'objet. Elle peut envelopper un message signé puis ajouter son pied de page. La signature reste pertinente pour la partie intérieure, mais devient errante par rapport au message reçu par l'abonné. Le résumé supérieur est alors non protégé. L'interface peut expliquer le résultat intérieur séparément ; elle ne peut pas annoncer que tout le message reçu est signé.

Déchiffrer n'autorise pas à recomposer

Un client peut déchiffrer une partie errante pour la consultation. Il doit toutefois rendre le clair comme un sous-arbre MIME séparé, sans le greffer dans du HTML environnant contrôlable par un attaquant, et sans présenter le message entier comme chiffré. Les travaux EFAIL et sur les oracles multipart expliquent cette prudence : une réussite cryptographique locale n'est pas une autorisation de composition.

Un bloc OpenPGP en ligne, même conforme au format actuel du RFC 9580, ne fournit pas une signature validante au résumé s'il se trouve hors du modèle MIME. Son clair ne doit pas être recopié automatiquement dans une réponse.

Le transfert et la réponse ouvrent un nouveau dossier

Un objet transféré message/rfc822 ou message/global, fondé sur les RFC 5322 et 6532, peut posséder sa propre enveloppe. Son résumé est distinct de celui du message extérieur. L'interface doit rattacher visuellement chaque état à son objet.

Une réponse est un nouveau message et une nouvelle divulgation. Si le résumé global de l'original est chiffré, le RFC 9787 impose de chiffrer la réponse ou de supprimer la citation. Sans certificat de chiffrement non expiré pour chaque destinataire, la citation disparaît sauf choix explicite de l'utilisateur. La recherche sur les attaques par réponse montre pourquoi la citation n'est pas un simple geste éditorial. Le contenu déchiffré d'une partie errante ne doit jamais y entrer implicitement.

Pièces jointes et archives ont leurs propres preuves

Les pièces jointes appartiennent au Crypto Payload commun. Des enveloppes séparées permettraient retrait, substitution ou réorganisation sans intégrité globale et rendraient un badge unique trompeur. Seul l'arbre MIME analysé prouve qu'une pièce se trouve dans le périmètre ; l'icône trombone ne le prouve pas.

Le certificat qui expire plus tard ne détruit pas rétroactivement le chiffré. Si la clé secrète nécessaire existe encore, le client devrait permettre le déchiffrement. L'expiration organise rotation et destruction ; l'avertissement historique concerne un certificat déjà expiré au moment du chiffrement. Copie exacte chiffrée pour l'expéditeur, versions distinctes, clair conservé ou clés de session archivées produisent des risques et des garanties différents.

Le RFC 9788 traite le domaine voisin de la protection des en-têtes, sans être repris ici. La fiche RFC Editor, le Datatracker et la recherche d'errata établissent le dossier documentaire, pas l'implémentation d'un produit.