Skip to main content

1. Introduction

1. Introduction​

Traditionally, TLS client and server public keys are obtained in PKIX containers in-band as part of the TLS handshake procedure and are validated using trust anchors based on a [PKIX] certification authority (CA). This method can add a complicated trust relationship that is difficult to validate. Examples of such complexity can be seen in [Defeating-SSL]. TLS is, however, also commonly used with self-signed certificates in smaller deployments where the self-signed certificates are distributed to all involved protocol endpoints out-of-band. This practice does, however, still require the overhead of the certificate generation even though none of the information found in the certificate is actually used.

Alternative methods are available that allow a TLS client/server to obtain the TLS server/client public key:

  • The TLS client can obtain the TLS server public key from a DNSSEC-secured resource record using DNS-Based Authentication of Named Entities (DANE) [RFC6698].

  • The TLS client or server public key is obtained from a [PKIX] certificate chain from a Lightweight Directory Access Protocol [LDAP] server or web page.

  • The TLS client and server public key is provisioned into the operating system firmware image and updated via software updates. For example:

    Some smart objects use the UDP-based Constrained Application Protocol [CoAP] to interact with a Web server to upload sensor data at regular intervals, such as temperature readings. CoAP can utilize DTLS for securing the client-to-server communication. As part of the manufacturing process, the embedded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public/private key pair for the client itself.

This document introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificate that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler. Only a minimalistic ASN.1 parser is needed; code for certificate path validation and other PKIX-related processing is not required. Note, however, the SubjectPublicKeyInfo structure is still in an ASN.1 format. To further reduce the size of the exchanged information, this specification can be combined with the TLS Cached Info extension [CACHED-INFO], which enables TLS peers to exchange just fingerprints of their public keys.

The mechanism defined herein only provides authentication when an out-of-band mechanism is also used to bind the public key to the entity presenting the key.

Section 3 defines the structure of the two new TLS extensions, client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are to be used. Section 4 defines the behavior of the TLS client and the TLS server. Example exchanges are described in Section 5. Section 6 describes security considerations with this approach. Finally, in Section 7 this document registers a new value to the IANA "TLS Certificate Types" subregistry for the support of raw public keys.

Last updated on