3.6 Key Management and Representation (Schlüsselverwaltung und -darstellung)

3.6. Key Management and Representation (Schlüsselverwaltung und -darstellung)

Signaturanwendungen erfordern ein gewisses Maß an Sicherheit, dass der öffentliche Verifizierungsschlüssel mit dem beanspruchten Signer verbunden ist. Viele Anwendungen erreichen dies durch die Verwendung von öffentlichen Schlüsselzertifikaten, die von einer vertrauenswürdigen dritten Partei ausgestellt werden. DKIM kann jedoch ein ausreichendes Sicherheitsniveau mit erheblich verbesserter Skalierbarkeit erreichen, indem der Verifier einfach den DNS-Eintrag des mutmaßlichen Signers (oder ein Sicherheitsäquivalent) abfragt, um den öffentlichen Schlüssel abzurufen.

DKIM-Schlüssel können potenziell in mehreren Arten von Schlüsselservern und in mehreren Formaten gespeichert werden. Die Speicherung und das Format von Schlüsseln sind für den Rest des DKIM-Algorithmus irrelevant.

Parameter für den Schlüsselsuchalgorithmus sind der Typ der Suche (das "q="-Tag), die Domäne des Signers (das "d="-Tag des DKIM-Signature-Headerfeldes) und der Selector (das "s="-Tag).

public_key = dkim_find_key(q_val, d_val, s_val)

Dieses Dokument definiert eine einzelne Bindung unter Verwendung von DNS TXT RRs zur Verteilung der Schlüssel. Andere Bindungen können in Zukunft definiert werden.

3.6.1. Textual Representation (Textuelle Darstellung)

Es wird erwartet, dass viele Schlüsselserver sich dafür entscheiden werden, die Schlüssel in einem ansonsten unstrukturierten Textformat darzustellen (z. B. würde eine XML-Form für diesen Zweck nicht als unstrukturierter Text betrachtet). Die folgende Definition MUSS für jeden DKIM-Schlüssel verwendet werden, der in einer ansonsten unstrukturierten textuellen Form dargestellt wird.

Die Gesamtsyntax ist eine Tag-Liste, wie in Abschnitt 3.2 beschrieben. Die aktuell gültigen Tags werden unten beschrieben. Andere Tags KÖNNEN vorhanden sein und MÜSSEN von jeder Implementierung ignoriert werden, die sie nicht versteht.

v= Version des DKIM-Schlüsseldatensatzes (Klartext; EMPFOHLEN, Standard ist "DKIM1"). Falls angegeben, MUSS dieses Tag auf "DKIM1" (ohne Anführungszeichen) gesetzt werden. Dieses Tag MUSS das erste Tag im Datensatz sein. Datensätze, die mit einem "v="-Tag mit einem anderen Wert beginnen, MÜSSEN verworfen werden. Beachten Sie, dass Verifizierer einen Zeichenfolgenvergleich für diesen Wert durchführen müssen; zum Beispiel ist "DKIM1" nicht dasselbe wie "DKIM1.0".

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= Akzeptable Hash-Algorithmen (Klartext; OPTIONAL, Standard erlaubt alle Algorithmen). Eine durch Doppelpunkte getrennte Liste von Hash-Algorithmen, die verwendet werden könnten. Nicht erkannte Algorithmen MÜSSEN ignoriert werden. Siehe Abschnitt 3.3 für eine Diskussion der von Signern und Verifizierern implementierten Hash-Algorithmen. Die Menge der in diesem Tag in jedem Datensatz aufgeführten Algorithmen ist eine betriebliche Entscheidung des Signers.

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; für zukünftige Erweiterung

k= Schlüsseltyp (Klartext; OPTIONAL, Standard ist "rsa"). Signer und Verifizierer MÜSSEN den "rsa"-Schlüsseltyp unterstützen. Der "rsa"-Schlüsseltyp gibt an, dass ein ASN.1 DER-kodierter [ITU-X660-1997] RSAPublicKey (siehe [RFC3447], Abschnitte 3.1 und A.1.1) im "p="-Tag verwendet wird. (Hinweis: Das "p="-Tag kodiert den Wert zusätzlich mit dem base64-Algorithmus.) Nicht erkannte Schlüsseltypen MÜSSEN ignoriert werden.

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; für zukünftige Erweiterung

n= Hinweise, die für einen Menschen von Interesse sein könnten (qp-section; OPTIONAL, Standard ist leer). Es wird keine Interpretation durch ein Programm vorgenommen. Dieses Tag sollte in jedem Schlüsselservermechanismus, der Platzbeschränkungen hat (insbesondere DNS), sparsam verwendet werden. Dies ist für Administratoren gedacht, nicht für Endbenutzer.

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= Öffentliche Schlüsseldaten (base64; ERFORDERLICH). Ein leerer Wert bedeutet, dass dieser öffentliche Schlüssel widerrufen wurde. Die Syntax und Semantik dieses Tag-Werts vor der base64-Kodierung werden durch das "k="-Tag definiert.

INFORMATIVE BEGRÜNDUNG: Wenn ein privater Schlüssel kompromittiert oder anderweitig deaktiviert wurde (z. B. ein Outsourcing-Vertrag wurde beendet), möchte ein Signer möglicherweise explizit erklären, dass er über den Selector Bescheid weiß, aber alle Nachrichten, die diesen Selector verwenden, sollten bei der Verifizierung fehlschlagen. Verifizierer SOLLTEN einen Fehlercode für jedes DKIM-Signature-Headerfeld mit einem Selector zurückgeben, der auf einen widerrufenen Schlüssel verweist. (Siehe Abschnitt 6.1.2 für Details.)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

INFORMATIVER HINWEIS: Ein base64string darf Leerzeichen (FWS) an beliebigen Stellen enthalten; jedoch müssen alle CRLFs von mindestens einem WSP-Zeichen gefolgt werden. Implementierer und Administratoren werden gewarnt sicherzustellen, dass Selector-TXT-RRs dieser Spezifikation entsprechen.

s= Servicetyp (Klartext; OPTIONAL; Standard ist "*"). Eine durch Doppelpunkte getrennte Liste von Servicetypen, für die dieser Datensatz gilt. Verifizierer für einen bestimmten Servicetyp MÜSSEN diesen Datensatz ignorieren, wenn der entsprechende Typ nicht aufgeführt ist. Nicht erkannte Servicetypen MÜSSEN ignoriert werden. Aktuell definierte Servicetypen sind wie folgt:

* entspricht allen Servicetypen
email elektronische Post (nicht notwendigerweise auf SMTP beschränkt)

Dieses Tag soll die Verwendung von Schlüsseln für andere Zwecke einschränken, falls die Verwendung von DKIM in Zukunft von anderen Diensten definiert wird.

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; für zukünftige Erweiterung

t= Flags, dargestellt als durch Doppelpunkte getrennte Liste von Namen (Klartext; OPTIONAL, Standard ist keine Flags gesetzt). Nicht erkannte Flags MÜSSEN ignoriert werden. Die definierten Flags sind wie folgt:

y Diese Domäne testet DKIM. Verifizierer DÜRFEN Nachrichten von Signern im Testmodus NICHT anders behandeln als unsignierte E-Mails, auch wenn die Signatur nicht verifiziert werden kann. Verifizierer KÖNNEN Testmodusergebnisse verfolgen wollen, um den Signer zu unterstützen.
s Alle DKIM-Signature-Headerfelder, die das "i="-Tag verwenden, MÜSSEN denselben Domänenwert auf der rechten Seite des "@" im "i="-Tag und den Wert des "d="-Tags haben. Das heißt, die "i="-Domäne DARF NICHT eine Subdomäne von "d=" sein. Die Verwendung dieses Flags wird EMPFOHLEN, es sei denn, Subdomaining ist erforderlich.

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; für zukünftige Erweiterung

3.6.2. DNS Binding (DNS-Bindung)

Eine Bindung unter Verwendung von DNS TXT RRs als Schlüsseldienst wird hiermit definiert. Alle Implementierungen MÜSSEN diese Bindung unterstützen.

3.6.2.1. Namespace (Namensraum)

Alle DKIM-Schlüssel werden in einer Subdomäne namens "_domainkey" gespeichert. Bei einem DKIM-Signature-Feld mit einem "d="-Tag von "example.com" und einem "s="-Tag von "foo.bar" lautet die DNS-Abfrage "foo.bar._domainkey.example.com".

3.6.2.2. Resource Record Types for Key Storage (Ressourcendatensatztypen für Schlüsselspeicherung)

Der verwendete DNS-Ressourcendatensatztyp wird durch eine Option zum Query-Type ("q=")-Tag angegeben. Die einzige in dieser Basisspezifikation definierte Option ist "txt", die die Verwendung eines TXT RR anzeigt. Eine spätere Erweiterung dieses Standards kann einen anderen RR-Typ definieren.

Zeichenfolgen in einem TXT RR MÜSSEN vor der Verwendung ohne Zwischenleerzeichen zusammengefügt werden. TXT RRs MÜSSEN für einen bestimmten Selector-Namen eindeutig sein; das heißt, wenn es mehrere Datensätze in einem RRset gibt, sind die Ergebnisse undefiniert.

TXT RRs werden wie in Abschnitt 3.6.1 beschrieben kodiert.