Zum Hauptinhalt springen

5. Client-Zertifikat-URLs

5.1. Verarbeitung der Client-Hello-Nachricht​

Um die Unterstützung mehrerer Zertifikatstypen anzuzeigen, KÖNNEN Clients eine Erweiterung vom Typ "client_certificate_url" in das (erweiterte) Client-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung MUSS "CertChainType" enthalten, wobei:

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

struct {
    CertChainType type;
} CertificateURL;

Wenn die client_certificate_url-Erweiterung gesendet wird, MUSS sie einen Wert aus der aufgezählten Liste CertChainType enthalten. Clients, die diese Erweiterung senden, MÜSSEN darauf vorbereitet sein, CertificateURL-Nachrichten zu verarbeiten, die entweder den Typ individual_certs oder pkipath enthalten.

Die client_certificate_url-Erweiterung kann als Hinweis an den Server betrachtet werden, dass der Client bereit ist, wenn der Server dies akzeptiert, URLs zu senden, die auf die Zertifikate in seiner Certificate-Nachricht verweisen, anstelle der Zertifikate selbst. Auf diese Weise können Server vermeiden, eine große Certificate-Nachricht vom Client zu empfangen (z. B. über eine schmalbandige Wählverbindung).

5.2. Verarbeitung der Server-Hello-Nachricht​

Ein Server, der eine client_certificate_url-Erweiterung im Client-Hello erhält, KANN wählen, dem Client zu erlauben, Zertifikat-URLs anstelle von Zertifikaten zu senden, indem er eine Erweiterung vom Typ "client_certificate_url" in das (erweiterte) Server-Hello aufnimmt. Wenn der Server mehrere Zertifikatskettenkodierungen für URLs unterstützt, kann er den CertChainType in der client_certificate_url-Erweiterung verwenden, um zu bestimmen, welcher der Typen vom Client bevorzugt wird. Das Feld "extension_data" dieser Erweiterung MUSS leer sein.

Clients, die eine client_certificate_url-Erweiterung im Server-Hello erhalten, die anzeigt, dass der Server bereit ist, Zertifikat-URLs zu akzeptieren, KÖNNEN wählen, Zertifikat-URLs wie in Abschnitt 5.3 beschrieben zu senden, anstatt Zertifikate zu senden.

5.3. Client-Certificate-Nachricht​

Normalerweise, wenn eine zertifikatbasierte Client-Authentifizierung vom Server angefordert wird, MUSS der Client die Certificate-Nachricht senden, die seine Zertifikatskette enthält. Wenn der Server jedoch die client_certificate_url-Erweiterung akzeptiert hat, KANN der Client stattdessen die (erweiterte) CertificateURL-Nachricht senden, wobei:

enum {
    X509(0), OpenPGP(1), (255)
} CertificateType;

struct {
    CertificateType cert_type;
    uint16 url_and_hash_len;
    URLAndOptionalHash url_and_hash_list[1..2^16-1];
} CertificateURL;

struct {
    opaque url<1..2^16-1>;
    unint1 padding;
    opaque SHA1Hash[20];
} URLAndOptionalHash;

unint1 URLAndOptionalHash.padding = 0;

Hier enthält "url_and_hash_list" eine Sequenz von URLs (und optionalen Hashes) in aufsteigender Reihenfolge der Präferenz. Jede dieser URLs sollte auf ein einzelnes Zertifikat oder auf eine Zertifikatssequenz verweisen, die die Zertifikatskette des Clients enthält. Server MÜSSEN darauf vorbereitet sein, HTTP [RFC2616]-URLs zu verarbeiten, die auf ungültige HTTP-URLs verweisen, und KÖNNEN andere Schemata wie FTP [RFC0959] und HTTPS [RFC2818] unterstützen (die verwendet werden können, um Server zu identifizieren und zu authentifizieren, die die Zertifikat-URLs hosten). Die URLs DÜRFEN NICHT einen anderen Port als den Standardport für das URL-Schema angeben. Der CertificateType MUSS X509 sein. Wenn andere CertificateType-Werte vorhanden sind, KÖNNEN diese vom Server ignoriert werden.

Wenn URLs verwendet werden, gibt es zwei Möglichkeiten, wie die Zertifikatskette strukturiert werden kann. Der Typ individual_certs zeigt an, dass jede Zertifikat-URL auf ein einzelnes Zertifikat im DER-Format [X690] verweist. Der Typ pkipath zeigt an, dass die URL-Sequenz auf eine Zertifikatssequenz verweist, in der Reihenfolge, die durch PkiPath [RFC4366] und [RFC3280] beschrieben wird. Eine solche Sequenz kann erzeugt werden, indem die pkiPath-Sequenz [RFC3280], Abschnitt 10.1, unter Verwendung der DER-Kodierungskonventionen [X690] kodiert wird.

Der Server muss entscheiden, ob er die Verwendung von URLs akzeptiert oder ob er erfordert, dass der Client die normale Certificate-Nachricht mit den Zertifikaten sendet. Wenn der Server die URLs akzeptiert, hängt die Serververarbeitung vom Typ der Zertifikatskette ab, die er erhält.

Wenn der Server eine Liste vom Typ individual_certs erhalten hat, SOLLTE er die URLs in der Reihenfolge versuchen, in der sie empfangen wurden, bis er erfolgreich die erforderlichen Zertifikate erhält. Wenn eine URL nicht an einem für den Server zugänglichen Ort zwischengespeichert werden kann (z. B. weil das Abrufprotokoll keine Zwischenspeicherung erlaubt), sollte der Server die nächste URL in der Liste versuchen; die Entscheidung, es nach einer Verzögerung erneut mit der ursprünglichen URL zu versuchen, sollte vom Protokoll abhängen, das zum Abrufen der URL verwendet wird, und vom empfangenen Antwortcode.

Wenn der Server eine Liste vom Typ pkipath erhalten hat, SOLLTE er die URLs in der Reihenfolge versuchen, bis er erfolgreich einen vollständigen Satz von Zertifikaten erhält. Die Überlegungen zur Zwischenspeicherung sind die gleichen wie für die individual_certs-Verarbeitung. Es ist möglich, dass ein Server mehrere pkipath-URLs erhält, wobei eine Teilmenge der Zertifikate zwischen verschiedenen PkiPaths gleich ist. In diesem Fall KANN der Server die Zertifikate verwenden, die er bereits bei der Verarbeitung einer nachfolgenden pkipath-URL zwischengespeichert hat.

Eines der Elemente in url_and_hash_list KANN einen zugehörigen Hash haben (siehe Diskussion in Abschnitt 5.4 für Details). Server, die eine CertificateURL-Nachricht erhalten, die mindestens einen Hash enthält, MÜSSEN überprüfen, dass der Hash des abgerufenen Zertifikats (oder der Zertifikatsmenge für pkipath) mit dem angegebenen Hash übereinstimmt. Wenn das Zertifikat (oder die Zertifikatsmenge) nicht mit dem angegebenen Hash übereinstimmt, MUSS der Server die Verbindung mit einer Warnung bad_certificate_hash_value(114) abbrechen.

5.4. Zertifikat-Hash-Informationen​

Die Zertifikat-URL kann auch einen SHA-1-Hash [SHA] der DER-kodierten Daten enthalten, die der URL entsprechen. Dies ermöglicht es dem Server, ein bereits zwischengespeichertes Zertifikat mit den URLs in der Nachricht abzugleichen. Wenn der Server die entsprechenden Zertifikate zwischengespeichert hat, muss er das Zertifikat nicht von der URL abrufen. Wenn das Padding den Wert Null hat, ist der Hash vorhanden; wenn das Padding einen anderen Wert als Null hat, ist kein Hash vorhanden, und der Rest von URLAndOptionalHash nach der URL fehlt.

Wenn der Hash für den Typ individual_certs vorhanden ist, wird der Hash über die DER-kodierten Daten berechnet, die der URL entsprechen (d. h. das einzelne von der URL abgerufene Zertifikat). Wenn der Hash für den Typ pkipath vorhanden ist, wird der Hash über die vollständige pkiPath-kodierte Sequenz berechnet; d. h., der Hash deckt die gesamten DER-kodierten Byte-Daten für die Zertifikatssequenz ab.

Die URL und der Hash, falls vorhanden, ermöglichen es dem Server, ein zwischengespeichertes Zertifikat leicht zu identifizieren, selbst wenn die Kette vom Typ individual_certs ist. Beachten Sie, dass das Abrufen des Zertifikats fehlschlagen könnte, entweder weil der Server nicht auf die URL zugreifen kann oder weil das Zertifikat verschoben wurde, seit der Client es zuletzt gesehen hat. Im letzteren Fall muss der Client möglicherweise das Zertifikat neu laden und den Handshake wiederholen, um dem Server einen aktuellen Zertifikat-Hash bereitzustellen.

5.5. Serverseitige Verarbeitung der CertificateURL-Nachricht​

Wenn der Server eine CertificateURL-Nachricht erhält, MUSS er validieren, dass die Nachricht gemäß der Spezifikation in Abschnitt 5.3 korrekt geformt ist. Insbesondere:

  • Jede URL MUSS ein unterstütztes Abrufschema haben.
  • Die URLs DÜRFEN NICHT einen anderen Port als den Standardport für das Schema angeben.
  • Der CertificateType MUSS ein Wert sein, den der Server versteht. Server MÜSSEN den Typ X509 verstehen.

Wenn der Server feststellt, dass die CertificateURL-Nachricht fehlerhaft ist, MUSS er die Verbindung mit einer Warnung decode_error abbrechen.

Der Server KANN versuchen, die in der CertificateURL-Nachricht referenzierten Zertifikate abzurufen. Wenn dieser Abruf für alle in der Nachricht enthaltenen URLs fehlschlägt, KANN der Server die Verbindung mit einer Warnung certificate_unobtainable(111) abbrechen.

Der Server MUSS die in [RFC5246] beschriebenen Zertifikatsüberprüfungen unter Verwendung des/der abgerufenen Zertifikate(s) durchführen. Wenn die Überprüfungen fehlschlagen, MUSS der Server die Verbindung mit einer entsprechenden Warnung wie in [RFC5246] definiert abbrechen.

Wenn der Server ein zwischengespeichertes Zertifikat basierend auf einem Zertifikat-Hash auswählt und der Inhalt dieses Zertifikats vom Zertifikat abweicht, das von einer URL abgerufen worden wäre, MUSS der Server dieses Szenario als Angriff betrachten und KANN die Verbindung mit einer Warnung bad_certificate_hash_value(114) abbrechen.

Letztes Update am