Zusammenfassung

  • RFC 9787 Abschnitt 9.5 behandelt einen gespeicherten Entwurf als anderen Sicherheitszustand als die tatsächlich versandte Nachricht. Ein geschützter Entwurf soll ausschließlich für das Zertifikat des Benutzers oder einen gleichwertigen, nur von ihm beherrschten Schlüssel verschlüsselt werden; vorgesehene Empfänger sollen ihn erst beim wirklichen Versand lesen können.

  • Die schwierige Stelle liegt zwischen Geräten. Ein zweiter Mail User Agent kann denselben geschützten Entwurf nur fortsetzen, wenn er auf dieselbe Mailbox und auf geeignetes geheimes Entschlüsselungsmaterial zugreifen kann. RFC 9787 bezeichnet den sicheren Austausch lokaler Zertifikate und geheimer Schlüssel zwischen mehreren MUAs ausdrücklich als offenen Bereich außerhalb seiner derzeitigen Anleitung.

  • Das Verbot, einen Entwurf mit dem normalen Signaturschlüssel zu signieren, zieht eine zweite Grenze. RFC 9787 warnt davor, eine nicht abstreitbare Signatur unter unfertigem Text könne nach einem Leck als Ausdruck einer bereits erfolgten Festlegung dargestellt werden. Das ist eine protokollbezogene Sicherheitsbegründung, keine allgemeine Aussage über Rechtswirkung.

  • Für die Praxis fehlt damit weniger ein weiterer Statusname als belastbare Evidenz über den Übergang. Der hier vorgeschlagene „Gewahrsamsbeleg für die Entwurfsabsicht“ soll knapp dokumentieren, welches Objekt welcher Client bearbeiten durfte und wann daraus tatsächlich ein Versandobjekt wurde. Er ist ein redaktioneller Vorschlag, keine Anforderung von RFC 9787.

Stellen wir uns einen ausdrücklich hypothetischen Vorgang vor. Auf einem Laptop werden einige noch unfertige Sätze automatisch gespeichert. Minuten später wird auf einem Telefon dieselbe Mailbox geöffnet, und genau dieser Arbeitsstand erscheint wieder. Diese Wiederkehr soll zwei Dinge gerade nicht bedeuten: Die vorgesehenen Empfänger dürfen den Text noch nicht lesen, und aus der bloßen Speicherung soll nicht folgen, dass sich der Autor bereits auf seinen Inhalt festgelegt hat.

Dieses kleine Gerätewechsel-Szenario legt den Kern von RFC 9787 offen. Das im August 2025 veröffentlichte Dokument ist Informational und ausdrücklich kein Standards-Track-RFC. Gleichwohl verwendet es für seine Implementierungsanleitung die üblichen normativen Schlüsselwörter. Besonders klar wird die Trennung in Abschnitt 9.5: Ein Entwurf ist nicht einfach eine frühe Kopie der späteren Nachricht. Er besitzt eine andere Autoritätslage.

Der entfernte Drafts-Ordner ist Teil des Bedrohungsmodells

RFC 9787 setzt bei einem vertrauten Verhalten moderner Mailprogramme an: MUAs speichern unfertige Nachrichten in einem Drafts-Ordner. Liegt dieser Ordner auf einem entfernten System, etwa einer IMAP-Mailbox, kann ein Klartextentwurf dort für den Betreiber oder einen Angreifer lesbar werden, obwohl die später versandte Nachricht Ende-zu-Ende-verschlüsselt wäre.

Daraus folgt die Empfehlung, Entwürfe grundsätzlich zu verschlüsseln, solange der Client nicht ausdrücklich weiß, dass die fertige Nachricht ohnehin unverschlüsselt gesendet werden soll oder der Drafts-Speicher einem potenziellen Angreifer nicht lesbar ist. Die Sicherheitsentscheidung wird damit zeitlich vorgezogen: Der MUA muss einen unfertigen Zustand schützen, bevor alle Parameter des späteren Versands feststehen.

Entscheidend ist, für wen verschlüsselt wird. Ein geschützter Entwurf muss nach RFC 9787 ausschließlich für das Zertifikat des Benutzers oder für einen gleichwertigen geheimen Schlüssel verschlüsselt sein, den nur der Benutzer besitzt. Die geplanten Empfänger gehören in diesem Zustand nicht zum Leserkreis. Empfängerverschlüsselung ist dem tatsächlichen Versand vorbehalten.

Damit wird die gewöhnliche Vorstellung „Diese Mail geht an A und B, also verschlüssele für A und B“ während des Schreibens bewusst ausgesetzt. Der Entwurf ist noch Arbeitsmaterial des Autors. Erst das Senden verändert diese Beziehung.

Der zweite Client macht das Problem sichtbar

Auf einem einzigen Gerät ist diese Trennung vergleichsweise leicht zu verstehen. Schwieriger wird sie, sobald das hypothetische Telefon den auf dem Laptop gespeicherten Entwurf fortsetzen soll.

Der zweite MUA braucht zunächst Zugriff auf dieselbe Mailbox. Das reicht aber nicht. Er muss auch über einen geheimen Schlüssel verfügen, mit dem sich der autorbezogen verschlüsselte Entwurf entschlüsseln lässt. Genau hier verweist RFC 9787 auf sein eigenes ungelöstes Stück Infrastruktur. Anhang A.4.1 beschreibt die sichere und effiziente gemeinsame Nutzung lokaler Zertifikate und geheimer Schlüssel zwischen mehreren MUAs als Gegenstand möglicher künftiger Anleitung, nicht als bereits standardisierte Lösung.

Anhang A.4.2 nennt tragbare, hardwaregestützte Schlüssel als eine mögliche Richtung, weist aber ebenfalls auf praktische Bedienungsfragen hin und definiert dafür keine allgemeine Entwurfsarchitektur. Die Grenze des gesicherten Wissens ist deshalb wichtig: Aus RFC 9787 folgt nicht, dass ein bestimmtes geräteübergreifendes Schlüsselverteilungsverfahren verbreitet oder interoperabel eingesetzt würde.

Auch S/MIME 4.0 und OpenPGP liefern kryptografische Bausteine für Nachrichtenverschlüsselung und Signaturen. Die hier geprüften Dokumente belegen jedoch keine breite Nutzung eines standardisierten, geräteübergreifenden Entwurfsschlüsselsystems. Nachrichtenkryptografie und der operative Lebenszyklus eines veränderlichen Entwurfs sind nicht dasselbe Problem.

Speichern ist nicht Signieren

Die zweite harte Abgrenzung betrifft den Signaturschlüssel. RFC 9787 schreibt für einen konformen MUA vor, einen Entwurf nicht mit dem normalen Signaturschlüssel des Benutzers zu signieren. Seine Begründung ist eng gefasst: Eine nicht abstreitbare Signatur könne eine Festlegung des Absenders ausdrücken; gelangte ein solcher signierter Entwurf von einem nicht vertrauenswürdigen Drafts-Speicher nach außen, könnte behauptet werden, der Benutzer habe sich auf einen Inhalt festgelegt, den er noch gar nicht endgültig beschlossen hatte.

Daraus sollte keine allgemeine juristische Regel konstruiert werden. Der RFC definiert weder Vertragsrecht noch Beweisrecht. Er beschreibt eine Sicherheits- und Bedeutungsgefahr der verwendeten Kryptografie: Ein Schlüssel, dessen gewöhnliche Funktion eine fertiggestellte Aussage authentisiert, soll nicht routinemäßig auf ein noch veränderliches Arbeitsobjekt angewendet werden.

Für eine koordinierte Signierung von Entwürfen zwischen mehreren MUAs deutet RFC 9787 einen anderen Schlüssel an. Einen Mechanismus, ein Austauschprotokoll oder eine allgemeine Semantik dafür spezifiziert er nicht. Gerade diese Leerstelle ist aufschlussreich. Die Norm sagt relativ präzise, was nicht verwechselt werden soll, ohne daraus eine vollständige Infrastruktur für kollaborierende Clients abzuleiten.

Speicherstatus und kryptografische Autorität sind verschiedene Ebenen

Mailprotokolle besitzen längst Begriffe für Entwürfe. IMAP4rev2 definiert das System-Flag \Draft. RFC 6154 beschreibt mit \Drafts eine besondere Mailbox-Nutzung. JMAP Mail verwendet $draft; sein Versandbeispiel zeigt zudem, wie eine erfolgreiche Einreichung den Draft-Status entfernt und ein Objekt aus Drafts nach Sent verschieben kann.

Diese Mechanismen sind wertvoll, aber sie beantworten eine andere Frage. Sie klassifizieren oder verändern Speicher- und Lebenszykluszustände. Sie definieren nicht vollständig, welcher kryptografische Schlüssel den Zwischenzustand schützen darf, welche Clients ihn verändern dürfen oder wann die gewöhnliche Signatur des Autors erstmals angemessen ist.

Man kann daher zwei Achsen auseinanderhalten. Auf der einen liegt der Mailboxzustand: Entwurf, Einreichung, gesendete Ablage. Auf der anderen liegt die Autorität über das Objekt: Wer kann lesen, wer kann verändern, wer kann eine endgültige Absenderhandlung auslösen? RFC 9787 macht sichtbar, dass ein sicherer MUA beide Achsen koordinieren muss.

Ein „Gewahrsamsbeleg für die Entwurfsabsicht“

Für genau diesen Übergang schlage ich als redaktionelles Instrument einen Gewahrsamsbeleg für die Entwurfsabsicht vor. Er ist weder Bestandteil noch Anforderung von RFC 9787. Sein Zweck wäre enger: Bei geräteübergreifender Fortsetzung soll nachvollziehbar bleiben, welches veränderliche Objekt geschützt gespeichert wurde, wer es bearbeiten konnte und welches konkrete Ereignis aus diesem Entwurfszustand eine tatsächlich gesendete Nachricht machte.

Ein solcher kurzer Beleg könnte eine Objekt- und Versionsreferenz, die Speicherklasse, die autorbezogene Verschlüsselungs- und Schlüsselklasse, die entschlüsselungs- oder änderungsfähigen Clients sowie den Letztschreiber- oder Merge-Zustand festhalten. Hinzu käme die Bestätigung, dass der normale Signaturschlüssel diesen Entwurf nicht signiert hat – ausdrücklich nicht die Behauptung, dieser Schlüssel habe sich nicht auf einem Gerät befunden. Vor dem Versand sollte der Datensatz festhalten, dass noch keine Empfängerverschlüsselung vorgenommen wurde. Beim echten Sendeereignis kämen ausführender Client, Zeitpunkt und ein Digest der finalen Empfängermenge hinzu, außerdem ein Objekt-Hash, der Zustand der Bereinigung oder eines Tombstones sowie der für Prüfung und Ablauf verantwortliche Akteur.

Gerade weil es nur Hilfsevidenz sein soll, gehört der Inhalt der Nachricht nicht hinein. Auch Betreff, unbegrenzte Aufzählungen, geheime Schlüssel, Zugangsdaten oder allgemeine Protokollsammlungen hätten dort nichts verloren.

Selbst diese Reduktion braucht Schutz. Ein gewöhnlicher Hash ist keine automatische Anonymisierung. Werte mit geringer Entropie können durch Ausprobieren wiedererkannt werden; wiederkehrende Hashwerte können Datensätze miteinander korrelierbar machen. Wo solche Evidenz überhaupt benötigt wird, sind deshalb je nach Umgebung schlüsselgebundene oder streng zugriffsgeschützte Nachweise, klare Zweckbindung und kurze Aufbewahrung vernünftiger als eine dauerhaft wachsende Metadatenspur.

Was die Quellen nicht belegen

Die Evidenzgrenze bleibt schmal. Die zum Stichtag abgefragte Errata-Suche für RFC 9787 weist keine passende RFC-9787-Errata aus. Die geprüften Quellen liefern zugleich keinen belastbaren Nachweis über Marktverbreitung, Herstellerkonformität, einen gemessenen realen Entwurfsleck-Vorfall, allgemeine Rechtswirkungen oder einen standardisierten Austausch von Entwurfsschlüsseln zwischen Geräten.

Gerade deshalb darf Implementierungsanleitung nicht mit beobachteter Implementierung verwechselt werden. RFC 9787 beschreibt eine Sicherheitsgrenze. Ob ein konkretes Produkt diese Grenze tatsächlich einhält, wäre eine eigene empirische Frage.

Quellen