3.7 Computing the Message Hashes (Berechnung der Nachricht-Hashes)

3.7. Computing the Message Hashes (Berechnung der Nachricht-Hashes)

Sowohl das Signieren als auch das Verifizieren von Nachrichtensignaturen beginnen mit einem Schritt zur Berechnung zweier kryptografischer Hashes über die Nachricht. Signer wählen die Parameter der Signatur wie in "Signer Actions" (Abschnitt 5) beschrieben; Verifizierer verwenden die im zu verifizierenden DKIM-Signature-Headerfeld angegebenen Parameter. In der folgenden Diskussion werden die Namen der Tags im DKIM-Signature-Headerfeld verwendet, das existiert (beim Verifizieren) oder erstellt wird (beim Signieren). Beachten Sie, dass die Kanonisierung (Abschnitt 3.4) nur verwendet wird, um die E-Mail zum Signieren oder Verifizieren vorzubereiten; sie beeinflusst die übertragene E-Mail in keiner Weise.

Der Signer/Verifizierer MUSS zwei Hashes berechnen: einen über den Body der Nachricht und einen über die ausgewählten Headerfelder der Nachricht.

Signer MÜSSEN sie in der angezeigten Reihenfolge berechnen. Verifizierer KÖNNEN sie in jeder für den Verifizierer bequemen Reihenfolge berechnen, vorausgesetzt, das Ergebnis ist semantisch identisch mit der Semantik, die der Fall wäre, wenn sie in dieser Reihenfolge berechnet worden wären.

Im Hash-Schritt 1 MUSS der Signer/Verifizierer den Nachrichtenbody hashen, kanonisiert mit dem im "c="-Tag angegebenen Body-Kanonisierungsalgorithmus und dann auf die im "l="-Tag angegebene Länge gekürzt. Dieser Hash-Wert wird dann in base64-Form konvertiert und in (Signer) oder verglichen mit (Verifizierer) dem "bh="-Tag des DKIM-Signature-Headerfeldes eingefügt.

Im Hash-Schritt 2 MUSS der Signer/Verifizierer das Folgende in der angegebenen Reihenfolge an den Hash-Algorithmus übergeben.

1. Die durch das "h="-Tag angegebenen Headerfelder, in der in diesem Tag angegebenen Reihenfolge, und kanonisiert mit dem im "c="-Tag angegebenen Header-Kanonisierungsalgorithmus. Jedes Headerfeld MUSS mit einem einzelnen CRLF abgeschlossen werden.

2. Das DKIM-Signature-Headerfeld, das existiert (Verifizierung) oder in die Nachricht eingefügt wird (Signierung), wobei der Wert des "b="-Tags (einschließlich aller umgebenden Leerzeichen) gelöscht wird (d. h. als leere Zeichenfolge behandelt), kanonisiert mit dem im "c="-Tag angegebenen Header-Kanonisierungsalgorithmus und ohne abschließendes CRLF.

Alle Tags und ihre Werte im DKIM-Signature-Headerfeld sind im kryptografischen Hash enthalten, mit der einzigen Ausnahme des Wertteils des "b=" (Signatur)-Tags, der als Null-String behandelt werden MUSS. Alle Tags MÜSSEN einbezogen werden, auch wenn sie vom Verifizierer möglicherweise nicht verstanden werden. Das Headerfeld MUSS dem Hash-Algorithmus nach dem Body der Nachricht anstatt mit den restlichen Headerfeldern präsentiert werden und MUSS wie im "c=" (Kanonisierung)-Tag angegeben kanonisiert werden. Das DKIM-Signature-Headerfeld DARF NICHT in seinem eigenen "h="-Tag enthalten sein, obwohl andere DKIM-Signature-Headerfelder signiert werden KÖNNEN (siehe Abschnitt 4).

Beim Berechnen des Hashs für Nachrichten, die mit base64- oder quoted-printable-Kodierung übertragen werden, MÜSSEN Signer den Hash nach der Kodierung berechnen. Ebenso MUSS der Verifizierer die Werte in den Hash einbeziehen, bevor er den base64- oder quoted-printable-Text dekodiert. Der Hash MUSS jedoch vor Transport-Level-Kodierungen wie SMTP "dot-stuffing" (die Modifikation von Zeilen, die mit einem "." beginnen, um Verwechslungen mit dem SMTP-End-of-Message-Marker zu vermeiden, wie in [RFC5321] angegeben) berechnet werden.

Mit Ausnahme des in Abschnitt 3.4 beschriebenen Kanonisierungsverfahrens behandelt der DKIM-Signierungsprozess den Body von Nachrichten einfach als Zeichenfolge von Oktetten. DKIM-Nachrichten KÖNNEN entweder im Klartext oder im MIME-Format vorliegen; MIME-Inhalten wird keine besondere Behandlung gewährt. Nachrichtenanhänge im MIME-Format MÜSSEN im zu signierenden Inhalt enthalten sein.

Formaler ausgedrückt, Pseudocode für den Signaturalgorithmus ist:

body-hash    =  hash-alg (canon-body, l-param)
data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
signature    =  sig-alg (d-domain, selector, data-hash)

wobei:

• body-hash: die Ausgabe des Hashens des Bodys unter Verwendung von hash-alg ist.
• hash-alg: der im "a"-Parameter angegebene Hash-Algorithmus ist.
• canon-body: eine kanonisierte Darstellung des Bodys ist, erzeugt mit dem im "c"-Parameter angegebenen Body-Algorithmus, wie in Abschnitt 3.4 definiert und unter Ausschluss des DKIM-Signature-Feldes.
• l-param: der Length-of-Body-Wert des "l"-Parameters ist.
• data-hash: die Ausgabe der Verwendung des hash-alg-Algorithmus zum Hashen des Headers einschließlich des DKIM-Signature-Headers und des Body-Hashs ist.
• h-headers: die Liste der zu signierenden Header ist, wie im "h"-Parameter angegeben.
• D-SIG: das kanonisierte DKIM-Signature-Feld selbst ohne den Signaturwertteil des Parameters ist, d. h. ein leerer Parameterwert.
• signature: der vom Signaturalgorithmus erzeugte Signaturwert ist.
• sig-alg: der durch den "a"-Parameter angegebene Signaturalgorithmus ist.
• d-domain: der im "d"-Parameter angegebene Domänenname ist.
• selector: der im "s"-Parameter angegebene Selector-Wert ist.

HINWEIS: Viele digitale Signatur-APIs bieten sowohl das Hashen als auch die Anwendung des privaten RSA-Schlüssels unter Verwendung einer einzelnen "sign()"-Primitive. Bei Verwendung einer solchen API würden die letzten beiden Schritte des Algorithmus wahrscheinlich zu einem einzigen Aufruf kombiniert, der sowohl den "a-hash-alg" als auch den "sig-alg" ausführen würde.