Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Extracted elements (23)
Raw public keys reuse the SubjectPublicKeyInfo structure from PKIX certificates rather than defining a new encoding, retaining the algorithm identifier and parameters while omitting certificate-specific fields. This minimizes the ASN.1 parsing footprint: only a minimal parser is needed, and no certificate path validation code is required.
Support for hashes (fingerprints) of public keys was moved to the separate TLS Cached Info extension after IETF 82 discussions, keeping this document focused solely on the SubjectPublicKeyInfo encoding and certificate-type negotiation mechanism.
The server_certificate_type extension in the ServerHello provides an explicit indication of the certificate type in the Certificate payload to avoid parsing ambiguities, since the Certificate message may contain either an X.509 certificate or a SubjectPublicKeyInfo structure depending on negotiation.
A server that does not support the extensions defined in this document simply returns the ServerHello without those extensions, enabling graceful fallback to standard X.509 certificate exchange.
No new cipher suites are required to use raw public keys. All existing cipher suites that support a key exchange method compatible with the defined extensions can be used unchanged.
Raw public keys and X.509 certificates can be combined in the same handshake: for example, the client may use a raw public key for client authentication while the server provides an X.509 certificate. The client can express an ordered preference list in server_certificate_type, and the server selects one value.
If the client hello indicates support of raw public keys in server_certificate_type and the server chooses to use raw public keys, the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload.
If the server does not send a certificate_request, or none of the client-supported certificate types match server-supported types, the client_certificate_type payload in the ServerHello MUST be omitted.
If the server wants to request a certificate from the client, it MUST include the client_certificate_type extension in the ServerHello, and MUST also include a certificate_request payload. The selected value MUST be drawn from the list provided by the client in its ClientHello.
The SubjectPublicKeyInfo value in the Certificate payload MUST contain the DER encoding of the SubjectPublicKeyInfo structure as defined in RFC 5280.
The TLS client MUST omit certificate types from the server_certificate_type extension if it is unable to process the corresponding type. If only X.509 would remain, the client MUST omit the entire server_certificate_type extension from the ClientHello.
Client authentication with RawPublicKey as the client_certificate_type is supported only through out-of-band authentication of the received SubjectPublicKeyInfo. No in-band certificate chain validation is performed.
Server authentication with RawPublicKey as the server_certificate_type is supported only through out-of-band authentication of the received SubjectPublicKeyInfo. Mechanisms such as DANE (RFC 6698) or pre-provisioned keys are cited as examples.
Two new TLS extensions, client_certificate_type and server_certificate_type, are defined for negotiating certificate types during the TLS/DTLS handshake. These extensions are carried in both the ClientHello and ServerHello messages and allow raw public keys to be indicated alongside X.509 and other certificate types.
IANA allocated two new extension type values, client_certificate_type and server_certificate_type, in the 'TLS ExtensionType Values' subregistry defined in RFC 5246. Both extensions are valid in ClientHello and ServerHello messages.
IANA registered value 2 (Raw Public Key) in the 'TLS Certificate Types' subregistry of the 'Transport Layer Security (TLS) Extensions' registry, enabling implementations to signal raw public key capability via the client_certificate_type and server_certificate_type extensions.
An attacker attempting to manipulate certificate-type selection during the handshake must actively modify handshake messages, which causes client and server to compute different handshake hash values. The resulting Finished message mismatch will reveal the attack, since the attacker cannot forge valid Finished messages without the master_secret.
Pre-configured raw public keys are not suitable for a generic Web-based e-commerce environment but are appropriate for constrained smart-object deployments (e.g., CoAP/DTLS sensors) where device firmware and server endpoint are under close administrative control. The chosen out-of-band validation mechanism must be assessed before deployment.
The primary security challenge is binding a raw public key to a specific entity. Without a secure out-of-band binding between identifier and key, the protocol is vulnerable to man-in-the-middle attacks. Specifications using this extension MUST specify how identifier-to-key binding is established and verified.
When the server receives a ClientHello containing client_certificate_type and/or server_certificate_type extensions, three outcomes are defined: (1) server does not support the extension — returns ServerHello without the extensions; (2) server supports it but has no common certificate type — terminates with fatal 'unsupported_certificate' alert; (3) server supports it and has at least one common type — proceeds with negotiation.
The Certificate payload is extended to carry a raw public key as an opaque ASN.1_subjectPublicKeyInfo field (1..2^24-1 octets) when certificate_type is RawPublicKey. The existing X.509 case carries ASN.1Cert certificate_list<0..2^24-1>.
The ClientCertTypeExtension carries a list CertificateType client_certificate_types<1..2^8-1> in the ClientHello, and a single CertificateType client_certificate_type in the ServerHello. ServerCertTypeExtension is symmetric, carrying a preference-ordered list from the client and a single selected value from the server.
The SubjectPublicKeyInfo structure is a DER-encoded ASN.1 SEQUENCE containing an AlgorithmIdentifier (OID plus optional parameters) and a BIT STRING subjectPublicKey. It includes algorithm OIDs for RSA (1.2.840.113549.1.1), DSA (1.2.840.10040.4.1), and ECDSA (1.2.840.10045.2.1).