Zum Hauptinhalt springen

2. Der TLSA-Ressourceneintrag (The TLSA Resource Record)

Der TLSA-DNS-Ressourceneintrag (RR) wird verwendet, um ein TLS-Serverzertifikat oder einen öffentlichen Schlüssel mit dem Domainnamen zu verknüpfen, in dem der Eintrag gefunden wird, und bildet so eine "TLSA-Zertifikatszuordnung". Die Semantik, wie der TLSA-RR interpretiert wird, wird später in diesem Dokument angegeben.

Der Typwert für den TLSA-RR-Typ ist in Abschnitt 7.1 definiert.

Der TLSA-RR ist klassenunabhängig.

Der TLSA-RR hat keine speziellen Time-to-Live (TTL)-Anforderungen.

2.1. TLSA RDATA Wire-Format (TLSA RDATA Wire Format)​

Das RDATA für einen TLSA-RR besteht aus einem Ein-Oktett-Zertifikatsverwendungsfeld, einem Ein-Oktett-Selektorfeld, einem Ein-Oktett-Übereinstimmungstypfeld und dem Zertifikatszuordnungsdatenfeld.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Zert.Verw.   |   Selektor    | Übereinstim.  |               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 Zertifikatszuordnungsdaten                    /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. Das Zertifikatsverwendungsfeld (The Certificate Usage Field)​

Ein Ein-Oktett-Wert, "Zertifikatsverwendung" genannt, gibt die bereitgestellte Zuordnung an, die verwendet wird, um das im TLS-Handshake präsentierte Zertifikat abzugleichen. Dieser Wert wird in einem neuen IANA-Register definiert (siehe Abschnitt 7.2), um es in Zukunft einfacher zu machen, zusätzliche Zertifikatsverwendungen hinzuzufügen. Die in diesem Dokument definierten Zertifikatsverwendungen sind:

0 -- CA-Einschränkung: Zertifikatsverwendung 0 wird verwendet, um ein CA-Zertifikat oder den öffentlichen Schlüssel eines solchen Zertifikats anzugeben, das in einem der PKIX-Zertifizierungspfade für das vom Server in TLS angegebene Endentitätszertifikat gefunden werden MUSS. Diese Zertifikatsverwendung wird manchmal als "CA-Einschränkung" bezeichnet, da sie einschränkt, welche CA verwendet werden kann, um Zertifikate für einen bestimmten Dienst auf einem Host auszustellen. Das präsentierte Zertifikat MUSS die PKIX-Zertifizierungspfadvalidierung bestehen, und ein CA-Zertifikat, das dem TLSA-Eintrag entspricht, MUSS als Teil eines gültigen Zertifizierungspfads enthalten sein. Da diese Zertifikatsverwendung sowohl Vertrauensanker als auch CA-Zertifikate zulässt, kann das Zertifikat die basicConstraints-Erweiterung aufweisen oder auch nicht.

1 -- Dienstzertifikatseinschränkung: Zertifikatsverwendung 1 wird verwendet, um ein Endentitätszertifikat oder den öffentlichen Schlüssel eines solchen Zertifikats anzugeben, das mit dem vom Server in TLS angegebenen Endentitätszertifikat übereinstimmen MUSS. Diese Zertifikatsverwendung wird manchmal als "Dienstzertifikatseinschränkung" bezeichnet, da sie einschränkt, welches Endentitätszertifikat von einem bestimmten Dienst auf einem Host verwendet werden kann. Das Zielzertifikat MUSS die PKIX-Zertifizierungspfadvalidierung bestehen und MUSS dem TLSA-Eintrag entsprechen.

2 -- Vertrauensanker-Assertion: Zertifikatsverwendung 2 wird verwendet, um ein Zertifikat oder den öffentlichen Schlüssel eines solchen Zertifikats anzugeben, das als Vertrauensanker verwendet werden MUSS, wenn das vom Server in TLS angegebene Endentitätszertifikat validiert wird. Diese Zertifikatsverwendung wird manchmal als "Vertrauensanker-Assertion" bezeichnet und ermöglicht es einem Domainnamen-Administrator, einen neuen Vertrauensanker anzugeben -- zum Beispiel, wenn die Domain ihre eigenen Zertifikate unter ihrer eigenen CA ausstellt, von der nicht erwartet wird, dass sie in der Sammlung von Vertrauensankern der Endbenutzer enthalten ist. Das Zielzertifikat MUSS die PKIX-Zertifizierungspfadvalidierung bestehen, wobei jedes Zertifikat, das dem TLSA-Eintrag entspricht, als Vertrauensanker für diese Zertifizierungspfadvalidierung betrachtet wird.

3 -- Domain-ausgestelltes Zertifikat: Zertifikatsverwendung 3 wird verwendet, um ein Zertifikat oder den öffentlichen Schlüssel eines solchen Zertifikats anzugeben, das mit dem vom Server in TLS angegebenen Endentitätszertifikat übereinstimmen MUSS. Diese Zertifikatsverwendung wird manchmal als "Domain-ausgestelltes Zertifikat" bezeichnet, da sie es einem Domainnamen-Administrator ermöglicht, Zertifikate für eine Domain auszustellen, ohne eine Drittanbieter-CA einzubeziehen. Das Zielzertifikat MUSS dem TLSA-Eintrag entsprechen. Der Unterschied zwischen Zertifikatsverwendung 1 und Zertifikatsverwendung 3 besteht darin, dass Zertifikatsverwendung 1 erfordert, dass das Zertifikat die PKIX-Validierung besteht, aber die PKIX-Validierung wird für Zertifikatsverwendung 3 nicht getestet.

Die in diesem Dokument definierten Zertifikatsverwendungen gelten ausdrücklich nur für PKIX-formatierte Zertifikate in DER-Kodierung [X.690]. Wenn TLS später andere Formate zulässt oder wenn Erweiterungen zu diesem RRtype vorgenommen werden, die andere Formate für Zertifikate akzeptieren, benötigen diese Zertifikate ihre eigenen Zertifikatsverwendungswerte.

2.1.2. Das Selektorfeld (The Selector Field)​

Ein Ein-Oktett-Wert, "Selektor" genannt, gibt an, welcher Teil des vom Server präsentierten TLS-Zertifikats mit den Zuordnungsdaten abgeglichen wird. Dieser Wert wird in einem neuen IANA-Register definiert (siehe Abschnitt 7.3). Die in diesem Dokument definierten Selektoren sind:

0 -- Vollständiges Zertifikat: die Zertifikatsbinärstruktur wie in [RFC5280] definiert

1 -- SubjectPublicKeyInfo: DER-kodierte Binärstruktur wie in [RFC5280] definiert

(Beachten Sie, dass die Verwendung von "Selektor" in diesem Dokument völlig unabhängig von der Verwendung von "Selektor" in DomainKeys Identified Mail (DKIM) [RFC6376] ist.)

2.1.3. Das Übereinstimmungstypfeld (The Matching Type Field)​

Ein Ein-Oktett-Wert, "Übereinstimmungstyp" genannt, gibt an, wie die Zertifikatszuordnung präsentiert wird. Dieser Wert wird in einem neuen IANA-Register definiert (siehe Abschnitt 7.4). Die in diesem Dokument definierten Typen sind:

0 -- Exakte Übereinstimmung bei ausgewähltem Inhalt

1 -- SHA-256-Hash des ausgewählten Inhalts [RFC6234]

2 -- SHA-512-Hash des ausgewählten Inhalts [RFC6234]

Wenn der Übereinstimmungstyp des TLSA-Eintrags ein Hash ist, hilft es Clients, die eine kleine Anzahl von Hash-Algorithmen unterstützen, wenn der Eintrag denselben Hash-Algorithmus verwendet, der in der Signatur im Zertifikat verwendet wurde (falls möglich).

2.1.4. Das Zertifikatszuordnungsdatenfeld (The Certificate Association Data Field)​

Dieses Feld gibt die zu vergleichenden "Zertifikatszuordnungsdaten" an. Diese Bytes sind entweder Rohdaten (d. h. das vollständige Zertifikat oder sein SubjectPublicKeyInfo, je nach Selektor) für Übereinstimmungstyp 0 oder der Hash der Rohdaten für Übereinstimmungstypen 1 und 2. Die Daten beziehen sich auf das Zertifikat in der Zuordnung, nicht auf das TLS-ASN.1-Zertifikatsobjekt.

2.2. TLSA-RR-Präsentationsformat (TLSA RR Presentation Format)​

Das Präsentationsformat des RDATA-Teils (wie in [RFC1035] definiert) ist wie folgt:

  • Das Zertifikatsverwendungsfeld MUSS als 8-Bit-unsigned Integer dargestellt werden.
  • Das Selektorfeld MUSS als 8-Bit-unsigned Integer dargestellt werden.
  • Das Übereinstimmungstypfeld MUSS als 8-Bit-unsigned Integer dargestellt werden.
  • Das Zertifikatszuordnungsdatenfeld MUSS als Zeichenfolge von Hexadezimalzeichen dargestellt werden. Leerzeichen sind innerhalb der Zeichenfolge von Hexadezimalzeichen zulässig, wie in [RFC1035] beschrieben.

2.3. TLSA-RR-Beispiele (TLSA RR Examples)​

In den folgenden Beispielen wird der Domainname unter Verwendung der Regeln in Abschnitt 3 gebildet.

Ein Beispiel für eine gehashte (SHA-256) Zuordnung eines PKIX-CA-Zertifikats:

_443._tcp.www.example.com. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

Ein Beispiel für eine gehashte (SHA-512) Subject-Public-Key-Zuordnung eines PKIX-Endentitätszertifikats:

_443._tcp.www.example.com. IN TLSA (
   1 1 2 92003ba34942dc74152e2f2c408d29ec
         a5a520e7f2e06bb944f4dca346baf63c
         1b177615d466f6c4b71c216a50292bd5
         8c9ebdd2f74e38fe51ffd48c43326cbc )

Ein Beispiel für eine vollständige Zertifikatszuordnung eines PKIX-Endentitätszertifikats:

_443._tcp.www.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )
Letztes Update am