6. Überprüfung der Dienst-Identität (Verifying Service Identity)

Dieser Abschnitt bietet Regeln und Richtlinien für Implementierer von Anwendungsclient-Software bezüglich der Algorithmen zur Überprüfung der Anwendungsdienst-Identität.

6.1. Übersicht (Overview)

Auf einer hohen Ebene überprüft der Client die Identität des Anwendungsdienstes, indem er die folgenden Operationen durchführt (diese Operationen werden in den folgenden Unterabschnitten dieses Dokuments definiert):

Der Client erstellt eine Liste akzeptabler Referenz-Identifikatoren basierend auf der Quelldomäne (source domain) und optional dem Diensttyp, mit dem sich der Client verbindet.
Der Server präsentiert seine Identifikatoren in Form eines PKIX-Zertifikats.
Der Client überprüft jeden seiner Referenz-Identifikatoren gegen die präsentierten Identifikatoren, um eine Übereinstimmung zu finden.
Bei der Überprüfung eines Referenz-Identifikators gegen einen präsentierten Identifikator gleicht der Client die Quelldomäne der Identifikatoren und optional ihren Anwendungsdienst-Typ ab.

Natürlich muss der Client neben der Überprüfung der Identifikatoren möglicherweise weitere Überprüfungen durchführen, um sicherzustellen, dass der Server berechtigt ist, den angeforderten Dienst bereitzustellen; solche Überprüfungen sind jedoch keine Angelegenheit der Überprüfung der in einem Zertifikat präsentierten Anwendungsdienst-Identität, und die Methoden hierfür (z. B. Konsultation lokaler Richtlinieninformationen) liegen daher außerhalb des Umfangs dieses Dokuments.

6.2. Erstellung einer Liste von Referenz-Identifikatoren (Constructing a List of Reference Identifiers)

6.2.1. Regeln (Rules)

Der Client MUSS (MUST) eine Liste akzeptabler Referenz-Identifikatoren erstellen, und er MUSS (MUST) dies unabhängig von den vom Dienst präsentierten Identifikatoren tun.

Die Eingaben, die der Client zur Erstellung seiner Liste von Referenz-Identifikatoren verwendet, können ein URI sein, den ein Benutzer in eine Schnittstelle eingibt (z. B. eine HTTPS-URL für eine Website), konfigurierte Kontoinformationen (z. B. der Domänenname eines bestimmten Hosts oder URI, der verwendet wird, um Informationen abzurufen oder eine Verbindung zu einem Netzwerk herzustellen, der sich von dem DNS-Domänennamen-Teil eines Benutzernamens unterscheiden kann), ein Hyperlink in einer Webseite, der einen Browser dazu veranlasst, ein Medienobjekt oder Skript abzurufen, oder andere Kombinationen von Informationen, die eine Quelldomäne und einen Anwendungsdienst-Typ ergeben können.

Der Client muss möglicherweise die Quelldomäne und den Anwendungsdienst-Typ aus der erhaltenen Eingabe extrahieren. Die extrahierten Daten MÜSSEN (MUST) jedoch nur Informationen enthalten, die sicher aus der Eingabe geparst werden können (z. B. ein vollqualifizierter DNS-Domänenname, der aus der "Host"-Komponente (oder deren Äquivalent) eines URI geparst wird, oder ein Anwendungsdienst-Typ, der aus dem Schema eines URI abgeleitet wird) oder Informationen, die auf eine Weise abgeleitet wurden, die nicht anfällig für Korruption durch Netzwerkangreifer ist (z. B. Daten, die aus einer explizit per Client- oder Systemkonfiguration festgelegten Delegationsdomäne extrahiert wurden, Daten, die über [DNSSEC] aufgelöst wurden, oder Daten, die von einem Drittanbieter-Domänen-Mapping-Dienst stammen, dem ein menschlicher Benutzer explizit vertraut hat und mit dem der Client über eine Verbindung oder Assoziierung kommuniziert, die gegenseitige Authentifizierung und Integritätsprüfung bietet). Diese Überlegungen gelten nur für die Extraktion der Quelldomäne aus der Eingabe; natürlich kann der Client, wenn die Eingabe selbst ungültig oder beschädigt ist (z. B. wenn ein Benutzer auf einen Link klickt, der von einer böswilligen Entität in einem Phishing-Angriff bereitgestellt wurde), am Ende mit einem unbeabsichtigten Anwendungsdienst kommunizieren.

Beispiel: Gegeben den Eingabe-URI <sips:[email protected]>, würde ein Client den Anwendungsdienst-Typ "sip" aus dem "Schema" ableiten und den Domänennamen "example.net" aus der "Host"-Komponente (oder deren Äquivalent) parsen.

Jeder Referenz-Identifikator in der Liste SOLLTE (SHOULD) auf der Quelldomäne basieren und SOLLTE NICHT (SHOULD NOT) auf einer abgeleiteten Domäne basieren (z. B. ein Hostname oder Domänenname, der als Ergebnis einer DNS-Auflösung der Quelldomäne entdeckt wurde). Diese Regel ist wichtig, da nur eine Übereinstimmung zwischen der Benutzereingabe und dem präsentierten Identifikator dem Client eine gewisse Sicherheit geben kann, dass das Zertifikat legitim verwendet werden kann, um die Kommunikation zwischen dem Client und dem Server zu sichern. Es gibt nur einen Fall, in dem ein interaktiver Client die Empfehlung dieser Regel außer Kraft setzen und mit einem anderen Domänennamen als der Quelldomäne kommunizieren kann: wenn ein menschlicher Benutzer das Zertifikat des Anwendungsdienstes an einen alternativen Domänennamen "angeheftet" (pinned) hat, wie später in den Abschnitten 6.6.4 und 7.1 erläutert. In diesem Fall kann die Eingabe, die der Client zur Erstellung seiner Liste von Referenz-Identifikatoren verwendet, mehr als einen vollqualifizierten DNS-Domänennamen enthalten: (a) die Quelldomäne und (b) die alternative Domäne, die im angehefteten Zertifikat enthalten ist.

Unter Verwendung der Kombination aus einem oder mehreren vollqualifizierten DNS-Domänennamen und einem Anwendungsdienst-Typ erstellt der Client eine Liste von Referenz-Identifikatoren gemäß den folgenden Regeln:

Die Liste SOLLTE (SHOULD) eine DNS-ID enthalten, die direkt aus (a) dem vollqualifizierten DNS-Domänennamen, der in der Eingabe enthalten ist oder sicher daraus abgeleitet wurde (d. h. der Quelldomäne), oder (b) dem vollqualifizierten DNS-Domänennamen, der explizit über die Benutzerkonfiguration mit der Quelldomäne verbunden ist (d. h. einer abgeleiteten Domäne), aufgebaut ist.
Wenn ein Server für den Anwendungsdienst-Typ typischerweise über DNS SRV-Datensätze lokalisiert wird, SOLLTE (SHOULD) die Liste eine SRV-ID enthalten.
Wenn ein Server für den Anwendungsdienst-Typ typischerweise zu Sicherheitszwecken mit einem URI verknüpft ist (d. h. wenn ein formales Protokolldokument die Verwendung von URIs in Server-Zertifikaten spezifiziert), SOLLTE (SHOULD) die Liste eine URI-ID enthalten.
Die Liste KANN (MAY) eine CN-ID enthalten, hauptsächlich für die Abwärtskompatibilität mit installierter Infrastruktur.

Welche Identifikatortypen ein Client in seine Liste von Referenz-Identifikatoren aufnimmt, ist eine Frage der lokalen Richtlinie. Beispielsweise kann es eine Bereitstellungsumgebung geben, in der Clients, die für die Verbindung mit einem bestimmten Diensttyp (sagen wir, nur ein IM-Dienst) gebaut sind, so konfiguriert sind, dass sie nur Zertifikate als gültig akzeptieren, die eine SRV-ID für diesen Anwendungsdienst-Typ enthalten; in diesem Fall würde der Client nur eine SRV-ID für den entsprechenden Anwendungsdienst-Typ in seine Liste von Referenz-Identifikatoren aufnehmen (und nicht z. B. eine DNS-ID). Im Gegensatz dazu könnte ein nachsichtigerer Client (selbst einer, der nur für die Verbindung mit einem bestimmten Diensttyp gebaut ist) sowohl eine SRV-ID als auch eine DNS-ID in seine Liste von Referenz-Identifikatoren aufnehmen.

Implementierungshinweis: Aufgrund der Verbreitung von Zertifikaten, die CN-IDs enthalten, ist es sehr wahrscheinlich, dass Anwendungssoftware-Implementierer CN-IDs auf absehbare Zeit unterstützen müssen. Implementierer werden aufgefordert, den Stand der Technik der Zertifikatsausstellungsrichtlinien zu überwachen und die Unterstützung für CN-IDs in Zukunft nach Möglichkeit einzustellen.

Implementierungshinweis: Ein Client muss die oben genannten Identifikatoren nicht in der tatsächlichen Form erstellen, die in einem Zertifikat gefunden wird (z. B. als ASN.1-Typen); es reicht aus, funktionale Äquivalente solcher Identifikatoren für Abgleichzwecke zu erstellen.

Sicherheitswarnung: Ein Client DARF NICHT (MUST NOT) einen Referenz-Identifikator erstellen, der einem Relative Distinguished Name (RDN) entspricht, der kein Typ Common Name ist, und ein Client DARF NICHT (MUST NOT) einen anderen RDN als die vom Typ Common Name in einem präsentierten Identifikator überprüfen.

6.2.2. Beispiele (Examples)

Ein Webbrowser, der sich über HTTPS mit einer Website "www.example.com" verbindet, könnte zwei Referenz-Identifikatoren haben: eine DNS-ID von "www.example.com" und als Fallback eine CN-ID von "www.example.com".

Ein E-Mail-User-Agent, der sich über IMAPS mit einem E-Mail-Dienst "example.net" (der auf "mail.example.net" auflöst) verbindet, könnte fünf Referenz-Identifikatoren haben: eine SRV-ID von "_imaps.example.net" (siehe [EMAIL-SRV]), DNS-IDs von "example.net" und "mail.example.net", und als Fallbacks CN-IDs von "example.net" und "mail.example.net". (Ein älterer User-Agent, der [EMAIL-SRV] nicht unterstützt, könnte explizit konfiguriert sein, um sich mit "mail.example.net" zu verbinden, während ein SRV-fähiger User-Agent "example.net" aus einer E-Mail-Adresse der Form "[email protected]" ableiten würde, aber auch "mail.example.net" als den DNS-Domänennamen-Teil eines Referenz-Identifikators für den Dienst akzeptieren könnte.)

Ein Voice-over-IP (VoIP)-User-Agent, der sich über SIP mit einem Sprachdienst "voice.example.edu" verbindet, könnte nur einen Referenz-Identifikator haben: eine URI-ID von "sip:voice.example.edu" (siehe [SIP-CERTS]).

Ein Instant Messaging (IM)-Client, der sich über XMPP mit einem IM-Dienst "im.example.org" verbindet, könnte drei Referenz-Identifikatoren haben: eine SRV-ID von "_xmpp-client.im.example.org" (siehe [XMPP]), eine DNS-ID von "im.example.org" und eine XMPP-spezifische "XmppAddr" (siehe [XMPP]) von "im.example.org".

6.3. Vorbereitung auf den Abgleich (Preparing to Seek a Match)

Sobald der Client seine Liste von Referenz-Identifikatoren erstellt hat und die Identifikatoren des Servers in Form eines PKIX-Zertifikats erhalten hat, überprüft der Client seine Referenz-Identifikatoren gegen die präsentierten Identifikatoren, um eine Übereinstimmung zu finden. Die Suche schlägt fehl, wenn der Client seine Liste von Referenz-Identifikatoren erschöpft, ohne eine Übereinstimmung zu finden. Die Suche ist erfolgreich, wenn einer der präsentierten Identifikatoren mit einem der Referenz-Identifikatoren übereinstimmt, woraufhin der Client die Suche beenden SOLLTE (SHOULD).

Implementierungshinweis: Ein Client könnte so konfiguriert sein, dass er mehrere Suchen durchführt, d. h. mehr als einen Referenz-Identifikator abgleicht. Obwohl diese Spezifikation ein solches Verhalten nicht verbietet, sind die Regeln für den Abgleich mehrerer Referenz-Identifikatoren eine Angelegenheit für zukünftige Implementierungen oder Spezifikationen.

Sicherheitswarnung: Wenn ein präsentierter Identifikator eine DNS-ID, SRV-ID, URI-ID oder einen vom Client unterstützten anwendungsspezifischen Identifikatortyp enthält, DARF der Client NICHT (MUST NOT) versuchen, eine Übereinstimmung mit einem Referenz-Identifikator vom Typ CN-ID zu finden.

Vor der Anwendung der in den folgenden Abschnitten bereitgestellten Vergleichsregeln muss der Client möglicherweise einen Referenz-Identifikator in einen DNS-Domänennamen-Teil und einen Anwendungsdienst-Typ-Teil aufteilen, wie folgt:

Ein Referenz-Identifikator vom Typ DNS-ID enthält keinen Anwendungsdienst-Typ-Teil und kann direkt als DNS-Domänenname für den Vergleich verwendet werden. Beispielsweise führt eine DNS-ID von "www.example.com" zu einem DNS-Domänennamen-Teil von "www.example.com".
Ein Referenz-Identifikator vom Typ CN-ID enthält ebenfalls keinen Anwendungsdienst-Typ-Teil und kann direkt als DNS-Domänenname für den Vergleich verwendet werden. Wie angemerkt, schreibt dieses Dokument vor, dass eine CN-ID immer eine Zeichenfolge enthält, die dem Format eines DNS-Domänennamens entspricht (wodurch eine CN-ID von einem Common Name unterschieden wird, der einen freundlichen Namen enthält).
Bei einem Referenz-Identifikator vom Typ SRV-ID ist der DNS-Domänennamen-Teil der Name und der Anwendungsdienst-Typ-Teil der Service. Beispielsweise teilt sich eine SRV-ID von "_imaps.example.net" in einen DNS-Domänennamen-Teil von "example.net" und einen Anwendungsdienst-Typ-Teil von "imaps" auf (der dem IMAP-Anwendungsprotokoll entspricht, wie in [EMAIL-SRV] erläutert).
Bei einem Referenz-Identifikator vom Typ URI-ID ist der DNS-Domänennamen-Teil der "reg-name"-Teil der "Host"-Komponente (oder deren Äquivalent) und der Anwendungsdienst-Typ-Teil ist der Anwendungsdienst-Typ, der mit dem Schema-Namen verbunden ist, der der [ABNF]-Regel "scheme" von [URI] entspricht (minus dem Trennzeichen ':'). Wie angemerkt, schreibt dieses Dokument vor, dass eine URI-ID immer einen URI enthält, der eine "Host"-Komponente (oder deren Äquivalent) enthält, die einen "reg-name" enthält. (Der Abgleich nur mit der "reg-name"-Regel von [URI] beschränkt die Überprüfung auf DNS-Domänennamen und ermöglicht die Unterscheidung zwischen einer URI-ID und einem uniformResourceIdentifier-Eintrag, der eine IP-Adresse oder einen einfachen Hostnamen oder überhaupt keine "Host"-Komponente enthält). Beachten Sie außerdem, dass die Extraktion des "reg-name" möglicherweise eine URI-Normalisierung erfordert (wie in [URI] erläutert). Beispielsweise teilt sich eine URI-ID von "sip:voice.example.edu" in einen DNS-Domänennamen-Teil von "voice.example.edu" und einen Anwendungsdienst-Typ von "sip" auf (der mit dem SIP-Anwendungsprotokoll verbunden ist, wie in [SIP-CERTS] erläutert).

Die folgenden Abschnitte bieten detaillierte Vergleichsregeln für den Abgleich des DNS-Domänennamen-Teils und des Anwendungsdienst-Typ-Teils der Referenz-Identifikatoren.

6.4. Abgleich des DNS-Domänennamen-Teils (Matching the DNS Domain Name Portion)

Der Client MUSS (MUST) den DNS-Domänennamen-Teil eines Referenz-Identifikators gemäß den folgenden Regeln abgleichen und SOLLTE (SHOULD) gleichzeitig den Anwendungsdienst-Typ überprüfen, wie in Abschnitt 6.5 beschrieben. Die Regeln unterscheiden sich je nachdem, ob es sich bei der zu überprüfenden Domäne um einen "traditionellen Domänennamen" oder einen "internationalisierten Domänennamen" handelt (wie in Abschnitt 2.2 definiert). Darüber hinaus definieren wir zusätzliche Regeln für sogenannte "Wildcard-Zertifikate", um den Bedürfnissen von Clients gerecht zu werden, die präsentierte Identifikatoren unterstützen, die das Wildcard-Zeichen '*' enthalten, und wir legen die Umstände fest, unter denen es akzeptabel ist, den Identifikatortyp "CN-ID" als letzten Ausweg zu überprüfen.

6.4.1. Überprüfung traditioneller Domänennamen (Checking of Traditional Domain Names)

Wenn der DNS-Domänennamen-Teil eines Referenz-Identifikators ein "traditioneller Domänenname" ist, wird der Abgleich des Referenz-Identifikators mit dem präsentierten Identifikator durchgeführt, indem der Satz von Domänennamen-Labels unter Verwendung eines ASCII-Vergleichs ohne Berücksichtigung der Groß-/Kleinschreibung verglichen wird, wie durch [DNS-CASE] klargestellt (z. B. wäre "WWW.Example.Com" für den Vergleich in Kleinbuchstaben "www.example.com"). Jedes Label MUSS (MUST) übereinstimmen, damit es als Übereinstimmung gilt, sofern es nicht durch die Regeln zur Überprüfung von Wildcard-Labels ergänzt wird (Abschnitt 6.4.3).

6.4.2. Überprüfung internationalisierter Domänennamen (Checking of Internationalized Domain Names)

Wenn der DNS-Domänennamen-Teil eines Referenz-Identifikators ein internationalisierter Domänenname ist, MUSS (MUST) die Implementierung jedes U-Label [IDNA-DEFS] im Domänennamen in ein A-Label konvertieren, bevor der Domänenname überprüft wird. Gemäß [IDNA-PROTO] MÜSSEN (MUST) A-Labels als ASCII ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden. Jedes Label MUSS (MUST) übereinstimmen, damit es als Übereinstimmung gilt, sofern es nicht durch die Regeln zur Überprüfung von Wildcard-Labels ergänzt wird (Abschnitt 6.4.3; siehe jedoch auch Abschnitt 7.2 bezüglich Wildcards in internationalisierten Domänennamen).

6.4.3. Überprüfung von Wildcard-Zertifikaten (Checking of Wildcard Certificates)

Ein Client, der die Regeln dieser Spezifikation anwendet, KANN (MAY) einen Referenz-Identifikator mit einem präsentierten Identifikator abgleichen, dessen DNS-Domänennamen-Teil das Wildcard-Zeichen '*' als Teil oder Ganzes eines Labels enthält (gemäß der Beschreibung von Labels und Domänennamen in [DNS-CONCEPTS]).

Für Informationen über die Sicherheitsmerkmale von Wildcard-Zertifikaten siehe Abschnitt 7.2.

Wenn ein Client einen Referenz-Identifikator mit einem präsentierten Identifikator abgleicht, dessen DNS-Domänennamen-Teil das Wildcard-Zeichen '*' enthält, gelten die folgenden Regeln:

Der Client SOLLTE NICHT (SHOULD NOT) versuchen, einen präsentierten Identifikator abzugleichen, in dem das Wildcard-Zeichen ein anderes Label als das linke Label darstellt (z. B. nicht bar.*.example.net abgleichen).
Wenn das Wildcard-Zeichen das einzige Zeichen des linken Labels des präsentierten Identifikators ist, SOLLTE der Client NICHT (SHOULD NOT) mit etwas anderem als dem linken Label des Referenz-Identifikators übereinstimmen (z. B. würde *.example.com mit foo.example.com übereinstimmen, aber nicht mit bar.foo.example.com oder example.com).
Der Client KANN (MAY) mit einem präsentierten Identifikator übereinstimmen, in dem das Wildcard-Zeichen nicht das einzige Zeichen des Labels ist (z. B. würden baz*.example.net und baz.example.net und bz.example.net als übereinstimmend mit baz1.example.net, foobaz.example.net und buzz.example.net angesehen). Der Client SOLLTE JEDOCH NICHT (SHOULD NOT) versuchen, einen präsentierten Identifikator abzugleichen, bei dem das Wildcard-Zeichen in ein A-Label oder U-Label [IDNA-DEFS] eines internationalisierten Domänennamens [IDNA-PROTO] eingebettet ist.

6.4.4. Überprüfung von Common Names (Checking of Common Names)

Wie angemerkt, DARF ein Client NICHT (MUST NOT) versuchen, eine Übereinstimmung mit einem Referenz-Identifikator vom Typ CN-ID zu finden, wenn ein präsentierter Identifikator eine DNS-ID, SRV-ID, URI-ID oder einen vom Client unterstützten anwendungsspezifischen Identifikatortyp enthält.

Daher KANN (MAY) der Client nur dann als letzten Ausweg die Zeichenfolge überprüfen, die im Common Name-Feld des Subject-Feldes gefunden wurde (d. h. die CN-ID), wenn der präsentierte Identifikator keine DNS-ID, SRV-ID, URI-ID oder keinen vom Client unterstützten anwendungsspezifischen Identifikatortyp enthält und wenn diese Zeichenfolge dem Format eines vollqualifizierten DNS-Domänennamens entspricht. Wenn der Client sich entscheidet, einen Referenz-Identifikator vom Typ CN-ID mit dieser Zeichenfolge zu vergleichen, MUSS (MUST) er den Vergleichsregeln für den DNS-Domänennamen-Teil einer Kennung vom Typ DNS-ID, SRV-ID oder URI-ID folgen, wie in den Abschnitten 6.4.1, 6.4.2 und 6.4.3 beschrieben.

6.5. Abgleich des Anwendungsdienst-Typ-Teils (Matching the Application Service Type Portion)

Wenn der Client einen Identifikator vom Typ SRV-ID und URI-ID überprüft, MUSS (MUST) er den Anwendungsdienst-Typ-Teil des Identifikators zusammen mit dem DNS-Domänennamen-Teil überprüfen. Der Client tut dies, indem er den Identifikator in einen DNS-Domänennamen-Teil und einen Anwendungsdienst-Typ-Teil aufteilt (wie in Abschnitt 6.3 empfohlen) und dann den DNS-Domänennamen-Teil (wie in Abschnitt 6.4 beschrieben) und den Anwendungsdienst-Typ-Teil (wie in den folgenden Unterabschnitten beschrieben) überprüft.

Implementierungshinweis: Ein Identifikator vom Typ SRV-ID oder URI-ID stellt einen Anwendungsdienst-Typ-Teil zur Überprüfung bereit, aber dieser Teil wird nur mit dem DNS-Domänennamen-Teil der SRV-ID oder URI-ID selbst kombiniert. Wenn beispielsweise die Liste der Referenz-Identifikatoren eines Clients eine SRV-ID von "_xmpp-client.im.example.org" und eine DNS-ID von "apps.example.net" enthält, würde der Client (a) die Kombination aus einem Anwendungsdienst-Typ von "xmpp-client" und einem DNS-Domänennamen von "im.example.org" und (b) die Kombination aus einem DNS-Domänennamen von "apps.example.net" überprüfen; der Client würde jedoch nicht (c) die Kombination aus einem Anwendungsdienst-Typ von "xmpp-client" und einem DNS-Domänennamen von "apps.example.net" überprüfen, da er keine SRV-ID von "_xmpp-client.apps.example.net" in seiner Liste der Referenz-Identifikatoren hat.

6.5.1. SRV-ID

Der Dienstnamen-Teil einer SRV-ID (z. B. "imaps") MUSS (MUST) ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen werden, gemäß [DNS-SRV]. Beachten Sie, dass das Zeichen "_" den Dienstkennungen in DNS SRV-Datensätzen und SRV-IDs vorangestellt wird (gemäß [SRVNAME]) und nicht in den Vergleich einbezogen werden muss.

6.5.2. URI-ID

Der Schema-Namen-Teil einer URI-ID (z. B. "sip") MUSS (MUST) ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen werden, gemäß [URI]. Beachten Sie, dass das Zeichen ":" ein Trennzeichen zwischen dem Schema-Namen und dem Rest des URI ist und nicht in den Vergleich einbezogen werden muss.

6.6. Ergebnis (Outcome)

Das Ergebnis des Abgleichprozesses wird einer der folgenden Fälle sein.

6.6.1. Fall #1: Übereinstimmung gefunden (Case #1: Match Found)

Wenn der Client einen präsentierten Identifikator gefunden hat, der mit einem Referenz-Identifikator übereinstimmt, war die Überprüfung der Dienst-Identität erfolgreich. In diesem Fall MUSS (MUST) der Client den übereinstimmenden Referenz-Identifikator als authentifizierte Identität des Anwendungsdienstes verwenden.

6.6.2. Fall #2: Keine Übereinstimmung gefunden, angeheftetes Zertifikat (Case #2: No Match Found, Pinned Certificate)

Wenn der Client keinen präsentierten Identifikator gefunden hat, der mit einem der Referenz-Identifikatoren übereinstimmt, der Client jedoch zuvor das Zertifikat des Anwendungsdienstes an einen der Referenz-Identifikatoren in der für diesen Kommunikationsversuch erstellten Liste "angeheftet" hat ("Anheften" wird in Abschnitt 1.8 beschrieben) und das präsentierte Zertifikat mit dem angehefteten Zertifikat übereinstimmt (einschließlich des in Abschnitt 7.1 beschriebenen Kontexts), dann war die Überprüfung der Dienst-Identität erfolgreich.

6.6.3. Fall #3: Keine Übereinstimmung gefunden, kein angeheftetes Zertifikat (Case #3: No Match Found, No Pinned Certificate)

Wenn der Client keinen präsentierten Identifikator gefunden hat, der mit einem der Referenz-Identifikatoren übereinstimmt, und der Client das Zertifikat nicht zuvor an einen der Referenz-Identifikatoren in der für diesen Kommunikationsversuch erstellten Liste angeheftet hat, dann MUSS (MUST) der Client wie in Abschnitt 6.6.4 beschrieben fortfahren.

6.6.4. Fallback

Wenn der Client ein interaktiver Client ist, der direkt von einem menschlichen Benutzer gesteuert wird, SOLLTE (SHOULD) er den Benutzer über die Nichtübereinstimmung der Identität informieren und kann den Kommunikationsversuch automatisch mit einem Fehler wegen falschem Zertifikat beenden. Dieses Verhalten ist vorzuziehen, da es verhindern kann, dass ein Benutzer versehentlich Sicherheitsvorkehrungen in feindlichen Situationen umgeht.

Sicherheitswarnung: Einige interaktive Clients bieten fortgeschrittenen Benutzern die Möglichkeit, die Akzeptanz trotz der Identitäts-Nichtübereinstimmung fortzusetzen, wodurch das Zertifikat effektiv an einen der Referenz-Identifikatoren in der Liste "angeheftet" wird, die der Client für diesen Kommunikationsversuch erstellt hat. Obwohl ein solches Verhalten in bestimmten spezialisierten Umständen angemessen sein kann, sollte es im Allgemeinen nur fortgeschrittenen Benutzern zugänglich gemacht werden; selbst dann muss es mit äußerster Vorsicht behandelt werden, z. B. indem selbst ein fortgeschrittener Benutzer zunächst ermutigt wird, den Kommunikationsversuch zu beenden, indem der Benutzer gezwungen wird, den vollständigen Zertifizierungspfad zu sehen, wenn der Benutzer sich entscheidet, trotzdem fortzufahren, und erst dann dem Benutzer erlaubt wird, das Zertifikat anzuheften (temporär oder dauerhaft, nach Wahl des Benutzers).

Andernfalls, wenn der Client eine automatisierte Anwendung ist, die nicht direkt von einem menschlichen Benutzer gesteuert wird, SOLLTE (SHOULD) er den Kommunikationsversuch mit einem Fehler wegen falschem Zertifikat beenden und den Fehler entsprechend protokollieren. Die automatisierte Anwendung KANN (MAY) eine Konfigurationseinstellung bereitstellen, um dieses Verhalten zu deaktivieren, MUSS (MUST) dieses Verhalten jedoch standardmäßig aktivieren.