5. Signer Actions (Signer-Aktionen)

Die folgenden Schritte werden von Signern in der Reihenfolge ausgeführt.

5.1. Determine Whether the Email Should Be Signed and by Whom (Bestimmen, ob die E-Mail signiert werden soll und von wem)

Ein Signer kann offensichtlich nur E-Mails für Domains signieren, für die er einen privaten Schlüssel und die erforderlichen Kenntnisse über den entsprechenden öffentlichen Schlüssel und Selektor-Informationen besitzt. Es gibt jedoch eine Reihe anderer Gründe über das Fehlen eines privaten Schlüssels hinaus, warum ein Signer sich entscheiden könnte, eine E-Mail nicht zu signieren.

INFORMATIVE ANMERKUNG: Ein Signer kann als Teil eines beliebigen Teils des E-Mail-Systems implementiert werden, wie es für angemessen erachtet wird, einschließlich eines MUA, eines SUBMISSION-Servers oder eines MTA. Wo auch immer implementiert, sollten Signer davor warnen, Nachrichten zu signieren (und damit Verantwortung dafür zu übernehmen), die problematisch sein könnten. Insbesondere könnte innerhalb einer vertrauenswürdigen Enklave die signierende Domain gemäß lokaler Richtlinien vom Header abgeleitet werden; SUBMISSION-Server könnten nur Nachrichten von Benutzern signieren, die ordnungsgemäß authentifiziert und autorisiert sind.

INFORMATIVER IMPLEMENTIERUNGSRAT: SUBMISSION-Server sollten Received-Headerfelder nicht signieren, wenn das ausgehende Gateway-MTA Received-Headerfelder verschleiert, zum Beispiel um die Details der internen Topologie zu verbergen.

Wenn eine E-Mail aus irgendeinem Grund nicht signiert werden kann, ist es eine lokale Richtlinienentscheidung, was mit dieser E-Mail zu tun ist.

5.2. Select a Private Key and Corresponding Selector Information (Privaten Schlüssel und entsprechende Selektor-Informationen auswählen)

Diese Spezifikation definiert nicht die Grundlage, auf der ein Signer wählen sollte, welchen privaten Schlüssel und welche Selektor-Informationen verwendet werden sollen. Derzeit sind alle Selektoren gleich, soweit es diese Spezifikation betrifft, daher sollte die Entscheidung weitgehend eine Frage der administrativen Bequemlichkeit sein. Die Verteilung und Verwaltung privater Schlüssel liegt ebenfalls außerhalb des Umfangs dieses Dokuments.

INFORMATIVER BETRIEBSRAT: Ein Signer sollte nicht mit einem privaten Schlüssel signieren, wenn der Selektor, der den entsprechenden öffentlichen Schlüssel enthält, voraussichtlich widerrufen oder entfernt wird, bevor der Verifier Gelegenheit hat, die Signatur zu validieren. Der Signer sollte erwarten, dass Verifier wählen können, die Validierung aufzuschieben, möglicherweise bis die Nachricht tatsächlich vom endgültigen Empfänger gelesen wird. Insbesondere beim Wechsel zu einem neuen Schlüsselpaar sollte das Signieren sofort mit dem neuen privaten Schlüssel beginnen, und der alte öffentliche Schlüssel sollte für ein angemessenes Validierungsintervall aufbewahrt werden, bevor er vom Schlüsselserver entfernt wird.

5.3. Normalize the Message to Prevent Transport Conversions (Nachricht normalisieren, um Transportkonvertierungen zu verhindern)

Einige Nachrichten, insbesondere solche mit 8-Bit-Zeichen, unterliegen während des Transports Änderungen, insbesondere der Konvertierung in 7-Bit-Form. Solche Konvertierungen brechen DKIM-Signaturen. Um die Wahrscheinlichkeit eines solchen Bruchs zu minimieren, SOLLTEN Signer die Nachricht vor dem Signieren in eine geeignete MIME-Content-Transfer-Codierung wie Quoted-Printable oder Base64 konvertieren, wie in [RFC2045] beschrieben. Eine solche Konvertierung liegt außerhalb des Umfangs von DKIM; die tatsächliche Nachricht SOLLTE von einem MUA oder MSA in 7-Bit-MIME konvertiert werden, bevor sie dem DKIM-Algorithmus präsentiert wird.

Wenn die Nachricht dem Signer mit einer lokalen Codierung übermittelt wird, die vor der Übertragung geändert wird, MUSS diese Änderung in die kanonische [RFC5322]-Form vor dem Signieren erfolgen. Insbesondere MÜSSEN nackte CR- oder LF-Zeichen (von einigen Systemen als lokale Zeilentrennkonvention verwendet) vor dem Signieren der Nachricht in die SMTP-Standard-CRLF-Sequenz konvertiert werden. Jede Konvertierung dieser Art SOLLTE auf die Nachricht angewendet werden, die tatsächlich an die Empfänger gesendet wird, nicht nur auf die Version, die dem Signaturalgorithmus präsentiert wird.

Allgemeiner MUSS der Signer die Nachricht so signieren, wie sie vom Verifier erwartet wird, und nicht in einer lokalen oder internen Form.

5.3.1. Body Length Limits (Körperlängenbegrenzungen)

Eine Körperlängenzählung KANN angegeben werden, um die Signaturberechnung auf ein Anfangspräfix des Körpertextes zu beschränken, gemessen in Oktetten. Wenn die Körperlängenzählung nicht angegeben ist, wird der gesamte Nachrichtenkörper signiert.

INFORMATIVE BEGRÜNDUNG: Diese Fähigkeit wird bereitgestellt, weil es sehr üblich ist, dass Mailinglisten Trailer zu Nachrichten hinzufügen (z. B. Anweisungen, wie man von der Liste abkommt). Bis diese Nachrichten auch signiert werden, ist die Körperlängenzählung ein nützliches Werkzeug für den Verifier, da er als Richtlinienangelegenheit Nachrichten mit gültigen Signaturen mit überflüssigen Daten akzeptieren kann.

Die tatsächlich gehashte Länge sollte in das "l="-Tag des DKIM-Signature-Headerfeldes eingefügt werden. (Siehe Abschnitt 3.5.)

Die Körperlängenzählung ermöglicht es dem Signer einer Nachricht, Daten am Ende des Körpers einer signierten Nachricht anzuhängen. Die Körperlängenzählung MUSS nach dem Kanonisierungsalgorithmus berechnet werden; zum Beispiel wird jeder Leerraum, der von einem Kanonisierungsalgorithmus ignoriert wird, nicht als Teil der Körperlängenzählung einbezogen.

Eine Körperlängenzählung von Null bedeutet, dass der Körper vollständig unsigniert ist.

Signer, die sicherstellen möchten, dass keine Änderung jeglicher Art auftreten kann, sollten den "einfachen" Kanonisierungsalgorithmus sowohl für Header als auch für Körper angeben und die Körperlängenzählung weglassen.

Siehe Abschnitt 8.2 für weitere Diskussionen.

5.4. Determine the Header Fields to Sign (Zu signierende Headerfelder bestimmen)

Das From-Headerfeld MUSS signiert werden (das heißt, im "h="-Tag des resultierenden DKIM-Signature-Headerfeldes enthalten sein). Signer SOLLTEN NICHT ein bestehendes Headerfeld signieren, das während des Transports wahrscheinlich legitim geändert oder entfernt wird. Insbesondere erlaubt [RFC5321] ausdrücklich die Änderung oder Entfernung des Return-Path-Headerfeldes während des Transports. Signer KÖNNEN nach eigenem Ermessen andere Headerfelder einschließen, die zum Zeitpunkt des Signierens vorhanden sind.

INFORMATIVE BETRIEBSANMERKUNG: Die Wahl, welche Headerfelder zu signieren sind, ist nicht offensichtlich. Eine Strategie besteht darin, alle vorhandenen, nicht wiederholbaren Headerfelder zu signieren. Eine alternative Strategie besteht darin, nur Headerfelder zu signieren, die wahrscheinlich angezeigt werden oder anderweitig die Verarbeitung der Nachricht beim Empfänger beeinflussen. Eine dritte Strategie besteht darin, nur "bekannte" Header zu signieren. Beachten Sie, dass Verifier unsignierte Headerfelder mit extremer Skepsis behandeln können, einschließlich der Weigerung, sie dem Endbenutzer anzuzeigen oder sogar die Signatur zu ignorieren, wenn sie bestimmte Headerfelder nicht abdeckt. Aus diesem Grund wird dringend empfohlen, in der Nachricht vorhandene Felder wie Date, Subject, Reply-To, Sender und alle MIME-Headerfelder zu signieren.

Das DKIM-Signature-Headerfeld ist immer implizit signiert und DARF NICHT im "h="-Tag enthalten sein, außer um anzuzeigen, dass auch andere bereits vorhandene Signaturen signiert sind.

Signer KÖNNEN behaupten, Headerfelder signiert zu haben, die nicht existieren (das heißt, Signer KÖNNEN den Headerfeldnamen im "h="-Tag einschließen, auch wenn dieses Headerfeld in der Nachricht nicht existiert). Beim Berechnen der Signatur MUSS das nicht existierende Headerfeld als Null-String behandelt werden (einschließlich des Headerfeldnamens, des Headerfeldwerts, aller Satzzeichen und des abschließenden CRLF).

INFORMATIVE BEGRÜNDUNG: Dies ermöglicht es Signern, das Fehlen eines Headerfeldes explizit zu behaupten; wenn dieses Headerfeld später hinzugefügt wird, schlägt die Signatur fehl.

INFORMATIVE ANMERKUNG: Ein Headerfeldname muss nur einmal mehr als die tatsächliche Anzahl dieses Headerfeldes in einer Nachricht zum Zeitpunkt des Signierens aufgeführt werden, um weitere Ergänzungen zu verhindern. Wenn es beispielsweise zum Zeitpunkt des Signierens ein einzelnes Comments-Headerfeld gibt, reicht es aus, Comments zweimal im "h="-Tag aufzuführen, um das Anhängen einer beliebigen Anzahl von Comments-Headerfeldern zu verhindern; es ist nicht notwendig (aber legal), Comments dreimal oder öfter im "h="-Tag aufzuführen.

Siehe Abschnitt 5.4.2 für eine Diskussion des Verfahrens, das beim Kanonisieren eines Headers mit mehr als einer Instanz eines bestimmten Headerfeldnamens zu befolgen ist.

Signer müssen vorsichtig sein beim Signieren von Headerfeldern, bei denen später im Zustellungsprozess zusätzliche Instanzen hinzugefügt werden könnten, da solche Headerfelder nach der signierten Instanz eingefügt oder anderweitig neu geordnet werden könnten. Trace-Headerfelder (wie Received) und Resent-*-Blöcke sind die einzigen Felder, die von [RFC5322] nicht neu geordnet werden dürfen. Insbesondere da DKIM-Signature-Headerfelder von einigen zwischengeschalteten MTAs neu geordnet werden können, ist das Signieren vorhandener DKIM-Signature-Headerfelder fehleranfällig.

INFORMATIVE ERMAHNUNG: Trotz der Tatsache, dass [RFC5322] die Neuordnung von Headerfeldern nicht verbietet, wird die Neuordnung von signierten Headerfeldern mit mehreren Instanzen durch zwischengeschaltete MTAs DKIM-Signaturen brechen; solches antisoziales Verhalten sollte vermieden werden.

INFORMATIVE IMPLEMENTIERUNGSANMERKUNG: Obwohl von dieser Spezifikation nicht gefordert, sollten alle für den Endbenutzer sichtbaren Headerfelder signiert werden, um mögliches "indirektes Spamming" zu vermeiden. Wenn beispielsweise das Subject-Headerfeld nicht signiert ist, kann ein Spammer eine zuvor signierte E-Mail erneut senden und den legitimen Betreff durch eine einzeilige Spam-Nachricht ersetzen.

5.4.1. Recommended Signature Content (Empfohlener Signaturinhalt)

Der Zweck des DKIM-Kryptografiealgorithmus besteht darin, einen Identifikator an die Nachricht anzuhängen, der sowohl robust gegen normale transitbezogene Änderungen als auch widerstandsfähig gegen Arten von Replay-Angriffen ist. Ein wesentlicher Aspekt der Erfüllung dieser Anforderungen ist die Auswahl, welche Headerfelder in den Hash aufgenommen und welche Felder ausgeschlossen werden sollen.

Die Grundregel für die Auswahl von aufzunehmenden Feldern besteht darin, diejenigen Felder auszuwählen, die den "Kern" des Nachrichteninhalts darstellen. Daher muss jeder Replay-Angriff diese einschließen, damit die Signatur erfolgreich ist; mit diesen eingeschlossen ist der Kern der Nachricht jedoch gültig, auch wenn sie an neue Empfänger weitergeleitet wird.

Häufige Beispiele für Felder mit Adressen und Felder mit textuellem Inhalt in Bezug auf den Körper sind:

From (ERFORDERLICH; siehe Abschnitt 5.4)
Reply-To
Subject
Date
To, Cc
Resent-Date, Resent-From, Resent-To, Resent-Cc
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

Wenn das "l="-Signatur-Tag verwendet wird (siehe Abschnitt 3.5), ist das Content-Type-Feld ebenfalls ein Kandidat für die Aufnahme, da es auf eine Weise ersetzt werden könnte, die dazu führt, dass dem empfangenden Benutzer völlig anderer Inhalt gerendert wird.

Bei der Entscheidung, was den "Kern" der Nachricht ausmacht, gibt es Kompromisse, was für einige Felder ein subjektives Konzept ist. Das Einbeziehen von Feldern wie "Message-ID" ist beispielsweise nützlich, wenn man einen Mechanismus zur Unterscheidung separater Instanzen derselben Nachricht als Kerninhalt betrachtet. Ebenso könnte es wünschenswert sein, "In-Reply-To" und "References" einzuschließen, wenn man das Nachrichten-Threading als Kernteil der Nachricht betrachtet.

Eine andere Klasse von Feldern, die von Interesse sein können, sind diejenigen, die sicherheitsbezogene Informationen über die Nachricht übermitteln, wie Authentication-Results [RFC5451].

Die Grundregel für die Auswahl auszuschließender Felder besteht darin, diejenigen Felder auszuwählen, für die es mehrere Felder mit demselben Namen gibt, und Felder, die während des Transports geändert werden. Beispiele hierfür sind:

Return-Path
Received
Comments, Keywords

Beachten Sie, dass das DKIM-Signature-Feld auch vom Header-Hash ausgeschlossen ist, da seine Behandlung separat spezifiziert ist.

Typischerweise ist es besser, andere optionale Felder auszuschließen, da die Möglichkeit besteht, dass zusätzliche Felder mit demselben Namen vor der Verifizierung legitim hinzugefügt oder neu geordnet werden. Es gibt wahrscheinlich legitime Ausnahmen von dieser Regel aufgrund der großen Vielfalt anwendungsspezifischer Headerfelder, die auf eine Nachricht angewendet werden könnten, von denen einige unwahrscheinlich dupliziert, geändert oder neu geordnet werden.

Signer SOLLTEN Kanonisierungsalgorithmen basierend auf den Arten von Nachrichten, die sie verarbeiten, und ihrer Risikoaversion wählen. Zum Beispiel werden E-Commerce-Sites, die hauptsächlich Kaufbelege senden, die nicht von Mailinglisten oder anderer Software verarbeitet werden, die Nachrichten wahrscheinlich ändern, im Allgemeinen die "einfache" Kanonisierung bevorzugen.

Sites, die hauptsächlich Person-zu-Person-E-Mails senden, werden wahrscheinlich bevorzugen, widerstandsfähiger gegen Änderungen während des Transports zu sein, indem sie die "relaxed"-Kanonisierung verwenden.

Sofern E-Mails nicht über Vermittler verarbeitet werden, wie Mailinglisten, die "Abmelde"-Anweisungen am Ende des Nachrichtenkörpers hinzufügen könnten, ist es unwahrscheinlich, dass das "l="-Tag zusätzlichen Nutzen vermittelt, während es einen Weg für die unbefugte Hinzufügung von Text zu einer Nachricht bietet. Die Verwendung von "l=0" treibt dies auf die Spitze und ermöglicht eine vollständige Änderung des Textes der Nachricht, ohne die Signatur ungültig zu machen. Darüber hinaus wäre ein Verifier berechtigt, einen teilweise signierten Nachrichtenkörper als inakzeptabel zu betrachten. Eine umsichtige Verwendung wird empfohlen.

5.4.2. Signatures Involving Multiple Instances of a Field (Signaturen mit mehreren Instanzen eines Feldes)

Signer, die sich entscheiden, ein vorhandenes Headerfeld zu signieren, das mehr als einmal in der Nachricht vorkommt (wie Received), MÜSSEN die physisch letzte Instanz dieses Headerfeldes im Headerblock signieren. Signer, die mehrere Instanzen eines solchen Headerfeldes signieren möchten, MÜSSEN den Headerfeldnamen mehrmals im "h="-Tag des DKIM-Signature-Headerfeldes einschließen und MÜSSEN solche Headerfelder in der Reihenfolge von unten nach oben des Headerfeldblocks signieren. Der Signer KANN mehr Instanzen eines Headerfeldnamens in "h=" einschließen, als es tatsächliche entsprechende Headerfelder gibt, damit die Signatur nicht verifiziert, wenn zusätzliche Headerfelder dieses Namens hinzugefügt werden.

INFORMATIVES BEISPIEL:

Wenn der Signer zwei vorhandene Received-Headerfelder signieren möchte und der vorhandene Header enthält:
Received: <A>
Received: <B>
Received: <C>
dann sollte das resultierende DKIM-Signature-Headerfeld lauten:
DKIM-Signature: ... h=Received : Received :...
und die Received-Headerfelder <C> und <B> werden in dieser Reihenfolge signiert.

5.5. Compute the Message Hash and Signature (Nachrichten-Hash und Signatur berechnen)

Der Signer MUSS den Nachrichten-Hash wie in Abschnitt 3.7 beschrieben berechnen und ihn dann mit dem ausgewählten Public-Key-Algorithmus signieren. Dies führt zu einem DKIM-Signature-Headerfeld, das den Body-Hash und eine Signatur des Header-Hashs enthält, wobei dieser Header das DKIM-Signature-Headerfeld selbst enthält.

Entitäten wie Mailinglisten-Manager, die DKIM implementieren und die Nachricht oder ein Headerfeld ändern (zum Beispiel das Einfügen von Abmeldeinformationen), bevor sie die Nachricht erneut übertragen, SOLLTEN jede vorhandene Signatur bei der Eingabe überprüfen und MÜSSEN solche Änderungen vornehmen, bevor sie die Nachricht erneut signieren.

5.6. Insert the DKIM-Signature Header Field (DKIM-Signature-Headerfeld einfügen)

Schließlich MUSS der Signer das im vorherigen Schritt erstellte DKIM-Signature-Headerfeld einfügen, bevor er die E-Mail überträgt. Das DKIM-Signature-Headerfeld MUSS dasselbe sein wie das zur Berechnung des Hashs verwendete, wie oben beschrieben, außer dass der Wert des "b="-Tags der im vorherigen Schritt berechnete, angemessen signierte Hash sein MUSS, signiert mit dem im "a="-Tag des DKIM-Signature-Headerfeldes angegebenen Algorithmus und unter Verwendung des privaten Schlüssels, der dem im "s="-Tag des DKIM-Signature-Headerfeldes angegebenen Selektor entspricht, wie oben in Abschnitt 5.2 gewählt.

Das DKIM-Signature-Headerfeld MUSS vor allen anderen DKIM-Signature-Feldern im Headerblock eingefügt werden.

INFORMATIVE IMPLEMENTIERUNGSANMERKUNG: Der einfachste Weg, dies zu erreichen, besteht darin, das DKIM-Signature-Headerfeld am Anfang des Headerblocks einzufügen. Insbesondere kann es vor allen vorhandenen Received-Headerfeldern platziert werden. Dies steht im Einklang damit, DKIM-Signature als Trace-Headerfeld zu behandeln.