1. Einführung (Introduction)

1.1. Motivation

Ein großer Teil des sichtbaren Gesichts des Internets besteht aus Diensten, die eine Client-Server-Architektur verwenden, bei der ein interaktiver oder automatisierter Client mit einem Anwendungsdienst kommuniziert, um Informationen abzurufen oder hochzuladen, mit anderen Entitäten zu kommunizieren oder eine Verbindung zu einem breiteren Netzwerk von Diensten herzustellen. Wenn der Client unter Verwendung des Transport Layer Security (TLS) Protokolls [TLS] oder des Datagram Transport Layer Security (DTLS) Protokolls [DTLS] mit einem Anwendungsdienst kommuniziert, bezieht er sich auf eine Vorstellung von der Identität des Servers (z. B. "die Webseite example.com"), während er versucht, eine sichere Kommunikation aufzubauen. Ebenso präsentiert der Server während der TLS-Verhandlung eine Vorstellung von seiner Dienst-Identität in Form eines Public-Key-Zertifikats, das von einer Zertifizierungsstelle (CA) im Kontext einer Internet-Public-Key-Infrastruktur unter Verwendung von X.509 [PKIX] ausgestellt wurde. Informell können wir uns diese Identitäten als die "Referenz-Identität" (reference identity) des Clients und die "präsentierte Identität" (presented identity) des Servers vorstellen (diese groben Ideen werden später in diesem Dokument durch das Konzept bestimmter Identifikatoren genauer definiert). Im Allgemeinen muss ein Client überprüfen, ob die vom Server präsentierte Identität mit seiner Referenz-Identität übereinstimmt, damit er die Kommunikation authentifizieren kann.

Viele Anwendungstechnologien folgen dem beschriebenen Muster. Solche Protokolle haben traditionell ihre eigenen Regeln für die Darstellung und Überprüfung der Identität des Anwendungsdienstes spezifiziert. Leider hat diese Divergenz der Ansätze zu einiger Verwirrung bei Zertifizierungsstellen, Anwendungsentwicklern und Protokoll-Designern geführt.

Beispielsweise stellen verschiedene Anwendungsprotokolle die Dienst-Identität auf unterschiedliche Weise dar (z. B. verwenden einige DNS-Domänennamen als generische Identifikatoren der Public-Key-Infrastruktur (PKI), während andere anwendungsspezifische Identifikatoren definieren), und viele Protokolle bieten keine klaren Regeln für den Umgang mit internationalisierten Domänennamen, Wildcard-Domänennamen oder mehreren Identitäten pro Zertifikat. Dies macht es für Zertifizierungsstellen schwierig, Zertifikate auszustellen, die in einem breiten Spektrum von Anwendungen konsistent funktionieren, für Softwareentwickler, konsistenten Adressüberprüfungscode zu erstellen, und für Protokoll-Designer, zu entscheiden, wie die Identitätsüberprüfung in ihren Protokolldefinitionen gehandhabt werden soll.

Wenn ein einziger, einheitlicher Satz von Regeln für die Darstellung und Überprüfung der Identität von Anwendungsdiensten existieren würde, könnte dies die Verwirrung unter den verschiedenen Teilnehmern verringern und auch die Qualität der Software verbessern, indem Implementierungen einen gemeinsamen Code für die Authentifizierung verwenden könnten, anstatt dass jede Anwendung die Überprüfungslogik ad hoc neu implementieren muss.

1.2. Zielgruppe (Audience)

Die Zielgruppe dieses Dokuments umfasst:

Protokoll-Designer, die Protokolle spezifizieren, die über TLS laufen.
Anwendungssoftware-Entwickler, die solche Protokolle implementieren.
Dienstanbieter, die solche Dienste bereitstellen.
Zertifizierungsstellen, die Zertifikate für die Verwendung in solchen Diensten ausstellen.

1.3. Wie dieses Dokument zu lesen ist (How to Read This Document)

Dieses Dokument ist hauptsächlich zur Wiederverwendung durch Anwendungs-Protokoll-Designer geschrieben; daher kann der Großteil der "Anforderungen"-Sprache als "eine Anwendungsprotokollspezifikation, die dieses Dokument wiederverwendet, muss die folgenden Anforderungen einschließen oder referenzieren" interpretiert werden.

Für Anwendungssoftware-Entwickler stellen wir separate Abschnitte bereit, die die Server-Identitätsüberprüfung (Abschnitt 6) und damit verbundene Sicherheitserwägungen (Abschnitt 7) behandeln.

Für Dienstanbieter und Zertifizierungsstellen stellen wir separate Abschnitte bereit, die die Darstellung der Server-Identität (Abschnitt 4) und die Anforderung von Server-Zertifikaten (Abschnitt 5) behandeln.

1.4. Anwendbarkeit (Applicability)

Dieses Dokument beabsichtigt nicht, eine allgemeine Nutzungsrichtlinie für alle PKIX-Zertifikate zu definieren. Sein Umfang beschränkt sich stattdessen auf TLS-Clients, die X.509 (PKIX)-Zertifikate verwenden, um Server zu authentifizieren. Es regelt nicht die Authentifizierung in Bezug auf S/MIME, IPsec oder andere Protokolle (außer wie explizit in der Spezifikation eines solchen Protokolls angegeben, das dieses Dokument wiederverwendet). Obwohl die in diesem Dokument definierten Konzepte in anderen Kontexten nützlich sein könnten, liegen solche Erweiterungen außerhalb des Umfangs dieses Dokuments.

Dieses Dokument ist hauptsächlich zur Übernahme durch neue Anwendungsprotokolle gedacht, obwohl erwartet wird, dass bestehende Anwendungsprotokolle (wie die in Anhang B aufgeführten) schrittweise zur Verwendung dieses Dokuments migrieren könnten.

1.5. Übersicht der Empfehlungen (Overview of Recommendations)

Wir fassen die Empfehlungen dieses Dokuments in der folgenden Tabelle zusammen; Details werden in den folgenden Abschnitten bereitgestellt.

Entität	Rolle	Empfehlung
Protokoll-Designer	Spezifizieren	Dieses Dokument wenn möglich referenzieren; spezifische Identifikatortypen definieren.
App-SW-Entwickler	Überprüfung implementieren	Algos in Abschnitt 6 folgen; Wildcards mit Vorsicht behandeln; "Pinning" (Benutzerüberschreibung) unterstützen.
Dienstanbieter	Dienst bereitstellen	Certs mit DNS-ID erhalten; SRV-ID oder URI-ID einschließen, falls erforderlich.
Zertifizierungsstelle	Zertifikat ausstellen	DNS-ID in subjectAltName einschließen; Common Name im Subjekt nur für Abwärtskompatibilität einschließen.

1.6. Verallgemeinerung aktueller Technologien (Generalization from Current Technologies)

Die in diesem Dokument spezifizierten Empfehlungen wurden aus den Regeln zur Identitätsüberprüfung verallgemeinert, die in verschiedenen Anwendungsprotokollspezifikationen enthalten sind (einschließlich der in Anhang B aufgeführten). Unser allgemeiner Ansatz war, dass wir bestehenden Praktiken folgen sollten, es sei denn, es gibt zwingende Gründe, dies nicht zu tun (z. B. um Sicherheitslücken zu schließen, die in früheren Spezifikationen identifiziert wurden). Nach einer detaillierten Analyse der aktuellen Praktiken und umfassender Beratung mit der Gemeinschaft der Protokollentwicklung glauben die Autoren, dass die in diesem Dokument spezifizierten Regeln im Wesentlichen mit der Mehrheit der derzeit eingesetzten Nutzung übereinstimmen. Wo wir uns bemüht haben, die Kompatibilität mit der aktuellen Nutzung zu maximieren, wie z. B. die Verwendung des X.509 "Common Name" zur Darstellung von Server-Identitäten, haben wir manchmal empfohlen, bestehende Einschränkungen aus Sicherheitsgründen zu verschärfen (z. B. zum Schutz vor Angriffen im Zusammenhang mit Wildcard-Zertifikaten).

1.7. Umfang (Scope)

1.7.1. Im Rahmen (In Scope)

Diese Spezifikation gilt für Software-Implementierungen und Bereitstellungen, bei denen alle folgenden Bedingungen zutreffen:

Ein Client möchte mit einem Dienst kommunizieren, der durch einen DNS-Domänennamen identifiziert wird.
Der Client verwendet DNS, um den Domänennamen in eine Netzwerkadresse (z. B. eine IPv4- oder IPv6-Adresse) aufzulösen.
Der Client kommuniziert mit dem Server unter Verwendung des Transport Layer Security (TLS) Protokolls [TLS] oder des Datagram Transport Layer Security (DTLS) Protokolls [DTLS] und deren Erweiterungen (z. B. die Server Name Indication Erweiterung aus [TLS-EXT]).
Der Server präsentiert seine Identität dem Client in Form eines X.509-basierten Public-Key-Zertifikats [PKIX].
Der Client verwendet das vom Server präsentierte Zertifikat im Verlauf der Server-Identitätsüberprüfung.

1.7.2. Außerhalb des Rahmens (Out of Scope)

Die folgenden Themen liegen außerhalb des Umfangs dieses Dokuments:

Client- oder Server-Authentifizierung außer der Anwendungsdienst-Authentifizierung (z. B. Client-Authentifizierung oder Authentifizierung in XML-basierten Protokollen, bei denen Partner sowohl als Client als auch als Server agieren können).
Zertifikate im Kontext anderer PKI-Profile als PKIX (z. B. OpenPGP [OPENPGP]).
Authentifizierung von Diensten, die nicht durch DNS-Domänennamen identifiziert werden (z. B. Dienste, die durch IP-Adressen wie [IP] oder [IPv6] Adressen oder durch andere Identifikatortypen wie die in [NAPTR] verwendeten identifiziert werden).
Auflösung von DNS-Domänennamen in IP-Adressen (obwohl dies eine notwendige Vorbedingung für den Betrieb dieses Dokuments ist).
Mechanismen zur Überprüfung der Gültigkeit eines Zertifikats (z. B. gegen eine Zertifikats widerrufsliste [PKIX] oder über das OCSP-Protokoll [OCSP]).
Autorisierungsentscheidungen (z. B. ob ein Client einer bestimmten Zertifizierungsstelle vertrauen oder sich mit einem bestimmten Server verbinden sollte).
Wie eine Identität überprüft wird, wenn das Zertifikat keine bekannten Identifikatortypen enthält (z. B. nur proprietäre Identifikatortypen, die der Client nicht versteht).
Details der Benutzeroberfläche (z. B. [WSC-UI]).

1.8. Terminologie (Terminology)

Da viele Konzepte im Zusammenhang mit "Identität" oft zu vage sind, um in Anwendungsprotokollen umsetzbar zu sein, definieren wir eine Reihe konkreterer Begriffe zur Verwendung in dieser Spezifikation.

Anwendungsdienst (application service): Ein Dienst im Internet, mit dem ein interaktiver oder automatisierter Client eine Verbindung herstellt, um Informationen abzurufen oder hochzuladen, mit anderen Entitäten zu kommunizieren oder sich mit einem breiteren Netzwerk von Diensten zu verbinden.

Anwendungsdienstanbieter (application service provider): Eine Entität, die einen bestimmten Anwendungsdienst hostet und verwaltet.

Anwendungsdienst-Typ (application service type): Ein Identifikator, der das spezifische Anwendungsprotokoll oder die Protokollkonfiguration unterscheidet, die einen Anwendungsdienst von einem anderen unterscheidet. Mögliche Werte sind ein DNS-SRV-Dienstname (z. B. "ldap", "imap", "xmpp-client") oder ein URI-Schema-Name (z. B. "http", "sip", "acap").

Attributtyp (attribute type): Der Objektidentifikator für den Informationstyp, der in einem X.500-Attribut [X.500] enthalten ist. Im Kontext dieses Dokuments bezieht sich dies auf bestimmte Objektidentifikatoren (z. B. CN), die in Attributwerte-Behauptungen (Attribute Value Assertions) [X.501] verwendet werden.

Attributwerte-Behauptung (Attribute Value Assertion - AVA): Eine Behauptung eines Attributtyps und eines entsprechenden Wertes [X.501].

Zertifizierungsstelle (certification authority - CA): Eine Entität, die Zertifikate ausstellt (z. B. "Example CA").

CN-ID: Ein Common Name-Attribut (d. h. ein Attribut vom Typ 2.5.4.3 [X.520]) im Subject-Feld eines Zertifikats [PKIX], das eine Zeichenfolge enthält, die der Syntax eines DNS-Domänennamens entspricht.

Common Name: Ein Attribut (d. h. ein Attribut vom Typ 2.5.4.3 [X.520]) im Subject-Feld eines Zertifikats [PKIX]. Aus historischen Gründen ist es oft notwendig, den Common Name als Identifikator zu überprüfen, aber es ist üblich, dass Zertifizierungsstellen dort nicht nur DNS-Domänennamen, sondern auch andere Zeichenfolgen platzieren (z. B. "John Doe" oder "Simple Authority"). Wir müssen daher den Common Name als Identifikator (siehe CN-ID) von anderen Formen des Common Name unterscheiden.

DNS-ID: Ein Identifikator vom Typ dNSName in der subjectAltName-Erweiterung (wie in [PKIX] definiert).

Identifikator (identifier): Eine Zeichenfolge, die von einem Client oder Server verwendet wird, um eine bestimmte Anwendungsentität zu identifizieren.

Identifikatortyp (identifier type): Eine spezifische Klasse von Identifikatoren (z. B. DNS-ID, CN-ID, SRV-ID oder URI-ID).

PKIX: Public-Key-Infrastruktur unter Verwendung von X.509 (Public Key Infrastructure using X.509), wie in [PKIX] definiert.

Präsentierte Identität (presented identity): Ein Identifikator, der von einem Server einem Client in einem PKIX-Zertifikat präsentiert wird.

Referenz-Identität (reference identity): Ein Identifikator, von dem ein Client erwartet, dass ein Server ihn in einem Zertifikat präsentiert.

Quelldomäne (source domain): Der vollqualifizierte DNS-Domänenname [DNS-CONCEPTS], den ein Client aus seiner empfangenen Eingabe (Benutzereingabe, Konfiguration usw.) extrahiert. Die Quelldomäne ist der primäre Identifikator, mit dem eine sichere Verbindung aufgebaut wird.

SRV-ID: Ein Identifikator vom Typ otherName in der subjectAltName-Erweiterung, in der Form von SRVName (wie in [SRVNAME] definiert).

URI-ID: Ein Identifikator vom Typ uniformResourceIdentifier in der subjectAltName-Erweiterung (wie in [PKIX] definiert).

Wildcard-Zertifikat (wildcard certificate): Ein Zertifikat, das mindestens einen Identifikator mit einem Wildcard-Zeichen ('*') enthält.

Anheften (pinning): Die Handlung eines Benutzers, ein spezifisches Zertifikat mit einem bestimmten Dienst zu assoziieren oder "anzuheften", typischerweise bei der ersten Verbindung oder nach einer manuellen Überprüfung durch den Benutzer nach einem Zertifikatsvalidierungsfehler.

Die Schlüsselwörter "MUSS" (MUST), "DARF NICHT" (MUST NOT), "ERFORDERLICH" (REQUIRED), "SOLL" (SHALL), "SOLL NICHT" (SHALL NOT), "SOLLTE" (SHOULD), "SOLLTE NICHT" (SHOULD NOT), "EMPFOHLEN" (RECOMMENDED), "KANN" (MAY) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind so zu interpretieren, wie in [KEYWORDS] beschrieben.