Skip to main content

5. Examples

5. Examples​

Figures 6, 7, and 8 illustrate example exchanges. Note that TLS ciphersuites using a Diffie-Hellman exchange offering forward secrecy can be used with a raw public key, although this document does not show the information exchange at that level with the subsequent message flows.

5.1. TLS Server Uses a Raw Public Key​

This section shows an example where the TLS client indicates its ability to receive and validate a raw public key from the server. In this example, the client is quite restricted since it is unable to process other certificate types sent by the server. It also does not have credentials at the TLS layer it could send to the server and therefore omits the client_certificate_type extension. Hence, the client only populates the server_certificate_type extension with the raw public key type, as shown in (1).

When the TLS server receives the client hello, it processes the extension. Since it has a raw public key, it indicates in (2) that it had chosen to place the SubjectPublicKeyInfo structure into the Certificate payload (3).

The client uses this raw public key in the TLS handshake together with an out-of-band validation technique, such as DANE, to verify it.

  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

5.2. TLS Client and Server Use Raw Public Keys​

This section shows an example where the TLS client as well as the TLS server use raw public keys. This is one of the use cases envisioned for smart object networking. The TLS client in this case is an embedded device that is configured with a raw public key for use with TLS and is also able to process a raw public key sent by the server. Therefore, it indicates these capabilities in (1). As in the previously shown example, the server fulfills the client's request, indicates this via the RawPublicKey value in the server_certificate_type payload (2), and provides a raw public key in the Certificate payload back to the client (see (3)). The TLS server demands client authentication, and therefore includes a certificate_request (4). The client_certificate_type payload in (5) indicates that the TLS server accepts a raw public key. The TLS client, which has a raw public key pre-provisioned, returns it in the Certificate payload (6) to the server.

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

5.3. Combined Usage of Raw Public Keys and X.509 Certificates​

This section shows an example combining a raw public key and an X.509 certificate. The client uses a raw public key for client authentication, and the server provides an X.509 certificate. This exchange starts with the client indicating its ability to process an X.509 certificate, OpenPGP certificate, or a raw public key, if provided by the server. It prefers a raw public key, since the RawPublicKey value precedes the other values in the server_certificate_type vector. Additionally, the client indicates that it has a raw public key for client-side authentication (see (1)). The server chooses to provide its X.509 certificate in (3) and indicates that choice in (2). For client authentication, the server indicates in (4) that it has selected the raw public key format and requests a certificate from the client in (5). The TLS client provides a raw public key in (6) after receiving and processing the TLS server hello message.

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

Last updated on