DE102004011042B4

DE102004011042B4 - Verfahren und Vorrichtung zur effizienteren und sichereren Codierung von E-Mails

Info

Publication number: DE102004011042B4
Application number: DE102004011042A
Authority: DE
Inventors: Joerg Schwenk
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-03-06
Filing date: 2004-03-06
Publication date: 2008-07-03
Anticipated expiration: 2024-03-07
Also published as: DE102004011042A1

Abstract

Verfahren zur Abbildung von Internet-E-Mails in ein reines XML-Format [XMaiL], dadurch gekennzeichnet,
dass sämtliche der nachfolgend genannten, in einer E-Mail enthaltenen Datenformate in XML-Datenformate überführt werden können:
– RFC 2822,
– MIME (gemäß RFC2045–2047 und RFC2049),
– S/MIME (gemäß RFC2311 und RFC2633),
– CMS/PKCS#7 (gemäß RFC3369),
– HTML (Version 4.01),
– OpenPGP (gemäß RFC2440);
dass die resultierende XML-Struktur [XMaiL] die Struktur der Internet-Mail widerspiegelt, und
dass die resultierende Struktur gemäß XML Schema validiert wird, wobei
– bei Datenformaten gemäß RFC 2822 die Unterteilung einer Internet-Mail in Header und Body dadurch berücksichtigt wird, dass es in der XML-Struktur genau zwei Nachfolgeelemente <Header> und <Body> des Wurzelelements gibt, die diese Struktur widerspiegeln;
– bei Datenformaten gemäß MIME die aus den Multipart-Datentypen des MIME-Standards (RFC2046) festgelegte Struktur in der resultierenden XML-Struktur erhalten bleibt.

Description

Stand der Technik
E-Mail ist neben dem WWW der wichtigste Dienst im Internet, und mit Abstand der ältere von beiden: Der RFC 822 „STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES" datiert vom 13. August 1982, und das darin beschriebene ASCII-basierte Textformat ist auch heute noch die Grundlage aller im Internet versendeten E-Mails.
Schnell stellte sich heraus, dass die Nutzer mit E-Mails mehr übertragen wollen als reinen Text. Man behalf sich zunächst damit, die zu übertragenden Binärdateien von Hand in ein RFC 822-kompatibles Format zu konvertieren (z. B. uuencode unter UNIX), aber dies war keine befriedigende Lösung. So wurden im November 1996 die „Multipurpose Internet Mail Extension (MIME, RFC 2045–2049) verabschiedet, die eine plattformunabhängige Übertragungsmethode für beliebige Daten im RFC 822-Format festlegten. Die wichtigste Codierungsart für Binärdaten ist dabei base64, mit der eine Expansion der Daten um 33% einhergeht. MIME strukturiert die übertragenen Daten dabei in einer baumartigen Struktur, die mit Hilfe von trennenden Zeichenketten („boundary") aufgebaut wird.
Eine konsequente Weiterentwicklung des MIME-Standards stellt Secure MIME (S/MIME, RFCs 2311, 2312, 2630, 2632, 2633, ab März 1998) dar. Hier wird festgelegt, wie MIME-formatierte Daten mit Hilfe moderner kryptographischer Methoden gesichert werden können. Da kryptographische Operationen immer Binärdaten liefern, mussten hierzu die Mailstandards um binäre Datenformate ergänzt werden. Diese basieren letztendlich auf der Datenbeschreibungssprache „Abstract Syntax Notation 1" (ASN.1), die das genaue Gegenteil der MIME-Philosophie verkörpert: eine möglichst kompakte Darstellung der Daten durch bitgenaue Codierung.
Durch die stürmische Entwicklung des WWW verwischten sich die Grenzen zwischen E-Mail und WWW: Bin Standard-E-Mail-Client muss heute HTML-codierte Mails mit eingebetteten Bildern darstellen und das HTTP-Protokoll sprechen können. Inzwischen beginnt XML das spezialisiertere HTML abzulösen, und so müssen die Clients auch hier nachrüsten.
Ein erster Ansatz zur Transformation von MIME-E-Mails in XML-Daten wurde im Jahr 2000 von der Firma Mediaone unter dem Namen „eXtensible Mail Transport Protocol (XMTP)” vorgestellt. Das sehr knapp gehaltene Dokument dazu ist heute noch unter http://xml.coverpages.org/xmtp20000508.html zu finden. Nach Durchsicht dieses Dokuments muss man zu dem Schluss kommen, dass es sich dabei nur um eine direkte Übersetzung von MIME nach XML handelt, die keines der genannten Probleme löst:

• Die Struktur der erzeugten XML-Dokumente ist sehr unklar definiert; ein XML Schema, das eine XMTP-Nachricht akzeptiert, wird auch viele falsche XML- Daten akzeptieren. Das in dieser Anmeldung angegebene XML-Schema kann dagegen gültige von ungültigen XMaiL-Nachrichten klar unterscheiden.
• Um nur ein Beispiel zu nennen: Das MIME-Konstrukt „boundary" wird in MIME dazu verwendet, eine Baumstruktur im Body der E-Mail zu erzeugen. Da XML-Dokumente immer Baumstruktur haben, kann auf dieses Konstrukt eigentlich verzichtet werden, aber XMTP behält es bei.
• Sicherheitsfragen werden bei XMTP in keinster Weise angesprochen.

Die für den Stand der Technik wichtigsten Internetstandards sind (Request for Comments (RFC) der Internet Engineering Task Force (IETF), abrufbar unter http://www.ietf.org/rfc/rfcNNNN.txt):

• Proposed Standard RFC 1341 MIME (Multipurpose Internet Mail Extensions), 1992
• Proposed Standard RFC 1421 Privacy Enhancement for Internet Electronic Mail, 1993
• Draft Standard RFC 1521 MIME (Multipurpose Internet Mail Extensions), 1993
• Proposed Standard RFC 2015 MIME Security with Pretty Good Privacy (PGP), 1996
• Draft Standard RFC 2045 MIME (Multipurpose Internet Mail Extensions), 1996
• Informational RFC 2311 S/MIME Version 2 Message Specification, 1998
• RFC 2557 – MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
• Proposed Standard RFC 2633 S/MIME Version 3 Message Specification, 1999
• Proposed Standard RFC 2822 Internet Message Format, 2001

Die wichtigsten zu berücksichtigenden XML-Standards sind (herausgegeben vom WWW-Konsortium, www.w3c.org):

• XML Base
• XML Signature
• XML Encryption
• Xpath
• XML Schema
• XSL und XSLT
• XHTML
• XML Key Management

Problemstellung 1: Legacy Code
Als Fazit können wir festhalten, dass E-Mail-Clients heute folgende, nicht verwandte Datenformate verarbeiten können muss:

• RFC 822 (in der aktuellen Version RFC 2822, nur für E-Mail),
• MIME (nur für E-Mail),
• S/MIME (Cryptographic Message Syntax, ASN.1-basiert, kompatibel zu PKCS#7 und den X.509-PKI-Standards) und
• HTML/XMLkomatibel zum WWW.

Da die ersten beiden Datenformate (RFC 822, MIME) in dieser Form nur bei E-Mails vorkommen, und das dritte denkbar inkompatibel zu den drei anderen ist (und daher völlig eigenständige Implementierungen erfordert), kann es in Zukunft ein Problem mit der Wartung dieses Codes geben.
Als weiterer Aspekt kommt hinzu, dass Firmen in Zukunft verpflichtet sein werden, ihre E-Mail-Geschäftskorrespondenz geeignet zu archivieren, wie dies auch bei schriftlicher Korrespondenz der Fall ist. Durch das oben aufgezeigte Nebeneinander unterschiedlichster Strukturen in einer E-Mail bietet sich hier als einzige Möglichkeit die Speicherung als BLOB (Binary Large OBject) in einer Datenbank an. Dadurch wird die Suche nach bestimmten Kriterien in der gesammelten E-Mail-Korrespondenz sehr aufwendig.
Problemstellung 2: Sicherheit
Vertrauliche Informationen in E-Mails oder deren Anhängen können mitgelesen werden. Dieses Problem ist bekannt und wird im Prinzip durch die Internet-Standards S/MIME und OpenPGP gelöst Dennoch wird heute auch weiterhin nur ein geringer Anteil der Internet-Mails verschlüsselt. Dies hat folgende Gründe:

• Die für die Verarbeitung von S/MIME-Nachrichten verwendeten Algorithmen sind sehr komplex und wenig verbreitet, weil sie auf dem ASN.1-Datenformat basieren, das von allen sonst im Internet verwendeten Datenformaten denkbar weit entfernt ist. Konsequenterweise findet man in Open-Source-Projekten wie Mozilla (Nachfolger des Netscape Messenger) oder Linux fast keine S/MIME-Implementierungen, sondern lediglich OpenPGP.
• In OpenPGP wird den oben genannten vier Datenformaten ein fünftes hinzugefügt. Auch in OpenPGP werden die binären Ergebnisse kryptographischer Operationen auf spezielle Art und Weise codiert. Dabei wird aber das Schlüsselmanagement-Problem nicht sauber gelöst, und der Einsatz scheitert einfach daran, dass man den Schlüssel des Kommunikationspartners nicht kennt.

Beide Ansätze haben eine gemeinsame Schwäche: Sie berücksichtigen die historisch gewachsene Trennung zwischen E-Mail-Header und E-Mail-Body (RFC 822, RFC 2822), und schützen nur letzteren mit kryptographischen Methoden. Dies hat folgende Konsequenzen:

• Absendeadressen (das „FROM:"-Feld im RFC 822-Header) sind kryptographisch nicht gesichert und können ggf. gefälscht werden, ohne dass ein E-Mail-Client dies anzeigt. S/MIME-Clients sollen zwar die Adresse im „FROM:"-Feld mit der Adresse im X.509-Zertifikat vergleichen, es ist jedoch keineswegs sicher, dass alle Clients dies auch tun. Für OpenPGP ist der entsprechende Sachverhalt noch zu klären.
• Empfängeradressen (das „TO:"-Feld von RFC 822) sind nicht kryptographisch geschützt (auch nicht durch eine Soll-Anweisung). Sie können für signierte Mails leicht manipuliert werden. (Für verschlüsselte Mails macht dies keinen Sinn, da sie vom geänderten Empfänger ja nicht gelesen werden können.

Diese Beobachtungen beeinträchtigen zum einen die Sicherheit normaler E-Mails (die vom Mailserver-Administrator signierte Mail „Sie haben Ihr Mailvolumen überschritten" könnte mit verändertem „TO:"-Feld auch an andere Nutzer weitergeleitet werden, und so für Konfusion sorgen), sie setzt aber auch die Wirksamkeit digitaler Signaturen als viel gepriesene Möglichkeit zur Verhinderung von SPAM-Mails außer Kraft:
Bei hinreichend großer Verbreitung digital signierter E-Mails könnte man SPAM-Mails aussortieren, indem man alle nicht signierten Mails in den Papierkorb wirft. Um diesen Filter zu überwinden müsste ein SPAM-Anbieter, so die gängige Argumentation, alle versendeten E-Mails signieren, was ihm einen Kostenfaktor in Form enorm gestiegenen Rechenaufwands aufbürden würde. Dieser auch finanziell bezifferbare Mehraufwand pro E-Mail würde SPAM wirtschaftlich unattraktiv machen.
Dies ist jedoch nicht der Fall, da ein SPAM-Anbieter folgende Alternativen hat:

1. Er besorgt sich für jede Mailingaktion eine neue E-Mail-Adresse (für wenige Cent) und ein kostenloses E-Mail-Zertifikat. Dann signiert er eine Mail, speichert diese ab, schreibt ein kleines Programm, das nur die „TO:"-Zeile austauscht, und versendet die Mails wie gewohnt.
2. Falls der SPAM-Filter auf „NoSPAM"-PKIs (...) beschränkt wurde, kann er eine „gute" Mailadresse zum Signieren einer E-Mail verwenden, und dann auch das „FROM:"-Feld austauschen. Die Erfolgsrate dieses Vorgehens hängt von der Anzahl der E-Mail-Clients ab, die nicht korrekt prüfen, und müsste empirisch ermittelt werden.

Zeitstempel: Ein wichtiger Nachteil von E-Mail gegenüber normaler Post ist der fehlende Nachweis, wann eine Nachricht abgeschickt oder wann sie angekommen ist. Zumindest das ungefähre Absendedatum wird durch ein halbamtliches Siegel, den Poststempel, quittiert. Im Internet gibt es Zeitstempeldienste, die ähnliche Nachweiskraft besitzen, aber es ist unklar, wie sie in eine E-Mail sicher eingebunden werden sollen.
Lösung beider Problemklassen: XMaiL
Man kann nun versuchen, die oben aufgezeigten Probleme durch Erweiterung der bestehenden E-Mail-Standards zu lösen: Einbeziehung des Headers (oder bestimmter Headerfelder) in die Signatur durch Modifikation von S/MIME und OpenPGP, Entwicklung von MIME-Datenbanken, Einführung neuer Headerfelder für Zeitstempel.
Ein solcher Lösungsansatz wirkt aber leicht anachronistisch in einer Zeit, in der alle Softwarefirmen bestrebt sind, ihre Produkte auf einen einzigen Standard hin auszurichten: XML. (Z. B. basieren in Office 2003 von Microsoft die Datenformate von Excel und Word bereits auf XML, andere Office-Produkte sollen folgen.)
Die hier vorgeschlagen Lösung, XMaiL genannt, basiert auf der Idee, alle Datenstrukturen einer E-Mail in XML nachzubilden. Die XML Standardsuite bietet dafür heute alle nötigen Teilstandards.
Dazu müssen die Datenstrukturen, die in den einschlägigen Internetstandards beschrieben sind, in XML-Datenstrukturen übersetzt werden. Dabei treten verschiedene Problem auf, die anhand der jeweiligen Standards gelöst werden müssen, und die hier beispielhaft für die jeweiligen Standards beschrieben werden sollen.
Die genaue Umsetzung der ersten Gruppe von Standards in die zweite Gruppe kann mit Hilfe von XML Schemas erfolgen. Vereinfachte Versionen dieser XML-Schemas werden im Rahmen der Ausführungsbeispiele vorgestellt.
Das Thema Sicherheit nimmt unter den Beispielen einen breiten Raum ein, da gerade hier große Verbesserungen möglich sind, die Umsetzung aber auf große Schwierigkeiten stößt.
Anmerkung zur Terminologie: Im Folgenden werden Teile einer E-Mail immer mit den Bezeichnungen aus den jeweiligen IETF-Standards bezeichnet, z. B. mit „Header" (ohne Anführungszeichen) für den Header einer E-Mail, und mit „TO-Feld" für die Zeile des E-Mail-Quelltextes, die mit „TO:" beginnt. Bestandteile der XML-Datenstruktur, die nach Maßgabe dieser Erfindungsmeldung aus der E-Mail gebildet wird, sind immer XML-Elemente und werden in spitzen Klammern angegeben, die von den XML-Tags bekannt sind, also z. B. <Header> und <TO>.
Ausführungsbeispiel 1: Einfache E-Mail nach RFC 2822
Die Unterteilung einer E-Mail nach RFC 822 (bzw. RFC 2822) in Header und Body kann in XML dadurch nachgebildet werden, dass das Wurzelelement <XMaiL> genau zwei Unterelemente <Header> und <Body> besitzt. Es sind auch andere Aufteilungen möglich, aber die vorgeschlagene Unterteilung macht Sinn, weil in <Header> und <Body> sinnvollerweise völlig verschiedene Unterelemente vorkommen.
Anmerkung: Diese Aussage wird auch nicht durch die Tatsache widerlegt, dass bestimmte MIME-Header bei einer E-Mail sowohl im Header als auch im Body gleichartige MIME-Felder wie „Content-Type: Multipart/Mixed" auftauchen; dies ist lediglich als historisches Relikt zu sehen, das beim Übergang von einem reinen (ASCII-)Textformat zu einem Multimediaformat unvermeidlich war.
Die folgende Tabelle gibt die Umsetzung der Beispielnachricht aus Anhang A.1.1 von RFC 822 wieder. Da eine Leerzeile nach RFC 2822 die beiden Teile Header und Body der E-Mail trennt, wurde in der Tabelle auf eine zeilenweise Zuordnung der Bestandteile verzichtet. (Dies wird aber in den folgenden, komplexeren Beispielen getan.)
Abbildung 1: Übersetzung einer einfachen E-Mail nach RFC 2822 in das XMaiL-Format
Das obige Beispiel ist eine direkte Übertragung der E-Mail-Struktur nach RFC 2822 in eine XML-Struktur. Im Gegensatz zu dem im Stand der Technik beschriebenen Verfahren wird hier aber die Unterteilung in Header und Body beibehalten, da diese konstitutiv für alle (auch die erweiterten) E-Mail-Formate ist. Die einzige Abweichung von diesem Prinzip ist die weitergehende Kapselung des eigentlichen Nachrichtentextes in die XML-Element <Text> und Plain>. Dies wurde im Hinblick auf die Erweiterung auf MIME-formatierte Mails gemacht, da so einfach strukturierte E-Mail wie in diesem Beispiel im heutigen Internet fast nicht mehr versendet werden.
Bei dem angeführten Beispiel ist zu beachten, dass es durchaus noch sinnvolle Varianten bei der Umsetzung gibt. So könnten z. B. die Schachtelung des ASCII-Textes in die XML-Elemente <Text> und <Plain> auch durch ein eiziges XML-Element <TextPlain> ersetzt weden, das dann den Text enthalten würde.
Ein einfaches XML-Schema für dieses Beispiel könnte wie folgt aussehen.
Abbildung 2: XML Schema zur Überprüfung, ob ein XML-Dokument eine gültige Übersetzung einer einfachen RFC 2822 E-Mail ist.
Durch das in 2 wiedergegebene XML-Schema wird auch klar, warum es sinnvoll ist, die Unterteilung in Header und Body beizubehalten:

• Die Unterelemente des <Header>-Elements haben keine vorgegebene Reihenfolge; dies entspricht der Praxis in E-Mails nach RFC 2822.
• In das <Header>-Element können weitere, proprietäre Unterelemente eingefügt werden, in 2 angedeutet durch drei Punkte („..."). Dies entspricht der gängigen Praxis, Informationen über den sendenden E-Mail-Client einzufügen (siehe nächstes Beispiel).
• Einzelne Unterelemente des <Header>-Elements können mehrfach auftreten; auch dies entspricht der Praxis, dass E-Mail-Gateways der E-Mail auf ihrem Weg vom Sender zum Empfänger solche „Received:"-Einträge hinzufügen.
• Im Gegensatz dazu hat der Body einer Nachricht eine klar definierte Struktur, die bei dieser einfachen E-Mail sehr einfach strukturiert ist, durch die Einbindung von MIME-Mechanismen aber sehr flexibel wird.

Ausführungsbeispiel 2: MIME-formatierte E-Mail
Bei der Umsetzung der MIME-Struktur einer E-Mail, die in XML möglicht identisch nachgebildet werden soll, ergeben sich Schwierigkeiten, deren Lösung wie folgt beschrieben werden kann:

• Für jeden möglichen Wert des MIME-Attributs Content-Type werden zwei (bzw. ein) neues XML-Element gleichen oder ähnlichen Namens eingeführt:
– Alternative 1: Die Kombination Type/Subtype des MIME-Attributs wird in zwei XML-Elemente <Typ> und <Subtyp> übersetzt, wobei <Subtyp> ein Unterelement von <Typ> sein muss. (Beispiel: „Content-Type: Multipart/Mixed" wird zu <Multipart><Mixed> ... </Mixed></Multipart>.)
– Alternative 2: Die Kombination Type/Subtype des MIME-Attributs wird in ein XML-Element <TypSubtyp> übersetzt. (Beispiel: „Content-Type: Multipart/Mixed" wird zu <MultipartMixed> ... </MultipartMixed>.)
– Content-Type: multipart/mixed der Tag <MultipartMixed>)
• 1. Gliederungsebene: Das <Body>-Element der XMaiL enthält nur ein direktes Unterelement. Dieses Element entspricht dem MIME „Content-Type" im Header der E-Mail. (Alternativ wäre es auch möglich, dass der MIME-Content-Type des Body der E-Mail als Attribut des <Body>-Tags gespeichert wird, oder dass es kein <Body>-Element gibt, sondern nur ein Element, das dem MIME-Typ des E-Mail-Body entspricht. Weitere Alternativen sind denkbar, ändern den Gesamtansatz aber nicht.)

Anmerkung: Das einige MIME-Attribute wie z. B. „Content-Type" und „Transfer-Encoding" bei MIME-E-Mails sowohl (einmal) im Header als auch (ggf. mehrmals) im Body einer E-Mail auftauchen, hat historische Gründe: Hätte ein solches Attribut im Header gefehlt, so hätte der E-Mail-Client den gesamten Body der Nachricht als reinen Text interpretiert.

• Weitere Gliederungsebenen: Je nach Art des Elements kann dieses ein oder mehrere Nachfolgeelement enthalten. Mehr als ein Nachfolgeelement ist dabei nur bei Elementen vom Typ <Multipart><XXX> (bzw. <MultiprtXXX>) möglich.
• Die genaue Umsetzung muss durch XML Schemata beschrieben werden, die sich so weit wie möglich an den entsprechenden MIME-Standards orientieren. Ein noch unvollständiges Beispiel dazu ist in 4 angegeben.

In der folgenden 3 werden der (gekürzte) Quelltext einer Originalmail (mit geänderten Mailadressen) im MIME-Quelltextformat, und parallel dazu ihre Umsetzung in das XMaiL-Format, wiedergegeben.
Abbildung 3: Eine (relative komplexe) MIME-E-Mail und ihre Umsetzung in das XMaiL-Format.
In 3 wurde die Variante gewählt, Typ und Subtyp eines MIME-Elements in einem XML-Element zusammenzufassen. Das folgende, noch unvollständige XML-Schema gibt dagegen die Variante wieder, Typ und Subtyp in zwei getrennte, aber verschachtelte XML-Elemente zu übersetzen.
Abbildung 4: XML-Schema (unvollständig) für MIME-formatierte E-Mails.
Ausführungbeispiel 3: S/MIME-verschlüsselte E-Mail
Gegeben sei der folgende (gekürzte) Quelltext einer Originalmail im S/MIME-Format, und parallel dazu die Umsetzung in das XMaiL-Format. Die grau hinterlegten Felder im S/MIME-Format sind in ASN.1 codiert und deshalb im ASCII-Quelltext der E-Mail nicht erkennbar (sie sind dort base64-codiert).
Anmerkungen zu Ausführungsbeispiel 3:

• Die Konvertierung der ASN.1/PKCS#7-codierten Darstellung des verschlüsselten Body der Beispiel-E-Mail in das dargestellte Textformat wurde durch ein automatisches Tool generiert. Dieses Tool übersetzt reine Binärdaten ohne weitere ASN.1-Struktur in eine Folge von Hexadezimalzahlen, die durch einen Doppelpunkt getrennt werden.
• In XML ist der Quelltext der Nachricht direkt lesbar, es bedarf keiner Tools. Binärdaten werden hier in base64-Codierung dargestellt. Gleiche oder den gleichen Inhalt darstellende Binärdaten in den beiden Spalten sind daher nicht identisch, sondern müssen anhand der Datenstruktur zugeordnet werden. So enthält z. B. die hexadezimale Zahlenfolge 3A:DB:98:08:1C:2E: ... in der linken Spalte die gleiche Information wie die ASCII-Folge a6mWXDS ... naTB81jvHw= in der rechten Spalte.

Ausführungsbeispiel 4: S/MIME-signierte E-Mail
Gegeben sei der folgende (gekürzte) Quelltext einer Originalmail im „clear-signed" S/MIME-Format, und parallel dazu die Umsetzung in das XMaiL-Format. Das „opaque-signed-Format ist ggf. mit dem Aufkommen von XML überholt. Die grau hinterlegten Felder im S/MIME-Format sind in ASN.1 codiert und deshalb im ASCII-Quelltext der E-Mail nicht erkennbar (sie sind dort base64-codiert).
Anmerkungen zu Ausführungsbeispiel 4:

• Die beiden XML-Elemente, die sich im XMaiL-Beispiel in einem gestrichelten Rahmen befinden, verdeutlichen die neuen Sicherheitsfeatures von XMaiL: Das <To> und das <From>-Element des <Header>-Elements können hier, im Gegensatz zu S/MIME oder OpenPGP, in die Signatur mit einbezogen werden.
• Als neues Feature bietet XMaiL die Möglichkeit, durch eine Spezifikation in XPath anzugeben, welche Elemente signiert werden und welche verschlüsselt werden sollen. Der dazu benötigte XPath-Ausdruck kann ggf. in einem E-Mail-Client interaktiv vom Nutzer festgelegt werden.
• Im Zuge der weiteren Anpassung aller Datenstrukturen an XML bietet es sich auch an, X.509-Zertifikate in XML nachzubilden. Alle nötigen Konstrukte stellt XML bereit.

Ausführungsbeispiel 5: Verhinderung von SPAM-Mails
Das Problem der SPAM-Mails kann mit der vorliegenden Erfindung wie folgt gelöst werden:

• Jeder Hersteller von XMaiL-Clients integriert ein Standard-Client-Zertifikat (und den dazugehörigen privaten Schlüssel) in das Programm, das nichts anderes zertifiziert, als dass bestimmte Teile einer E-Mail digital signiert wurden. Für diese Zwecke reicht ein Zertifikat weltweit aus, oder der Softwarehersteller könnte jedes Build der Software mit einem anderen Zertifikat versehen. Wichtig ist, dass diese Zertifikate mit der Software ausgeliefert werden können, und keine Konfigurationsarbeiten von Seiten des Nutzers erforderlich sind. Installiert der Nutzer später ein eigenes E-Mail-Zertifikat, so wird natürlich dieses anstelle des Standardzertifikats verwendet.
• Jeder XMaiL-Client signiert standardmäßig mit diesem Zertifikat das <From>, das <To> und das <Body>-Element jeder E-Mail. Die Signatur wird als „Enveloped Signature" dem Header-Element hinzugefügt. Alternativ dazu kann sie auch dem Body-Element hinzugefügt werden, das dann allerdings entsprechend modifiziert werden muss; in diesem Fall kann auch nicht das gesamte <Body>-Element signiert werden, sondern nur die Elemente ausschließlich des Signaturelements.
• Ebenfalls standardmäßig ist ein XMaiL-Filter aktiviert, der alle E-Mails ohne Signatur, mit ungültiger Signatur, oder alle E-Mail mit überlangem <To>-Element, in den SPAM-Ordner wegsortiert.
• Dem Spar-Mailer werden so Kosten aufgebürdet, da er für jede Gruppe von Adressaten (ungefähr zwischen 1 und 30 Empfängern, je nach erlaubter Größe des <To>-Elements) eine digitale Signatur erstellen muss. Durch Vergrößern der Schlüssellänge in den Zertifikaten, und durch Verkürzen des <To>-Elements, kann man diesen Kostenfaktor skalieren. Der Spar-Mailer kann auch keine fremden E-Mail-Verteilerlisten mehr benutzen, da hier das <To>-Element verändert und so die Signatur ungültig wird.
• Mit diesem Verfahren kann man auch den E-Mail-Missbrauch innerhalb von Unternehmen Herr werden: Der Mitarbeiter, der eine E-Mail an alle 20.000 anderen Mitarbeiter sendet, muss dann halt für den Rest des Tages auf seinen Computer verzichten.

Eine weitere Methode zur Lösung des SPAM-Problems, die gegenüber der vorher genannten den Vorteil hat, dass sie schnell (d. h. ohne großen Rechenaufwand), und auch in Mailservern überprüft werden kann, lässt sich wie folgt beschreiben:

• Ein wichtiges Element der E-Mail (z. B. das „TO"-Feld oder eine Kombination aus diesem und anderen Feldern wird ausgewählt. Diese Felder müssen die Voraussetzungen erfüllen, dass sie in jeder E-Mail andere Werte annehmen, und dass sie während des Transports nicht verändert werden.
• Über diese Felder wird eine erste (normale) Prüfsumme gebildet, die eine bestimmte Bitlänge, z. B. n-Bit, haben soll.
• Diese Prüfsumme, oder ein anderer geeigneter Wert, wird nun als Teil der Eingabe einer kryptographischen Einwegfunktion, z. B. einer Hashfunktion wie MD5 oder SHA-1, verwendet. Der E-Mail-Client des Senders steht nun vor der Aufgabe, eine Ergänzung zu dieser Prüfsumme zu finden, die zusammen mit der Prüfsumme wieder die Prüfsumme als Ergebnis liefert. Als Formel: f(P, D) = P, wobei f die kryptographische Einwegfunktion darstellt, P die Prüfsumme, und D den ergänzenden Datensatz. Ähnliche Verfahren wurden zur Abwehr von Denial-of-Service-Agriffen als „cryptographic client puzzles) bezeichnet. Im Gegensatz zu diesen Verfahren ist es hier wichtig, ein so genanntes „salt" (in vorliegenden Beispiel die Prüfsumme P, die in die Berechnung des Funktionswertes f(P, D) einfließt) hinzuzunehmen, um kryptographische Angriffe auf Basis des Geburtstagsparadoxons („birthday attacks") zu verhindern.
• Dieses Verfahren kann auch auf E-Mails angewandt werden, die nicht in das XMaiL-Format konvertiert wurden, und mit anderen als den genannten Datensätzen.

Übergangsszenarien
Bei einem so überaus alten, populären und auf hunderte Millionen Client-Rechner verteilten Dienst wie E-Mail stellt sich zwangsläufig die Frage nach Übergangsszenarien: Wie kann ein neues Datenformat eingeführt werden, ohne die Funktionsweise des alten zu beeinträchtigen?
Die natürliche Lösung besteht darin, beide Datenformate so lange wie möglich nebeneinander bestehen zu lassen. Folgender Ablauf wäre denkbar:

1. In der ersten Phase wird XMaiL nur als Archivierungsformat für E-Mails angewendet. Dazu wird ein Konvertierungsprogramm eingesetzt, dass eine Standard-E-Mail nach XMaiL konvertiert. Dieses Konvertierungsprogramm muss auch in umgekehrter Richtung funktionieren, d. h. die ursprüngliche E-Mail muss wieder hergestellt werden können. Die XMaiLs können dann in einer XML-Datenbank bequem archiviert werden.
2. In einer zweiten Phase können Unternehmen dazu übergehen, den internen E-Mail-Verkehr auf XMaiL umzustellen. Die Anbindung an den Internet-Dienst E-Mail bleibt dabei (im Gegensatz zu alten proprietären Lösungen wie Lotus Notes Mail) voll erhalten, da beide Formate ineinander umgewandelt werden können. Unternehmensinterne Sicherheitspolicies können dabei voll umgesetzt werden, z. B. die Regel, dass intern nur signierte XMaiLs in Umlauf sind (die von Virenschutzsoftware gescannt werden können), und eine Verschlüsselung (durch einen XPath-Ausdruck spezifiziert) erst im Konvertierungsgateway beim Übergang ins Internet angewandt wird.
3. Aufgrund des geringen Mehraufwands an Programmcode (die XML-Standards müssen von zukünftigen E-Mail-Clients alle unterstützt werden) werden in der dritten Phase alle gängigen E-Mail-Clients XMaiL-Unterstützung anbieten. Zu diesem Zeitpunkt ist eine Einführung möglich.

Zwei weitere Anmerkungen zum Thema Übergangsszenarien:

1. Das SMTP-Protokoll zum Senden und Empfangen von E-Mails muss nicht notwendigerweise an XMaiL angepasst werden: Ein Client kann die für SMTP benötigten Daten aus dem <Header>-Element der XMaiL extrahieren und an das SMTP-Gateway senden. Dieser RFC 822-Header kann „on the fly" immer dann generiert werden, wenn ein XMaiL-fähiges Gateway auf ein Legacy-Gateway trifft. Beim Übergang von einem Legacy-Gateway zu einem XMaiL-fähigen Gateway muss die neu hinzugekommene Information des RFC822-Header im <Header>-Element ergänzt werden. Die gesamt XMaiL wird von Legacy-Gateways als Body einer RFC822-E-Mail behandelt.
2. Während der Übergangphase stellt das Senden von RFC822-Header plus <Header>-Element im Body eine Lösung für nicht XMaiL-fähige Clients dar; der Client kann wahlweise das eine oder andere verwenden, das <Header>-Element wird dann im Body aber nicht angezeigt (z. B. <Header style="invisible"> o. ä.).

Claims

Verfahren zur Abbildung von Internet-E-Mails in ein reines XML-Format [XMaiL], dadurch gekennzeichnet, dass sämtliche der nachfolgend genannten, in einer E-Mail enthaltenen Datenformate in XML-Datenformate überführt werden können: – RFC 2822, – MIME (gemäß RFC2045–2047 und RFC2049), – S/MIME (gemäß RFC2311 und RFC2633), – CMS/PKCS#7 (gemäß RFC3369), – HTML (Version 4.01), – OpenPGP (gemäß RFC2440); dass die resultierende XML-Struktur [XMaiL] die Struktur der Internet-Mail widerspiegelt, und dass die resultierende Struktur gemäß XML Schema validiert wird, wobei – bei Datenformaten gemäß RFC 2822 die Unterteilung einer Internet-Mail in Header und Body dadurch berücksichtigt wird, dass es in der XML-Struktur genau zwei Nachfolgeelemente <Header> und <Body> des Wurzelelements gibt, die diese Struktur widerspiegeln; – bei Datenformaten gemäß MIME die aus den Multipart-Datentypen des MIME-Standards (RFC2046) festgelegte Struktur in der resultierenden XML-Struktur erhalten bleibt.
Verfahren nach Anspruch 1, wobei die Unterelemente des XML-Elements oder der Kombination von XML-Elementen, die den Typ Multipart/Mixed repräsentieren, in der vorgegebenen Ordnung dargestellt werden.
Verfahren nach Anspruch 1, wobei die Unterelemente des XML-Elements oder der Kombination von XML-Elementen, die den Typ Multipart/Parallel repräsentieren, in beliebiger Ordnung dargestellt werden.
Verfahren nach Anspruch 1, wobei von den Unterelementen des XML-Elements oder der Kombination von XML-Elementen, die den Typ Multipart/Alternative repräsentieren, genau eines dargestellt wird.
Verfahren nach Anspruch 1, wobei das XML-Element oder der Kombination von XML-Elementen, die den Typ Multipart/Signed repräsentieren, genau zwei Nachfolgeelemente hat, von denen eines ein Element vom Typ XML-Signatur ist, das wiederum ein einziges <Reference>-Element enthält, das das andere Nachfolgeelement referenziert.
Verfahren nach den Ansprüchen 1 bis 5, dadurch gekennzeichnet, dass die MIME-Datentypen, die intern nach den Standards CMS aufgebaut sind, so in XML-Elemente, die in den Standards XML-Signatur (RFC3275) und XML-Verschlüsselung (XML Encryption Syntax and Processing, W3C Recommendation, 10 Dezember 2002) definiert sind, überführt werden, dass ihre Struktur erhalten bleibt.
Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die in den Zertifikaten, die nach dem X.509-Standard gebildet und in E-Mails mit Hilfe der Standards S/MIME und CMS/PKCS#7 eingebettet werden, enthaltenen Informationen in Strukturen der XML-Standards XML-Signatur (RFC3275) und XML-Schlüsselmangement (XML Key Management Specification (XKMS) Version 2.0, W3C Working Draft 18 April 2003) eingebettet werden, oder dass die Struktur eines X.509-Zertifikats vollständig in einen XML-Datensatz überführt wird, der Elemente aus dem Standard XML-Signatur (RFC3275) verwendet.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die MIME-Datentypen, die intern nach dem Standard OpenPGP aufgebaut sind, so in XML-Elemente, die in den Standards XML-Signatur und XML-Verschlüsselung definiert sind, überführt werden, dass ihre Struktur erhalten bleibt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass beliebige XML-Elemente der XML-Struktur [XMaiL] mit Hilfe von Konstrukten aus dem Bereich der Standards XML-Signatur (RFC3275) und XML-Verschlüsselung (XML Encryption Syntax and Processing, W3C Recommendation, 10 Dezember 2002) abgesichert werden.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein <FROM>-Element und ein <TO>-Element eines <Header>-Elements in die Signatur mit einbezogen werden.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass in der XML-Struktur [XMaiL] die Elemente <FROM> und <TO> und mindestens noch ein weiteres Unterelement aus dem <Body>-Element oder dieses selbst signiert ist.
Verfahren nach einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass zum Signieren nicht ein individueller privater Schlüssel verwendet wird, sondern ein Schlüssel, der zusammen mit dem jeweiligen E-Mail-Client ausgeliefert wird und von der Herstellerfirma des E-Mail-Clients als authentisch gekennzeichnet wird.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein vorhandener Zeitstempel als XML-Element eingebunden wird und mit in die Signatur einfließt.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein neues Element in die XML-Struktur [XMaiL] mit aufgenommen wird, die ein Urbild eines Elements aus der XML-Struktur [XMaiL] unter einer kryptographischen Einwegfunktion erhält.
Verfahren nach den Ansprüchen 1 bis 8, dadurch gekennzeichnet, dass der Quelltext einer gegebenen E-Mail nach RFC 2822 in eine XML-Struktur [XMaiL] umgewandelt und das Ergebnis ausgegeben wird.
Verfahren nach den Ansprüchen 1 bis 8, dadurch gekennzeichnet, dass eine gegebenen XML-Struktur [XMaiL] in den Quelltext einer E-Mail nach RFC 2822 umgewandelt und das Ergebnis ausgegeben wird.
Verfahren nach den Ansprüchen 15 und 16, dadurch gekennzeichnet, dass die Hintereinanderausführung der beiden entgegengesetzten Umwandlungsschritte wieder das Ausgangsobjekt liefert.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass das ausgegebene Ergebnis in einer XML-Datenbank gespeichert wird.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Eingabe aus einer XML-Datenbank stammt.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Eingabe aus dem Internet oder einem anderen Netzwerk, in dem RFC 2822-basierte E-Mails versendet werden, stammt, und das Ergebnis in ein Netzwerk weitergeleitet wird, in dem XML-Strukturen [XMaiL] verwendet werden.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Eingabe aus einem Netzwerk stammt, in dem XML-Strukturen [XMaiL] verwendet werden, und das Ergebnis in das Internet oder ein anderes Netzwerk, in dem RFC 2822-basierte E-Mails versendet werden, weitergeleitet wird.
Verfahren nach den Ansprüchen 15, 16 und 18 bis 21, dadurch gekennzeichnet, dass bei der Umwandlung Sicherheitsmerkmale nach den Ansprüchen 9 bis 14 hinzugefügt oder entfernt werden.
Verfahren nach den Ansprüchen 15 bis 21, dadurch gekennzeichnet, dass zur Kommunikation nach dem SMTP-Protokoll (RFC2821) benötigte Informationen aus dem <Header>-Element extrahiert werden und während der Kommunikation im SMTP-Protokoll hinzugekommene Informationen im <Header>-Element eingefügt werden.
Verfahren nach den Ansprüchen 1 bis 13, dadurch gekennzeichnet, dass sowohl E-Mails nach den RFCs 2045–2049, 2311, 2312, 2557, 2630, 2632, 2633 und 2822 als auch XML-Strukturen [XMaiL] verarbeitet und dargestellt werden können.
Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass dem <Header>-Element ein Attribut hinzugefügt wird, mit dem seine Darstellung auf Endgeräten, die nur E-Mails nach den RECs 2045–2049, 2311, 2312, 2557, 2630, 2632, 2633 und 2822 darstellen können, nicht angezeigt wird.
Endgerät zur Umsetzung der Verfahren nach den Ansprüchen 15 bis 25.