X.509v3 Transport Layer Security (TLS) Feature Extension
Extracted elements (25)
The constraint propagation from a Certificate Signing Certificate's TLS feature extension to its issued certificates (requiring the same or superset of features) provides a means of enforcing feature support across a CA's certificate hierarchy without requiring TLS clients to verify compliance in multiple certificates.
The TLS feature extension is designed as an optional, post-issue security control. Risks from fraudulently obtained unmarked certificates are outside its scope and must be addressed by pre-issue controls such as CAA DNS records; the extension only improves security for certificates that opt in.
The TLS feature extension prevents OCSP stapling downgrade attacks by allowing a client to fail immediately if the server does not provide the OCSP status response that the certificate advertises it will supply. Without this extension, a client cannot distinguish a server that does not support OCSP stapling from one that is withholding a status response because the certificate is invalid.
A TLS server certificate containing a TLS feature extension MAY be used with any TLS server that supports the specified features; the server itself need not provide support for processing the TLS feature extension, though such support reduces administrative error risk.
Marking the TLS feature extension critical is not recommended because RFC 5280 requires implementations that do not understand critical extensions to reject the certificate, which breaks backward compatibility with clients that do not implement this extension.
A certificate signed by a Certificate Signing Certificate containing a TLS feature extension MUST itself contain a TLS feature extension offering the same set or a superset of the features advertised in the signing certificate.
A Certification Authority SHOULD ensure the certificate provisioning process permits the certificate subject to meet the requirements — for example, ensuring that OCSP tokens are published before the corresponding certificate is released to the subscriber.
A Certification Authority SHOULD NOT issue certificates that specify a TLS feature extension advertising features that the server does not support.
A Certification Authority SHOULD NOT issue certificates with a TLS feature extension unless there is an affirmative statement (e.g., via CSR or out-of-band communication) that the end entity intends to support the specified features.
A client MAY accept a TLS configuration despite it being inconsistent with the TLS feature declaration but MUST NOT distinguish that connection as secure.
A client MUST treat a certificate with a TLS feature extension as an invalid certificate if the features offered by the server do not contain all features present in both the client's ClientHello message and the TLS feature extension.
A server offering an end-entity certificate that contains a TLS feature extension MUST support the features specified and comply with the corresponding requirements.
A server SHOULD verify that its configuration is compatible with the TLS feature extension expressed in a certificate it presents, and SHOULD NOT begin using a new certificate until the necessary OCSP status tokens are available.
A server SHOULD verify that its configuration supports the features advertised in the credentials presented to a client requesting connection, and SHOULD support generation of the feature extension in CSRs if key generation is supported.
If the use of TLS with a valid certificate is mandated by explicit security policy, application protocol specification, or other means, the client MUST refuse the connection when the TLS feature extension is not satisfied.
If TLS features listed in the certificate are requested by the client in its ClientHello message, then the server MUST return a ServerHello message that satisfies this request.
In the case that a client determines that the server configuration is inconsistent with a feature declaration specifying support for the TLS status_request extension, it SHOULD reject the TLS configuration.
The TLS feature extension SHOULD NOT be marked critical. RFC 5280 requires that implementations not understanding critical extensions MUST reject the certificate, so marking it critical breaks backward compatibility.
The TLS feature extension is an X.509v3 certificate extension identified by OID id-pe-tlsfeature (1.3.6.1.5.5.7.1.24). It allows a certificate to advertise which TLS features a server is required to support, enabling clients to enforce those features during the TLS handshake.
IANA added decimal value 24 with description 'id-pe-tlsfeature' to the 'SMI Security for PKIX Certificate Extension' (1.3.6.1.5.5.7.1) registry, assigning the OID for the TLS feature X.509v3 extension defined in this document.
IANA added decimal value 86 with description 'id-mod-tls-feature-2015' to the 'SMI Security for PKIX Module Identifier' (1.3.6.1.5.5.7.0) registry, assigning the OID for the ASN.1 module defined in this document.
A malicious certificate issuer could issue a certificate specifying a TLS feature that the server cannot support, causing clients to reject valid connections; however, the RFC notes this risk is limited since a CA could equally refuse to issue the certificate at all.
The TLS feature extension does not provide protection against a cipher suite downgrade attack; that protection is left to the existing controls in the TLS protocol itself.
The TLS feature extension is a post-issue security control and provides no protection against an attacker who obtains an unmarked certificate through fraud; such risks require pre-issue controls such as CAA DNS records.
The TLS feature extension value is the ASN.1 DER encoding of a Features structure, defined as SEQUENCE OF INTEGER, where each INTEGER is a TLS extension identifier drawn from the IANA TLS Extensions registry.