4. Semantics of Multiple Signatures (Semantik mehrfacher Signaturen)

4.1. Example Scenarios (Beispielszenarien)

Es gibt viele Gründe, warum eine Nachricht mehrere Signaturen haben könnte. Angenommen, SHA-256 wird in Zukunft als nicht ausreichend stark befunden und die DKIM-Nutzung wechselt zu SHA-1024. Ein Signer könnte sofort mit dem neueren Algorithmus signieren, aber auch weiterhin mit dem älteren Algorithmus signieren, um die Interoperabilität mit Verifiern zu gewährleisten, die noch nicht aktualisiert wurden. Der Signer würde dies tun, indem er zwei DKIM-Signature-Headerfelder hinzufügt, eines für jeden Algorithmus. Ältere Verifier, die SHA-1024 nicht als akzeptablen Algorithmus erkennen, würden diese Signatur überspringen und den älteren Algorithmus verwenden; neuere Verifier könnten nach ihrer Wahl eine der beiden Signaturen verwenden und, wenn alles andere gleich ist, möglicherweise nicht einmal versuchen, die andere Signatur zu verifizieren.

Ebenso könnte ein Signer eine Nachricht signieren, die alle Headerfelder und kein "l="-Tag enthält (um strenge Verifier zu befriedigen), und ein zweites Mal mit einem begrenzten Satz von Headerfeldern und einem "l="-Tag (in Erwartung möglicher Nachrichtenänderungen auf dem Weg zu anderen Verifieren). Verifier könnten dann wählen, welche Signatur sie bevorzugen.

Natürlich könnte eine Nachricht auch mehrere Signaturen haben, weil sie mehrere Signer durchlaufen hat. Ein häufiger Fall ist zu erwarten, dass eine signierte Nachricht durch eine Mailingliste läuft, die ebenfalls alle Nachrichten signiert. Unter der Annahme, dass beide dieser Signaturen verifiziert werden, könnte ein Empfänger die Nachricht akzeptieren, wenn eine dieser Signaturen bekanntermaßen von vertrauenswürdigen Quellen stammt.

Insbesondere könnten Empfänger Mailinglisten, die sie abonniert haben und die akzeptable Anti-Missbrauchsrichtlinien haben, auf eine Whitelist setzen, um Nachrichten zu akzeptieren, die an diese Liste gesendet werden, auch von unbekannten Autoren. Sie könnten auch weniger vertrauenswürdige Mailinglisten abonnieren (z. B. solche ohne Anti-Missbrauchsschutz) und bereit sein, alle Nachrichten von bestimmten Autoren zu akzeptieren, aber auf zusätzlichen Missbrauchsscans für andere Nachrichten bestehen.

Ein weiteres verwandtes Beispiel für mehrere Signer könnten Weiterleitungsdienste sein, wie sie üblicherweise mit akademischen Alumni-Websites verbunden sind. Beispielsweise könnte ein Empfänger eine Adresse bei members.example.org haben, einer Website, die Anti-Missbrauchsschutz hat, der etwas weniger effektiv ist als der Empfänger es bevorzugen würde. Ein solcher Empfänger könnte bestimmte Autoren haben, deren Nachrichten absolut vertraut würden, aber Nachrichten von unbekannten Autoren, die die Prüfung des Weiterleiters bestanden haben, hätten nur mittleres Vertrauen.

4.2. Interpretation (Interpretation)

Ein Signer, der einer Nachricht eine Signatur hinzufügt, erstellt lediglich einen neuen DKIM-Signature-Header unter Verwendung der üblichen Semantik der "h="-Option. Ein Signer KANN zuvor vorhandene DKIM-Signature-Headerfelder unter Verwendung der in Abschnitt 5.4 beschriebenen Methode zum Signieren von Trace-Headerfeldern signieren.

Beachten Sie, dass Signer sich bewusst sein sollten, dass das Signieren von DKIM-Signature-Headerfeldern zu Signaturfehlern mit Vermittlern führen kann, die nicht erkennen, dass DKIM-Signature-Headerfelder Trace-Headerfelder sind, und sie unwissentlich neu ordnen, wodurch solche Signaturen ungültig werden. Aus diesem Grund wird das Signieren vorhandener DKIM-Signature-Headerfelder nicht empfohlen, obwohl es legal ist.

INFORMATIVE ANMERKUNG: Wenn ein Headerfeld mit mehreren Instanzen signiert wird, werden diese Headerfelder immer von unten nach oben signiert. Daher ist es nicht möglich, nur bestimmte DKIM-Signature-Headerfelder zu signieren. Beispielsweise, wenn die zu signierende Nachricht bereits drei DKIM-Signature-Headerfelder A, B und C enthält, ist es möglich, alle zu signieren, nur B und C oder nur C, aber nicht nur A, nur B, nur A und B oder nur A und C.

Ein Signer KANN mehr als ein DKIM-Signature-Headerfeld mit unterschiedlichen Parametern hinzufügen. Beispielsweise könnte ein Signer während einer Übergangszeit Signaturen mit zwei verschiedenen Hash-Algorithmen erstellen wollen.

Signer SOLLTEN keine DKIM-Signature-Headerfelder aus Nachrichten entfernen, die sie signieren, auch wenn sie wissen, dass die Signaturen nicht verifiziert werden können.

Bei der Bewertung einer Nachricht mit mehreren Signaturen SOLLTE ein Verifier Signaturen unabhängig und nach ihren eigenen Vorzügen bewerten. Beispielsweise würde ein Verifier, der durch Richtlinien keine Signaturen mit veralteten kryptografischen Algorithmen akzeptiert, solche Signaturen als ungültig betrachten. Verifier KÖNNEN Signaturen in beliebiger Reihenfolge ihrer Wahl verarbeiten; beispielsweise könnten einige Verifier Signaturen verarbeiten, die dem From-Feld im Nachrichtenheader entsprechen, vor anderen Signaturen. Siehe Abschnitt 6.1 für weitere Informationen zu Signaturwahlmöglichkeiten.

INFORMATIVE IMPLEMENTIERUNGSANMERKUNG: Versuche von Verifern, gültige Signaturen mit ungültigen Signaturen zu korrelieren, um zu erraten, warum eine Signatur fehlgeschlagen ist, sind nicht ratsam. Insbesondere gibt es keine allgemeine Möglichkeit für einen Verifier festzustellen, dass eine ungültige Signatur jemals gültig war.

Verifier SOLLTEN weiterhin Signaturen prüfen, bis eine Signatur erfolgreich zur Zufriedenheit des Verifiers verifiziert wird. Um potenzielle Denial-of-Service-Angriffe zu begrenzen, KÖNNEN Verifier die Gesamtzahl der Signaturen begrenzen, die sie zu verifizieren versuchen.

Wenn ein Verifier-Modul Signaturen meldet, deren Bewertungen PERMFAIL-Ergebnisse erzeugt haben, SOLLTEN Identity Assessors diese Signaturen ignorieren (siehe Abschnitt 6.1) und so handeln, als wären sie in der Nachricht nicht vorhanden.