Delegated Credentials for TLS and DTLS
Extracted elements (27)
A new DelegationUsage X.509 extension was chosen instead of a new Extended Key Usage (EKU) to maintain compatibility with deployed (D)TLS and PKI software stacks without requiring CAs to issue new intermediate certificates.
Delegated credentials are preferred over proxy certificates because they require no change to PKI certificate validation, have restricted semantics that avoid X.509 conflicts, provide a cryptographic binding between the entire certificate and the credential, and bind each DC to a specific signature algorithm preventing use with unintended algorithms.
Unlike keyless TLS (remote signing), delegated credentials allow the delegation to be performed offline with no per-transaction latency on the signing path, since the front-end server pre-fetches the DC from the back-end before clients connect.
Delegated credentials are only defined for use with (D)TLS 1.3 or later; their use in prior versions is not allowed. Implementations negotiating TLS < 1.3 MUST ignore the delegated_credential extension.
If a peer decides to cache the certificate chain and re-validate it when resuming a connection, it SHOULD also cache and re-validate the associated delegated credential, to avoid resuming connections for which the DC has expired.
A server that supports this specification SHALL send a 'delegated_credential' extension in the CertificateRequest when requesting client authentication. If the server receives a delegated credential without having indicated support, it MUST abort with an 'unexpected_message' alert.
An endpoint MUST NOT accept a delegated credential unless the peer's end-entity certificate has the DelegationUsage extension and the digitalSignature KeyUsage. The DelegationUsage extension MUST be marked non-critical.
If a client receives a delegated credential without having indicated support in its ClientHello, the client MUST abort the handshake with an 'unexpected_message' alert.
If the delegated_credential extension is not present in the ClientHello, the server MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension.
On receiving a delegated credential, the peer must: (1) verify current time is within the validity interval; (2) verify remaining validity is no more than 7 days and less than the certificate expiry; (3) verify dc_cert_verify_algorithm matches CertificateVerify; (4) verify end-entity certificate conditions; (5) verify the DC signature using the end-entity certificate's public key. Failure on any check MUST result in 'illegal_parameter' alert.
Peers MUST NOT issue delegated credentials with a validity period longer than the maximum validity period (7 days by default) or that extends beyond the validity period of the delegation certificate.
The algorithm field MUST be of a type advertised by the client in the 'signature_algorithms' extension, and dc_cert_verify_algorithm MUST be of a type advertised in the SignatureSchemeList; clients that receive non-valid delegated credentials MUST terminate the connection with an 'illegal_parameter' alert.
The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client MUST NOT use delegated credentials sent as extensions to any other certificate. If the server sends multiple delegated credentials extensions in a single CertificateEntry, the client MUST abort with an 'illegal_parameter' alert.
When a (D)TLS version negotiated is less than 1.3, the client MUST ignore the delegated_credential extension in CertificateRequest. Delegated credentials are only permitted in (D)TLS 1.3 or later.
When using RSA in dc_cert_verify_algorithm, the public key MUST NOT use the rsaEncryption OID, which means rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, and rsa_pss_rsae_sha512 are not allowed for use with delegated credentials.
A service could fingerprint client clock skew by creating delegated credentials with different expiry timestamps and observing which ones the client accepts. Privacy-sensitive clients (e.g., browsers in incognito mode) might choose not to advertise support for delegated credentials or limit probing by the server.
A Credential structure encodes a validity interval and public key for delegation. Fields: valid_time (uint32, seconds relative to delegation certificate's notBefore), dc_cert_verify_algorithm (SignatureScheme), and ASN1_subjectPublicKeyInfo (DER-encoded SubjectPublicKeyInfo, 1..2^24-1 bytes).
The DelegatedCredential signature is computed over: 64 repetitions of 0x20, a context string ('TLS, server delegated credentials' or 'TLS, client delegated credentials'), a 0x00 separator, the DER-encoded end-entity certificate, DelegatedCredential.cred, and DelegatedCredential.algorithm.
The DelegationUsage X.509 certificate extension (OID id-pe-delegationUsage from Cloudflare's PEN arc: 1.3.6.1.4.1.44363.44) signals that a certificate permits use of delegated credentials. Its ASN.1 syntax is NULL and it MUST be marked non-critical.
IANA registered value 95 for 'id-mod-delegated-credential-extn' in the 'SMI Security for PKIX Module Identifier' (1.3.6.1.5.5.7.0) registry for the ASN.1 module defined in Appendix A.
This document registers the 'delegated_credential' extension (value 34) in the 'TLS ExtensionType Values' registry, marked 'Recommended' (Y), applicable to ClientHello (CH), CertificateRequest (CR), and Certificate (CT) messages in (D)TLS 1.3, with DTLS-Only set to N.
An attacker who compromises a delegated credential's private key cannot create new delegated credentials but can impersonate the compromised party in new TLS connections until the credential expires. Access control mechanisms SHOULD be used to protect the DC private key, including file system controls, physical security, or hardware security modules.
Delegated credentials provide no additional early revocation mechanism beyond expiry. Revocation of the long-term private key of the end-entity certificate implicitly revokes all delegated credentials signed by it.
If (D)TLS 1.2 servers support RSA key exchange using a DC-enabled certificate, a Bleichenbacher-style signature forgery attack could produce valid delegated credentials. Operators should minimize use of DC-enabled certificates where a signature forgery oracle may be present, and may prefer elliptic curve certificates for DC-enabled traffic.
The same delegated credential cannot be used for both client and server authentication because the signature is computed over a context string unique to the intended role ('TLS, server delegated credentials' vs. 'TLS, client delegated credentials').
The delegated_credential TLS extension body in ClientHello and CertificateRequest consists of a SignatureSchemeList with field supported_signature_algorithms (2..2^16-2 bytes). The extension is assigned ExtensionType value 34.
The DelegatedCredential structure contains three fields: cred (Credential), algorithm (SignatureScheme used to sign the DC), and signature (opaque, 1..2^16-1 bytes) binding the credential to the end-entity certificate's public key.