2. Benennung von Anwendungsdiensten (Naming of Application Services)

Dieser Abschnitt beschreibt die Benennung von Anwendungsdiensten im Internet und beschreibt dann kurz die Benennung von Subjekten in PKIX.

2.1. Benennung von Anwendungsdiensten (Naming Application Services)

Diese Spezifikation geht davon aus, dass der Name eines Anwendungsdienstes auf einem DNS-Domänennamen (z. B. "example.com") basiert, optional ergänzt durch den Anwendungsdienst-Typ (z. B. "der IMAP-Server bei example.com").

Aus der Perspektive des Anwendungsclients oder Benutzers sind einige Namen direkt, weil sie direkt von einem menschlichen Benutzer bereitgestellt werden (z. B. über Laufzeiteingabe, Vorkonfiguration oder explizite Akzeptanz eines Client-Kommunikationsversuchs); während andere Namen indirekt sind, weil sie vom Client automatisch auf der Grundlage der Benutzereingabe aufgelöst werden (z. B. Auflösung eines Zielnamens aus einem Quellnamen unter Verwendung von DNS SRV- oder NAPTR-Datensätzen). Diese Dimension ist am wichtigsten für den Konsum von Zertifikaten, insbesondere die Überprüfung, wie in diesem Dokument beschrieben.

Aus der Perspektive des Anwendungsdienstes sind einige Namen uneingeschränkt, weil sie für jeden Diensttyp verwendet werden können (z. B. kann ein Zertifikat sowohl für HTTP- als auch für IMAP-Dienste bei example.com wiederverwendet werden); während andere Namen eingeschränkt sind, weil sie nur für einen Diensttyp verwendet werden können (z. B. ein Zertifikat, das nur für die Verwendung für IMAP-Dienste bestimmt ist). Diese Dimension ist am wichtigsten für die Ausstellung von Zertifikaten.

Wir können daher die Identifikatortypen von Interesse wie folgt kategorisieren:

CN-ID ist Direkt und Uneingeschränkt.
DNS-ID ist Direkt und Uneingeschränkt.
SRV-ID ist Direkt oder (häufiger) Indirekt, und Eingeschränkt.
URI-ID ist Direkt und Eingeschränkt.

Diese Kategorisierung ist in der folgenden Tabelle zusammengefasst.

+-----------+-----------+---------------+
|           |  Direkt   |  Eingeschränkt|
|           |           |  (Restricted) |
+-----------+-----------+---------------+
|  CN-ID    |  Ja       |  Nein         |
+-----------+-----------+---------------+
|  DNS-ID   |  Ja       |  Nein         |
+-----------+-----------+---------------+
|  SRV-ID   | Entweder  |  Ja           |
|           | oder      |               |
+-----------+-----------+---------------+
|  URI-ID   |  Ja       |  Ja           |
+-----------+-----------+---------------+

Es ist wichtig, diese Unterscheidungen im Auge zu behalten, wenn Software implementiert, Dienste bereitgestellt und Zertifikate ausgestellt werden, um eine sichere Authentifizierung auf PKIX-Basis zu gewährleisten. Insbesondere werden die Best Practices für Anwendungsserver-Implementierungen, Anwendungsclient-Implementierungen, Anwendungsdienstanbieter und Zertifizierungsstellen etwas unterschiedlich sein. Idealerweise wird eine Protokollspezifikation, die dieses Dokument referenziert, festlegen, welche Identifikatoren von Servern und Clients zwingend implementiert werden müssen, welche Identifikatoren von Zertifikatsausstellern unterstützt werden sollten und welche Identifikatoren von Anwendungsdienstanbietern angefordert werden sollten. Diese Anforderungen werden von Anwendung zu Anwendung variieren, daher können keine universellen Regeln kategorisch festgelegt werden (z. B., dass alle Softwareimplementierungen, alle Dienstanbieter und alle Zertifizierungsstellen für alle Anwendungsprotokolle DNS-IDs als Basis für die Interoperabilität verwenden oder unterstützen müssen).

Es ist jedoch wünschenswert, dass jedes Anwendungsprotokoll zumindest eine Basis definiert, die für die gesamte Gemeinschaft von Softwareentwicklern, Anwendungsdienstanbietern und CAs gilt, die diese Technologie aktiv nutzen oder unterstützen (eine solche Gemeinschaft, das CA/Browser Forum, hat bereits eine solche Basis für "Extended Validation Certificates" in [EV-CERTS] kodifiziert).

2.2. DNS-Domänennamen (DNS Domain Names)

Für die Zwecke dieser Spezifikation ist der Name eines Anwendungsdienstes (oder basiert auf) einem DNS-Domänennamen, der einem der folgenden Formate entspricht:

Ein "traditioneller Domänenname", d. h. ein vollqualifizierter DNS-Domänenname oder "FQDN" ([DNS-CONCEPTS]), der nur Labels besitzt, die "LDH-Labels" sind, wie in [IDNA-DEFS] beschrieben. Informell sind solche Labels auf Buchstaben, Ziffern und den Bindestrich [US-ASCII] beschränkt, wobei der Bindestrich an der ersten Zeichenposition verboten ist. Zusätzliche Qualifikationen gelten (siehe die oben zitierten Spezifikationen für Details), sind aber für diese Spezifikation nicht relevant.
Ein "internationalisierter Domänenname", d. h. ein DNS-Domänenname, der dem allgemeinen Format eines Domänennamens entspricht (informell, punktgetrennte alphanumerische Labels mit Bindestrichen), aber mindestens ein Label mit Unicode-Codepunkten außerhalb des traditionellen US-ASCII-Bereichs enthält, die angemessen codiert sind. Das heißt, er enthält mindestens ein U-Label oder A-Label, kann aber ansonsten jede Kombination von NR-LDH-Labels, A-Labels oder U-Labels enthalten, wie in [IDNA-DEFS] und den zugehörigen Dokumenten beschrieben.

2.3. Subjekt-Benennung in PKIX-Zertifikaten (Subject Naming in PKIX Certificates)

Theoretisch verwendet die Internet-Public-Key-Infrastruktur unter Verwendung von X.509 [PKIX] das globale Verzeichnisdienstmodell, das in [X.500] und [X.501] definiert ist. In diesem Modell werden Informationen in einer Directory Information Base (DIB) gehalten, und Einträge darin sind in einer Hierarchie namens Directory Information Tree (DIT) organisiert. Objekt- oder Alias-Einträge in dieser Hierarchie bestehen aus einer Sammlung von Attributen (jedes mit einem definierten Typ und einem oder mehreren Werten) und werden eindeutig durch einen einzigen Distinguished Name (DN) identifiziert. Der DN eines Eintrags wird konstruiert, indem der Relative Distinguished Name seines übergeordneten Eintrags im Baum (bis zur Wurzel des DIT) und ein oder mehrere speziell bezeichnete Attribute des Eintrags selbst kombiniert werden (die zusammen den Relative Distinguished Name oder RDN des Eintrags bilden - so genannt, weil er relativ zum Distinguished Name seines übergeordneten Eintrags im Baum ist). Der Eintrag, der der Wurzel am nächsten ist, wird manchmal als der "signifikanteste" Eintrag bezeichnet, und der Eintrag, der am weitesten von der Wurzel entfernt ist, wird manchmal als der "am wenigsten signifikante" Eintrag bezeichnet. Der RDN ist eine Menge (d. h. eine ungeordnete Sammlung) von Attributtyp-und-Wert-Paaren (siehe auch [LDAP-DN]), von denen jedes ein bestimmtes Attribut bezüglich des Eintrags behauptet.

In der Praxis leihen sich die in [X.509] und [PKIX] verwendeten Zertifikate Schlüsselkonzepte von X.500 und X.501 aus, um Entitäten zu identifizieren (wie DN und RDN), obwohl solche Zertifikate nicht unbedingt Teil einer globalen Directory Information Base sind. Insbesondere ist das Subject-Feld eines PKIX-Zertifikats ein Name vom X.501-Typ, der "die Entität identifiziert, die mit dem im öffentlichen Schlüsselfeld des Subjekts gespeicherten öffentlichen Schlüssel verbunden ist" (siehe Abschnitt 4.1.2.6 von [PKIX]). Es ist jedoch vollkommen akzeptabel, dass das Subject-Feld leer ist, solange das Zertifikat eine subject alternative name Erweiterung ("subjectAltName") enthält und diese Erweiterung mindestens einen subjectAltName-Eintrag enthält, da die subjectAltName-Erweiterung das Binden verschiedener Identitäten an das Subjekt ermöglicht (siehe Abschnitt 4.2.1.6 von [PKIX]). Die subjectAltName-Erweiterung ist selbst eine Liste von typisierten Einträgen, wobei jeder Typ eine andere Art von Identifikator ist.

Für unsere Zwecke kann ein Anwendungsdienst durch einen Namen im Subject-Feld (d. h. eine CN-ID) und/oder durch einen der folgenden Identifikatortypen in einem subjectAltName-Eintrag identifiziert werden:

DNS-ID
SRV-ID
URI-ID

Bestehende Zertifikate verwenden oft eine CN-ID im Subject-Feld, um einen vollqualifizierten DNS-Domänennamen darzustellen. Betrachten Sie beispielsweise die folgenden drei Subjekt-Namen, in denen das Attribut vom Typ Common Name eine Zeichenfolge enthält, die dem Format eines vollqualifizierten DNS-Domänennamens entspricht ("im.example.org", "mail.example.net" und "www.example.com" respektive):

CN=im.example.org,O=Example Org,C=GB

C=CA,O=Example Internetworking,CN=mail.example.net

O=Examples-R-Us,CN=www.example.com,C=US

Da der Common Name jedoch nicht stark typisiert ist, ist es möglich, dass ein Common Name eine benutzerfreundliche Zeichenfolge anstelle einer Zeichenfolge enthält, die dem Format eines vollqualifizierten DNS-Domänennamens entspricht (oft besitzt ein solches Zertifikat mit einem einzigen Common Name auch mindestens einen subjectAltName-Eintrag, der einen vollqualifizierten DNS-Domänennamen enthält):

CN=A Free Chat Service,O=Example Org,C=GB

Alternativ kann das Subjekt eines Zertifikats sowohl eine CN-ID als auch ein weiteres Common Name-Attribut enthalten, das eine benutzerfreundliche Zeichenfolge enthält:

CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB

Im Allgemeinen empfiehlt und bevorzugt diese Spezifikation die Verwendung von subjectAltName-Einträgen (DNS-ID, SRV-ID, URI-ID usw.) gegenüber der Verwendung des Subject-Feldes (CN-ID), wo immer dies möglich ist, wie in den folgenden Abschnitten ausführlicher erläutert. Eine Spezifikation, die diese Spezifikation wiederverwendet, KANN jedoch legitimerweise die fortgesetzte Unterstützung des CN-ID-Identifikatortyps empfehlen, wenn es gute Gründe dafür gibt, wie z. B. die Abwärtskompatibilität mit installierter Infrastruktur (siehe z. B. [EV-CERTS]).

2.3.1. Implementierungshinweise (Implementation Notes)

Verwirrung kann aus den unterschiedlichen Renderings oder Codierungen der in einem Zertifikat enthaltenen hierarchischen Informationen entstehen.

Ein Zertifikat ist ein binäres Objekt, das unter Verwendung der in [X.690] spezifizierten Distinguished Encoding Rules (DER) codiert ist. Einige Implementierungen generieren jedoch ein anzeigbares (d. h. druckbares) Rendering des Ausstellers des Zertifikats, des Subject-Feldes und der subjectAltName-Erweiterung, und diese Renderings konvertieren die in DER codierte Sequenz in eine "String-Repräsentation" vor der Anzeige. Da das Subject-Feld des Zertifikats (das vom Typ Name [X.509] ist, gleich wie der Distinguished Name (DN) [X.501]) eine geordnete Sequenz ist, wird die Reihenfolge in der String-Repräsentation des Subjekts im Allgemeinen beibehalten, obwohl sich die beiden häufigsten String-Repräsentationen von Subjekten (und DNs) in ihrer Annahme einer Links-nach-Rechts- versus einer Rechts-nach-Links-Reihenfolge unterscheiden. Relative Distinguished Names (RDNs) sind jedoch ungeordnete Mengen von Attributtyp-und-Wert-Paaren, so dass die String-Repräsentation eines RDN von der kanonischen DER-Codierung abweichen kann (und die Reihenfolge der Attributtyp-und-Wert-Paare je nach String-Repräsentation oder Anzeigereihenfolge, die von verschiedenen Implementierungen bereitgestellt wird, variieren kann). Darüber hinaus verwenden verschiedene Spezifikationen eine Terminologie, die sich implizit auf eine Informationshierarchie bezieht (die tatsächlich existieren kann oder nicht), um auf die Reihenfolge der RDNs in einem DN oder im Subject-Feld eines Zertifikats zu verweisen; z. B. "am spezifischsten" (most specific) vs. "am wenigsten spezifisch" (least specific), "am weitesten links" (left-most) vs. "am weitesten rechts" (right-most), "erstes" (first) vs. "letztes" (last) oder "am signifikantesten" (most significant) vs. "am wenigsten signifikant" (least significant) (siehe z. B. [LDAP-DN]).

Um Verwirrung zu verringern, vermeidet diese Spezifikation die Verwendung solcher Begriffe und verwendet stattdessen die in Abschnitt 1.8 bereitgestellte Terminologie. Insbesondere anstatt den Begriff aus [HTTP-TLS] "das (spezifischste) Common Name-Feld im Subject-Feld" zu verwenden, wird eine CN-ID als ein Relative Distinguished Name (RDN) innerhalb des Subjekts des Zertifikats deklariert, der genau ein Attributtyp-und-Wert-Paar vom Typ Common Name enthält (was die Möglichkeit ausschließt, dass ein RDN mehrere AVAs (Attribute Value Assertions) vom Typ CN enthält, von denen einer als "am spezifischsten" angesehen werden könnte).

Schließlich, während einige argumentieren, dass die Reihenfolge der RDNs im Subject-Feld theoretisch eine Bedeutung hat, wird diese Regel in der Praxis im Allgemeinen nicht beachtet. Ein AVA vom Typ CN wird als gültig angesehen, unabhängig von seiner Position im Subject-Feld.