5. Examples (Beispiele)
5. Examples (Beispiele)
Die Abbildungen 6, 7 und 8 veranschaulichen beispielhafte Austausche. Beachten Sie, dass TLS-Cipher-Suites, die einen Diffie-Hellman-Austausch verwenden, der Forward Secrecy bietet, mit einem rohen öffentlichen Schlüssel verwendet werden können, obwohl dieses Dokument den Informationsaustausch auf dieser Ebene mit den nachfolgenden Nachrichtenflüssen nicht zeigt.
5.1. TLS Server Uses a Raw Public Key (TLS-Server verwendet einen rohen öffentlichen Schlüssel)
Dieser Abschnitt zeigt ein Beispiel, in dem der TLS-Client seine Fähigkeit anzeigt, einen rohen öffentlichen Schlüssel vom Server zu empfangen und zu validieren. In diesem Beispiel ist der Client recht eingeschränkt, da er andere vom Server gesendete Zertifikatstypen nicht verarbeiten kann. Er verfügt auch nicht über Anmeldeinformationen auf der TLS-Schicht, die er an den Server senden könnte, und lässt daher die client_certificate_type-Erweiterung weg. Daher füllt der Client nur die server_certificate_type-Erweiterung mit dem Typ des rohen öffentlichen Schlüssels, wie in (1) gezeigt.
Wenn der TLS-Server das Client-Hello empfängt, verarbeitet er die Erweiterung. Da er einen rohen öffentlichen Schlüssel hat, gibt er in (2) an, dass er sich entschieden hat, die SubjectPublicKeyInfo-Struktur in die Certificate-Nutzlast (3) zu platzieren.
Der Client verwendet diesen rohen öffentlichen Schlüssel im TLS-Handshake zusammen mit einer Out-of-Band-Validierungstechnik wie DANE, um ihn zu überprüfen.
client_hello,
server_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=RawPublicKey, // (2)
certificate, // (3)
server_key_exchange,
server_hello_done
client_key_exchange,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 6: Example with Raw Public Key Provided by the TLS Server (Abbildung 6: Beispiel mit rohem öffentlichen Schlüssel, der vom TLS-Server bereitgestellt wird)
5.2. TLS Client and Server Use Raw Public Keys (TLS-Client und -Server verwenden rohe öffentliche Schlüssel)
Dieser Abschnitt zeigt ein Beispiel, in dem sowohl der TLS-Client als auch der TLS-Server rohe öffentliche Schlüssel verwenden. Dies ist einer der Anwendungsfälle, die für die Vernetzung intelligenter Objekte vorgesehen sind. Der TLS-Client ist in diesem Fall ein eingebettetes Gerät, das mit einem rohen öffentlichen Schlüssel für die Verwendung mit TLS konfiguriert ist und auch einen vom Server gesendeten rohen öffentlichen Schlüssel verarbeiten kann. Daher gibt er diese Fähigkeiten in (1) an. Wie im zuvor gezeigten Beispiel erfüllt der Server die Anfrage des Clients, gibt dies über den RawPublicKey-Wert in der server_certificate_type-Nutzlast (2) an und stellt dem Client einen rohen öffentlichen Schlüssel in der Certificate-Nutzlast zurück (siehe (3)). Der TLS-Server verlangt eine Client-Authentifizierung und fügt daher eine certificate_request (4) ein. Die client_certificate_type-Nutzlast in (5) gibt an, dass der TLS-Server einen rohen öffentlichen Schlüssel akzeptiert. Der TLS-Client, der über einen vorab bereitgestellten rohen öffentlichen Schlüssel verfügt, gibt ihn in der Certificate-Nutzlast (6) an den Server zurück.
client_hello,
client_certificate_type=(RawPublicKey) // (1)
server_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=RawPublicKey // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (5)
certificate_request, // (4)
server_key_exchange,
server_hello_done
certificate, // (6)
client_key_exchange,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 7: Example with Raw Public Key provided by the TLS Server and the Client (Abbildung 7: Beispiel mit rohem öffentlichen Schlüssel, der vom TLS-Server und dem Client bereitgestellt wird)
5.3. Combined Usage of Raw Public Keys and X.509 Certificates (Kombinierte Verwendung von rohen öffentlichen Schlüsseln und X.509-Zertifikaten)
Dieser Abschnitt zeigt ein Beispiel, das einen rohen öffentlichen Schlüssel und ein X.509-Zertifikat kombiniert. Der Client verwendet einen rohen öffentlichen Schlüssel für die Client-Authentifizierung, und der Server stellt ein X.509-Zertifikat bereit. Dieser Austausch beginnt damit, dass der Client seine Fähigkeit angibt, ein X.509-Zertifikat, ein OpenPGP-Zertifikat oder einen rohen öffentlichen Schlüssel zu verarbeiten, falls dieser vom Server bereitgestellt wird. Er bevorzugt einen rohen öffentlichen Schlüssel, da der RawPublicKey-Wert den anderen Werten im server_certificate_type-Vektor vorausgeht. Zusätzlich gibt der Client an, dass er über einen rohen öffentlichen Schlüssel für die clientseitige Authentifizierung verfügt (siehe (1)). Der Server entscheidet sich, sein X.509-Zertifikat in (3) bereitzustellen, und gibt diese Wahl in (2) an. Für die Client-Authentifizierung gibt der Server in (4) an, dass er das Format für rohe öffentliche Schlüssel ausgewählt hat, und fordert in (5) ein Zertifikat vom Client an. Der TLS-Client stellt einen rohen öffentlichen Schlüssel in (6) bereit, nachdem er die TLS-Server-Hello-Nachricht empfangen und verarbeitet hat.
client_hello,
server_certificate_type=(RawPublicKey, X.509, OpenPGP)
client_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=X.509 // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (4)
certificate_request, // (5)
server_key_exchange,
server_hello_done
certificate, // (6)
client_key_exchange,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 8: Hybrid Certificate Example (Abbildung 8: Hybrides Zertifikatsbeispiel)