Zusammenfassung

  • HP-Outer hält im verschlüsselten Payload fest, welche nichtstrukturellen Header der Verfasser bewusst außen sichtbar machte; der Beleg beschreibt die Komposition, nicht den gesamten Transportweg.
  • Der tatsächliche MIME-Schichtenbau bestimmt den empfangenen kryptografischen Zustand. Der Parameter hp dokumentiert Absicht und darf fehlende Verschlüsselung nicht ersetzen.
  • Inneres und äußeres From, Signaturbindung, Transportauthentisierung, dargestellter Absender und Antwortziel benötigen getrennte Autorisierung, weil sie verschiedene Angriffe begrenzen.

Eine Signatur kann vollkommen gültig sein und trotzdem die falsche Frage beantworten. Sie zeigt, dass eine geschützte Zeichenfolge seit dem Signieren unverändert blieb. Sie zeigt nicht automatisch, dass das verwendete Zertifikat zur darin genannten Mailadresse gehört. Und sie sagt nichts darüber, welche Adresse der Transport geprüft hat.

Bei einem verschlüsselten Brief mit zwei unterschiedlichen From-Werten führt diese Unterscheidung zu einer scheinbar seltsamen Oberfläche: Das Programm kann vorsichtshalber den äußeren Absender anzeigen, darf die Antwort aber nur aus geschützten Feldern adressieren. Wer diese beiden Entscheidungen auf einen grünen Status reduziert, öffnet entweder einen Spoofing- oder einen Abflusskanal.

RFC 9788 macht aus dieser Spannung eine nachvollziehbare Architektur.

Kryptografie ist im MIME-Baum verortet

RFC 9787 definiert kryptografische Schichten in einer MIME-Struktur. Eine Signaturschicht bietet Integrität und Authentizität, soweit ihre Prüfung trägt. Eine Verschlüsselungsschicht bietet Vertraulichkeit und abhängig von der Form Integrität. Reihenfolge ist Semantik: erst signieren und dann verschlüsseln ist nicht dasselbe wie erst verschlüsseln und dann signieren.

Als kryptografischer Umschlag gilt die größte zusammenhängende Folge solcher Schichten, beginnend beim äußeren MIME-Typ. Der erste nichtkryptografische Teil darin ist der Payload. Unterbricht ein gewöhnlicher MIME-Teil die Folge, verleiht ein tieferes Kryptoobjekt der gesamten Nachricht nicht seinen Zustand. Auch Kompression in CMS ist keine kryptografische Schicht bloß wegen ihres Containers.

Diese empfangene Topologie steht über dem Interface-Symbol. Klassische geschützte Mail verschlüsselte häufig den Body, ließ Betreff und sichtbaren Absender jedoch außen. Ein Angreifer konnte die Darstellung verändern, ohne die Body-Verschlüsselung zu brechen.

RFC 8551 schützte Header, indem es ein vollständiges message/rfc822-Objekt einwickelte. Einige ältere MUAs renderten oder verarbeiteten diese Konstruktion problematisch. RFC 9788 ersetzt sie: Die beim Verfassen bekannten Header werden direkt in den kryptografischen Payload kopiert. Bei verschlüsselter Mail kann ein nichtstrukturelles Feld außen unverändert bleiben, durch einen Ersatzwert verdeckt oder entfernt werden.

Eine verschlüsselte Kopie beweist nicht, welche dieser drei Handlungen geschah. Ein Feld kann gleichzeitig geschützt und für jeden Transportknoten offen sein.

HP-Outer belegt die bewusste Offenlegung

Das neue Feld HP-Outer liegt innerhalb des verschlüsselten Payloads. Für jeden nichtstrukturellen Header, den die verfassende Software bewusst außen platziert, muss es Namen und äußeren Wert geschützt wiederholen.

Wurde Subject außen zu [...], steht dieser Ersatz im Beleg. Blieb Date unverändert, wird das Klartextdatum erfasst. Fehlt für ein geschütztes Feld jeder passende Eintrag, behauptet der Verfasser, beim Einliefern keine Instanz dieses Feldes außen gesetzt zu haben.

Der Beleg ist für diese Handlung stark und für spätere Ereignisse absichtlich schwach. Ein Relay kann anschließend Received hinzufügen, eine Liste eigene Felder eintragen, ein Angreifer das äußere Feld löschen oder ändern. Empfänger-Schlüsselkennungen, SMTP-Umschlag, Mailboxposition oder Timing können verborgene Information indirekt preisgeben.

Gerade dieser begrenzte Beleg verhindert eine falsche Rückschau. Der Verfasser könnte Cc klar außen belassen und zugleich innen schützen. Entfernt ein Angreifer später nur das äußere Cc, würde ein naiver Innen-Außen-Vergleich behaupten, Cc sei von Anfang an vertraulich gewesen. Ein passendes HP-Outer bewahrt die ursprüngliche Offenlegung.

Für die Statusanzeige ist das Feld damit signiert, nicht geheim. Bei einer Antwort darf das Programm es trotzdem konservativ behandeln, damit es nicht erneut in Klartext gerät. Vergangenheitsbeschreibung und nächste Schutzentscheidung sind verschiedene Funktionen.

Das ist Realitätsschichtung in Protokollform: Ein Datensatz erhält keine Autorität über einen Abschnitt, den er nicht beobachtet hat.

HCP ist eine Funktion ohne Drahtetikett

Die Header Confidentiality Policy, HCP, nimmt Namen und Wert eines nichtstrukturellen Headers. Sie gibt den Wert unverändert, eine verdeckte Fassung oder null für Entfernung aus dem äußeren Abschnitt zurück.

Das empfohlene hcp_baseline bleibt konservativ: Subject wird [...], Comments und Keywords verschwinden, andere Felder passieren. hcp_shy entfernt zusätzlich Anzeigenamen aus From, To und Cc und normalisiert Date auf UTC. Das kann mehr menschenlesbare Metadaten verbergen, verlangt aber komplexeres Parsing und kann Zustellung oder Darstellung belasten; deshalb ist es nicht die Standardempfehlung.

Der Name der HCP erscheint nie auf dem Draht. Der Empfänger sieht ihre einzelnen Entscheidungen in HP-Outer. Das IANA-Register hält stabile, implementierbare Beschreibungen und Empfehlungseigenschaften fest. Es bescheinigt weder die Funktion eines Produkts noch eine Kontoeinstellung oder die Behandlung einer bestimmten Nachricht.

Die gemeinsame Schicht bleibt damit schmal: Syntax, reproduzierbare Funktion und Registrierung. Ein Betreiber kann To, Cc, References oder In-Reply-To aggressiver verbergen, muss dann aber Filter, Threading, Listen, Suche und Fehleranalyse prüfen. Ein Registereintrag ist kein Zustelltest.

hp dokumentiert den Plan

Der geschützte Content-Type kann den Parameter hp tragen. cipher bedeutet, dass der Verfasser verschlüsselten Header-Schutz beabsichtigte; clear gehört zur nur signierten Form. Was tatsächlich ankam, ergibt sich aus den beobachteten Schichten.

Eine nur signierte Nachricht mit hp=cipher bleibt unvertraulich. Das MUA darf Absicht nicht als Ergebnis darstellen. Umgekehrt kann eine Zwischenstelle eine ursprünglich nur signierte Nachricht nachträglich verschlüsseln. Der Empfänger sieht dann eine reale Verschlüsselungsschicht, die aber nicht vom ursprünglichen Verfasser stammen muss.

Bei dieser Abweichung darf ein fehlendes HP-Outer nicht als Beweis gelten, der Verfasser habe alle Header entfernt. Der Auditdatensatz braucht MIME-Baum und Reihenfolge, hp, sämtliche HP-Outer, die tatsächlich empfangenen Außenfelder und die Parserentscheidung. encrypted=true zerstört diese Herkunft.

Anzeige und Antwort verteidigen unterschiedliche Grenzen

Das äußere From kann von der Transportseite beurteilt werden. Das innere From kann durch eine Ende-zu-Ende-Signatur geschützt sein. RFC 9788 nennt unterschiedliche addr-spec-Werte einen Mismatch.

Geschützt heißt noch nicht identifiziert. Die Signatur muss gültig und das Zertifikat korrekt an die innere Adresse gebunden sein. Fallen Mismatch und fehlende Bindung zusammen, sollte das MUA eine phishingähnliche Warnung ausgeben und beide Werte zeigen.

Ein MUA, das auf die Transportprüfung vertraut, sollte dann den tatsächlich äußeren From als vorsichtige Anzeige verwenden. Sonst könnte ein böswilliger Verfasser eine bekannte Adresse innen schreiben, mit einem unverbundenen Zertifikat signieren und eine neue Spoofing-Oberfläche gewinnen.

Beim Antworten gilt die andere Grenze: Empfänger dürfen nur aus geschützten Feldern stammen. Ein veränderbares Außenfeld darf keinen vertraulichen Antwortstrom umleiten.

Die Regeln widersprechen sich nicht. Darstellung begrenzt falsche Autorenschaft; Antwortadressierung begrenzt Wegmanipulation. Ein menschlicher Anzeigename ist nochmals schwächer, weil er weder global eindeutig noch zwangsläufig in der Zertifikatsbindung enthalten ist.

Vertraulich gegenüber wem?

Ein Header, der innen und außen identisch vorliegt, ist vor Transportknoten nicht geheim. Entfernt man ihn außen, sehen ihn weiterhin alle vorgesehenen Empfänger. Schlüsselkennungen, SMTP-Umschlag, Received und Zeitkorrelation erlauben zusätzliche Schlüsse.

Der Verfasser selbst kann einem Empfänger unbeabsichtigt User-Agent-Version, Hostnamen im Message-ID oder ein Bcc in der falschen Kopie liefern. Verschlüsselung transportiert diesen Fehler zuverlässig.

Mailinglisten und Server ergänzen Felder nach der Komposition; die Nähe zum verschlüsselten Body verleiht ihnen keinen Ende-zu-Ende-Status. Antwort und Weiterleitung können entschlüsselten Betreff, Referenzen oder Zitate in eine klare Nachricht kopieren.

RFC 9788 ist deshalb keine Absage an Header-Schutz. Es ist eine Absage an unbeschränkte Aussagen. Feld, Beobachter, Zeitpunkt und Folgehandlung behalten jeweils ihren eigenen Beleg.

Quellen

  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 — Vorrang laufenden Codes
  10. Heng Lu — Minimale Anfangsspezifikation und lokale Zukunftsentscheidung
  11. Heng Lu — Realitätsschichten und symbolische Macht