4. Darstellung der Server-Identität (Representing Server Identity)

Dieser Abschnitt bietet Regeln und Richtlinien für Zertifikatsaussteller.

4.1. Regeln (Rules)

Wenn eine Zertifizierungsstelle ein Zertifikat basierend auf dem vollqualifizierten DNS-Domänennamen ausstellt, unter dem der Anwendungsdienstanbieter den/die relevanten Dienst(e) anbieten wird, gelten die folgenden Regeln für die Darstellung von Anwendungsdienst-Identitäten. Der Leser sollte beachten, dass einige dieser Regeln kumulativ sind und auf wichtige Weise interagieren können, wie später in diesem Dokument erläutert wird.

Das Zertifikat SOLLTE (SHOULD) eine "DNS-ID" als Basis für die Interoperabilität enthalten, wenn möglich.
Wenn der Dienst, der das Zertifikat verwendet, eine Technologie einsetzt, für die die relevante(n) Spezifikation(en) vorschreiben, dass das Zertifikat einen Identifikator vom Typ SRV-ID enthalten SOLL (OUGHT TO) (z. B. trifft dies auf [XMPP] zu), dann SOLLTE (SHOULD) das Zertifikat eine SRV-ID enthalten.
Wenn der Dienst, der das Zertifikat verwendet, eine Technologie einsetzt, für die die relevante(n) Spezifikation(en) vorschreiben, dass das Zertifikat einen Identifikator vom Typ URI-ID enthalten SOLL (OUGHT TO) (z. B. trifft dies auf [SIP] gemäß [SIP-CERTS] zu, aber nicht auf [HTTP], da [HTTP-TLS] die Verwendung von URI-IDs durch HTTP-Dienste nicht erwähnt), dann SOLLTE (SHOULD) das Zertifikat eine URI-ID enthalten. Das Schema SOLL (SHALL) dasjenige sein, das mit dem Anwendungsdienst-Typ verbunden ist, und die "Host"-Komponente (oder deren Äquivalent) SOLL (SHALL) der vollqualifizierte DNS-Domänenname des Dienstes sein. Eine Spezifikation, die diese Spezifikation wiederverwendet, MUSS (MUST) angeben, welche URI-Schemata in URI-IDs zulässig sind, die in PKIX-Zertifikaten für dieses Anwendungsprotokoll enthalten sind (z. B. "sip", aber nicht "sips" oder "tel" für SIP wie in [SIP-SIPS] beschrieben, oder möglicherweise http und https für HTTP, wie in einer zukünftigen Spezifikation beschrieben werden könnte).
Das Zertifikat KANN (MAY) andere anwendungsspezifische Identifikatortypen enthalten, die vor der Veröffentlichung von [SRVNAME] definiert wurden (wie z. B. XmppAddr für [XMPP]) oder für die es keinen Dienstnamen oder kein URI-Schema gibt; solche anwendungsspezifischen Identifikatoren gelten jedoch nicht für alle Anwendungstechnologien und liegen daher außerhalb des Umfangs dieser Spezifikation.
Obwohl viele installierte Clients immer noch das Subject-Feld auf eine CN-ID überprüfen, wird Zertifizierungsstellen empfohlen, dazu überzugehen, den vollqualifizierten DNS-Domänennamen des Servers nicht in eine CN-ID aufzunehmen. Daher SOLLTE (SHOULD NOT) das Zertifikat keine CN-ID enthalten, es sei denn, die Zertifizierungsstelle stellt das Zertifikat gemäß einer Spezifikation aus, die diese Spezifikation wiederverwendet und explizit die fortgesetzte Unterstützung für den CN-ID-Identifikatortyp im Kontext einer gegebenen Anwendungstechnologie empfiehlt.
Das Zertifikat KANN (MAY) mehrere DNS-IDs, SRV-IDs oder URI-IDs enthalten, aber SOLLTE NICHT (SHOULD NOT) mehrere CN-IDs enthalten, wie später in Abschnitt 7.4 erläutert.
Obwohl die Verwendung des Wildcard-Zeichens '' in DNS-Domänennamen erlaubt ist, SOLLTE es NICHT (SHOULD NOT) in den DNS-Domänennamen-Teil eines präsentierten Identifikators aufgenommen werden, weder als vollständiges linkes Label (z. B. ".example.com", wie in der Beschreibung von Labels und Domänennamen in [DNS-CONCEPTS]) noch als Fragment davon (z. B. oo.example.com, fo.example.com oder fo*.example.com), es sei denn, eine Spezifikation, die diese Spezifikation wiederverwendet, erlaubt explizit die fortgesetzte Unterstützung des Wildcard-Zeichens. Eine detailliertere Diskussion sogenannter "Wildcard-Zertifikate" findet sich in Abschnitt 7.2.

4.2. Beispiele (Examples)

Betrachten Sie eine einfache Website unter "www.example.com", die nicht über DNS SRV-Lookups auffindbar ist. Da HTTP die Verwendung von URIs in Server-Zertifikaten nicht spezifiziert, könnte ein Zertifikat für den Dienst nur eine DNS-ID von "www.example.com" enthalten. Es könnte auch eine CN-ID von "www.example.com" für die Abwärtskompatibilität mit installierter Infrastruktur enthalten.

Betrachten Sie einen IMAP-zugänglichen E-Mail-Server, der unter "mail.example.net" gehostet wird, E-Mail-Adressen der Form "[email protected]" bedient und über einen DNS SRV-Lookup des Anwendungsdienstnamens "example.net" auffindbar ist. Ein Zertifikat für den Dienst könnte SRV-IDs von "_imap.example.net" und "_imaps.example.net" (siehe [EMAIL-SRV]) sowie DNS-IDs von "example.net" und "mail.example.net" enthalten. Es könnte auch CN-IDs von "example.net" und "mail.example.net" für die Abwärtskompatibilität mit installierter Infrastruktur enthalten.

Betrachten Sie einen SIP-zugänglichen Voice-over-IP (VoIP)-Server, der unter "voice.example.edu" gehostet wird, SIP-Adressen der Form "[email protected]" bedient und durch einen URI von <sip:voice.example.edu> identifiziert wird. Ein Zertifikat für den Dienst würde eine URI-ID von "sip:voice.example.edu" (siehe [SIP-CERTS]) und eine DNS-ID von "voice.example.edu" enthalten. Es könnte auch eine CN-ID von "voice.example.edu" für die Abwärtskompatibilität mit installierter Infrastruktur enthalten.

Betrachten Sie einen XMPP-konformen Instant Messaging (IM)-Server, der unter "im.example.org" gehostet wird, IM-Adressen der Form "[email protected]" bedient und über einen DNS SRV-Lookup auf der Domäne "im.example.org" auffindbar ist. Ein Zertifikat für den Dienst könnte SRV-IDs von "_xmpp-client.im.example.org" und "_xmpp-server.im.example.org" (siehe [XMPP]), eine DNS-ID von "im.example.org" und eine XMPP-spezifische "XmppAddr" (siehe [XMPP]) von "im.example.org" enthalten. Es könnte auch eine CN-ID von "im.example.org" für die Abwärtskompatibilität mit installierter Infrastruktur enthalten.