3. Protocol Elements (Protokollelemente)

Der DKIM-Betrieb umfasst zwei Rollen: den Signer (Unterzeichner) und den Verifier (Verifizierer). Der Signer erstellt das DKIM-Signature-Headerfeld für die Nachricht, wenn sie die ADMD verlässt, und der Verifier überprüft es, wenn die Nachricht ankommt. Signer und Verifier können ein MTA, MSA oder MUA sein, sind aber eher ein von einem dieser aufgerufenes Modul.

3.1. Selectors (Selektoren)

Um mehrere gleichzeitige öffentliche Schlüssel unter einer einzelnen SDID zu unterstützen und die Bequemlichkeit der Schlüsselverwaltung zu verbessern, verwendet DKIM einen "Selector"-Mechanismus. Genau wie Labels in DNS-Domainnamen verwendet werden, wird der Selector in die Abfragezeichenfolge eingefügt.

Angenommen, der Administrator von example.com installiert zwei parallele DKIM-Systeme. Sie könnten sich entscheiden, "marketing.example.com" und "engineering.example.com" als Domainnamen für die beiden Systeme zu verwenden. Ein solches Schema hat jedoch ein ernstes betriebliches Problem: Es erfordert die Einrichtung und Aufrechterhaltung einer technischen Assoziation zwischen den Domainnamen der beiden Systeme und den unter ihren Namen verwendeten Domains. Im Gegensatz dazu ist ein einfacheres Schema, einen einzigen Domainnamen "example.com" als Quelle der beanspruchten Identität zu verwenden und die öffentlichen Schlüssel der beiden Systeme zu unterscheiden.

Zu diesem Zweck wurde der Selector-Mechanismus eingeführt. Die einfachste Verwendung besteht darin, verschiedene Schlüsseldatensätze zu haben, von denen jeder einen anderen Selector verwendet. Anstatt zwei verschiedene Domainnamen zu haben, verwenden Sie zwei verschiedene Selektoren "nyc" und "sf", um Abteilungen zu unterscheiden. In diesem Fall würden die beiden Schlüsseldatensätze in "nyc._domainkey.example.com" bzw. "sf._domainkey.example.com" referenziert.

Mehrere Selektoren ermöglichen es einer einzelnen Domain, mehrere DKIM-Schlüssel zu halten und somit mehrere gleichzeitige Schlüsselpaare zu realisieren. Der Verifier kümmert sich nicht darum, wie viele Selektoren eine bestimmte Domain verwendet; die DKIM-Architektur stellt sicher, dass die Schlüsselidentifikation eindeutig ist. Beispiele dafür, wie Benutzer mehrere Selektoren verwenden können, sind: separate MSA- und MTA-Schlüssel pflegen, benutzerspezifische Schlüssel, Schlüssel vor und nach dem Upgrade (Schlüsselüberlappung) und Unterstützung für Drittanbietersignaturen. In allen Fällen ist der Selector eine zufällige Zeichenfolge, die nichts mit dem Betrieb zu tun hat und daher nicht abgeleitet werden kann. Schlüsseldatensätze können menschenlesbare Kommentare (n=-Tag) für Schlüsselverwaltungszwecke bereitstellen.

3.2. Tag=Value Lists (Tag=Wert-Listen)

DKIM verwendet eine einfache "Tag=Wert"-Syntax, um verschiedene Strukturen auszudrücken, um Signaturen und Schlüsseldatensätze bereitzustellen. Jede Tag-Spec besteht aus einem Tag-Namen, gefolgt von "=" und einem Wert. Mehrere Tag-Specs werden durch Semikolons getrennt. Die Syntax von Tag-Namen und Werten folgt der ABNF von [RFC2822], wobei die spezifische Syntax in späteren Abschnitten definiert wird.

tag-list  =  tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
              ; Verbietet WSP und FWS am Anfang und Ende
tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
              ; EXCLAMATION bis TILDE außer SEMICOLON
ALNUMPUNC =  ALPHA / DIGIT / "_"

3.3. Signing and Verification Algorithms (Signatur- und Verifizierungsalgorithmen)

DKIM unterstützt mehrere digitale Signaturalgorithmen. Zwei Klassen von Algorithmen werden unterstützt: (1) erforderliche Algorithmen, die unterstützt werden müssen, um Interoperabilität zu gewährleisten; (2) optionale Algorithmen, die es ermöglichen, bei Bedarf neue Algorithmen zu implementieren.

Der Signer wählt den zu verwendenden Algorithmus aus. Der Verifier muss in der Lage sein, Signaturen zu verifizieren, die einen beliebigen erforderlichen Algorithmus verwenden.

Der Signaturalgorithmus ist im "a="-Tag des DKIM-Signature-Headerfeldes definiert, mit folgender Syntax:

sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k     = "rsa" / x-sig-a-tag-k
sig-a-tag-h     = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)
                  ; für zukünftige Erweiterung
x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)
                  ; für zukünftige Erweiterung

"rsa-sha1" und "rsa-sha256" müssen unterstützt und implementiert werden. Die Spezifikationen anderer Algorithmen bleiben späteren Definitionen vorbehalten.

3.4. Canonicalization (Kanonisierung)

Einige Internet-Mail-Transfersysteme ändern Nachrichten, z. B. durch Neuformatierung von Kopfzeilen oder Hinzufügen/Entfernen von führenden oder nachfolgenden Leerzeichen. Solche Änderungen können dazu führen, dass die Signaturverifizierung fehlschlägt.

Um dieses Problem zu lösen, definiert DKIM zwei Kanonisierungsalgorithmen zur Normalisierung von Nachrichten: "simple" und "relaxed". "simple" erlaubt wenige oder keine Änderungen; "relaxed" erlaubt gängige Änderungen wie die Neuformatierung von Leerzeichen. Der Signer kann wählen, welchen Algorithmus er verwenden möchte. Die beiden Algorithmen werden jeweils auf Header und Body angewendet.

Der Kanonisierungsalgorithmus wird im "c="-Tag des DKIM-Signature-Headerfeldes angegeben, mit folgender Syntax:

sig-c-tag       = "simple" / "relaxed" /
                  (sig-c-tag-h "/" sig-c-tag-b)
sig-c-tag-h     = "simple" / "relaxed" / x-sig-c-tag
sig-c-tag-b     = "simple" / "relaxed" / x-sig-c-tag
x-sig-c-tag     = hyphenated-word  ; für zukünftige Erweiterung

3.4.1. Einfacher Header-Kanonisierungsalgorithmus

Der "simple" Header-Kanonisierungsalgorithmus ändert Headerfelder nicht in einer Weise, die die Verifizierung beeinflussen würde.

3.4.2. Relaxed Header-Kanonisierungsalgorithmus

Der "relaxed" Header-Kanonisierungsalgorithmus muss die folgenden Schritte in der angegebenen Reihenfolge anwenden:

Konvertieren Sie alle Headerfeldnamen (einschließlich vor dem Doppelpunkt) in Kleinbuchstaben. Zum Beispiel "SUBJect: AbC" in "subject: AbC" konvertieren.
Entfernen Sie alle WSP-Zeichen nach dem Doppelpunkt.
Konvertieren Sie alle aufeinanderfolgenden WSP-Zeichensequenzen in ein einzelnes SP-Zeichen. WSP-Zeichen sind die SP- und HTAB-Zeichen, wie in Anhang B.1 von [RFC5234] definiert.
Entfernen Sie alle WSP am Ende des Feldwerts.
Entfernen Sie alle abschließenden CRLF-Sequenzen am Zeilenende, ohne dass ein Anhängen an die Body-Grenze erforderlich ist.

3.4.3. Einfacher Body-Kanonisierungsalgorithmus

Der "simple" Body-Kanonisierungsalgorithmus:

Ignoriert alle Leerzeilen am Ende des Nachrichtenbodys. Eine Leerzeile ist als Zeile definiert, die nur CRLF enthält; andere WSP-Zeichen können nicht allein in einer Zeile erscheinen. Wenn der Body vollständig leer ist, wird eine kanonisierte Version eines einzelnen CRLF verwendet, bei der die abschließenden Leerzeilen entfernt wurden.

3.4.4. Relaxed Body-Kanonisierungsalgorithmus

Der "relaxed" Body-Kanonisierungsalgorithmus muss die folgenden Schritte anwenden:

Reduzieren Sie alle aufeinanderfolgenden WSP-Zeichensequenzen (einschließlich nach CRLF) auf ein einzelnes SP.
Ignorieren Sie alle Zeilen, in denen WSP-Zeichen am Zeilenende im Nachrichtenbody erscheinen. Implementierungen dürfen CRLF nach dem letzten Nicht-WSP-Zeichen nicht entfernen.
Ignorieren Sie alle Leerzeilen am Ende des Nachrichtenbodys.

3.4.5. Canonicalization Examples (Kanonisierungsbeispiele)

Die folgenden Beispiele zeigen die Kanonisierung von Header und Body. Hier steht "<SP>" für ein Leerzeichen, "<HTAB>" für einen horizontalen Tabulator und "<CRLF>" für ein Carriage-Return/Line-Feed-Paar.

Originalnachricht:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>
\<CRLF\>
\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Nachricht nach einfacher Kanonisierung:

Header:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>

Body:

\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Nachricht nach relaxed Kanonisierung:

Header:

a:\<SP\>X\<CRLF\>
b:\<SP\>Y\<SP\>Z\<CRLF\>

Body:

\<SP\>C\<CRLF\>
D\<CRLF\>