Zusammenfassung

  • RFC 3923 schützte ein CPIM-Objekt mit S/MIME und transportierte es in einer XMPP--Hülle; deren Namensraum definierte nicht die Bedeutung der Nachricht.
  • Ein XMPP-CPIM-Gateway durfte die Diensthülle entfernen oder hinzufügen, musste das geschützte Objekt aber unverändert weiterleiten.

Was das Gateway ändern durfte

Ein Gateway verbindet Nachrichtendienste, die unterschiedliche Protokolle sprechen. Sobald ein Dienst eine Nachricht übersetzt, stellt sich jedoch eine Sicherheitsfrage: Was darf er ändern, ohne selbst Teil der Vertrauensgrenze zu werden? RFC 3923, im Oktober 2004 als IETF-Standard veröffentlicht, zog die Vertrauensgrenze bewusst eng. Ein XMPP-CPIM-Gateway durfte die Hülle eines Dienstes abnehmen und die eines anderen anbringen. Das darin enthaltene signierte oder verschlüsselte S/MIME-Objekt durfte es nicht verändern.

So ließ sich Ende-zu-Ende-Schutz zumindest an der Protokollgrenze mit einem Vermittler vereinbaren, der beide Dienste verstand. Das Gateway war kein kryptografischer Endpunkt, sondern transportierte das geschützte Objekt als undurchsichtige Nutzlast. Die Architektur trennte damit die Interoperabilität von Signatur, Verschlüsselung und inhaltlicher Auslegung.

Ein geschütztes Objekt in einer XMPP-Stanza

Der Absender erzeugt zunächst ein Message/CPIM-Objekt. Es enthält sowohl Kopfzeilen als auch Inhalt; RFC 3923 verlangt, dass beides von der S/MIME-Signatur oder -Verschlüsselung erfasst wird. Das Ergebnis liegt anschließend in einem XML-CDATA-Abschnitt, der in einem <e2e/>-Kind einer XMPP-Message- oder Presence-Stanza steht. Je nach Anwendungsfall kann das eingeschlossene Objekt auch ein PIDF-Präsenzdokument oder ein XMPP-XML-Objekt sein.

<e2e/> transportiert, interpretiert aber nicht. Laut RFC hat sein Namensraum keine eigene Semantik; maßgeblich sind die Spezifikationen für CPIM, PIDF oder XMPP. Ein Vermittler muss den geschützten Inhalt also nicht verstehen, nur weil er die äußere XMPP-Stanza parsen kann.

Daraus folgt die Gateway-Regel. Verlässt eine Nachricht XMPP, entfernt das Gateway die XMPP-Hülle einschließlich der <e2e>-Tags, legt das mehrteilige S/MIME-Objekt frei und leitet es weiter. Bei Bedarf ergänzt es die Hülle des Nicht-XMPP-Dienstes. In Gegenrichtung entfernt es die Nicht-XMPP-Hülle, setzt dasselbe Objekt in eine XMPP-Hülle und leitet die Stanza weiter. RFC 3923 schreibt ausdrücklich vor, dass das verpackte S/MIME-Objekt unveränderlich ist und vom XMPP-CPIM-Gateway nicht modifiziert werden darf.

Eine Grenze, kein vollständiges Sicherheitssystem

Unveränderlichkeit ist eine klare Protokollvorgabe, aber kein Beleg dafür, dass ein eingesetztes Gateway sie einhält. Auch macht die Hülle nicht alle Begleitumstände vertrauenswürdig. Empfänger benötigen weiterhin Zertifikate, müssen sie prüfen und entscheiden, was eine Signatur über die Identität des Absenders aussagt. RFC 3923 behandelt die Zertifikatsregistrierung nicht und verlangt vom empfangenden Agenten einen Mechanismus zum Abruf von Zertifikaten. Das Versprechen betrifft daher den Erhalt eines geschützten Objekts auf einem konkreten Interoperabilitätspfad, nicht die Lösung von Identität, Schlüsselverteilung oder Benutzeroberflächen.

Der betriebliche Zielkonflikt liegt offen. Undurchsichtiger Transport erlaubt einem Vermittler, Inhalt weiterzugeben, den er nicht gefahrlos umschreiben sollte, begrenzt aber die Möglichkeiten zur Umwandlung und Prüfung. Muss ein Dienst den Inhalt konvertieren, werden der Ort dieser Konvertierung und ihre Wirkung auf die Signatur entscheidend. Ein signaturgeschütztes Objekt zu ändern ist keine neutrale Übersetzung; die Entscheidung bleibt bei den Endpunkten.

RFC 7165 beschrieb 2014 den S/MIME-Ansatz als nicht weit verbreitet und nannte Herausforderungen beim Schlüsselmanagement und bei der Verarbeitung von S/MIME-Objekten als Teilgründe. Das ist eine zeitgebundene Beobachtung eines Standardsdokuments, keine heutige Nutzungserhebung und keine monokausale Erklärung. Sie verdeutlicht dennoch die historische Lehre: Eine saubere Grenze kann die kryptografische Bedeutung bewahren, während Produktintegration und Schlüsselmanagement schwierig bleiben. RFC 3923 machte Gateways nicht vertrauenswürdig. Es zeigte, dass Interoperabilität nicht voraussetzt, dass sie ändern, was die Endpunkte geschützt haben.

Quellen