No Revocation Available for Short-lived X.509 Public Key Certificates

Introduction X.509v3 public key certificates with short validity periods are seeing greater use in the Internet. For example, Automatic Certificate Management Environment (ACME) provides a straightforward way to obtain short-lived certificates. In many cases, no revocation information is made available for short-lived certificates by the Certification Authority (CA). This is because short-lived certificates have a validity period that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. For example, a factory might include an IDevID certificate to bind the factory-assigned device identity to a factory-installed public key. This identity might include the manufacturer, model, and serial number of the device, which never change. To indicate that a certificate has no well-defined expiration date, the notAfter date in the certificate validity period is set to "99991231235959Z" . This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

ASN.1 X.509 certificates are generated using ASN.1 , using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .

History In 1988, CCITT defined the X.509v1 certificate . In 1997, ITU-T defined the X.509v3 certificate and the attribute certificate . In 1999, the IETF first profiled the X.509v3 certificate for use in the Internet . In 2000, ITU-T defined the noRevAvail certificate extension for use with attribute certificates . In 2002, the IETF first profiled the attribute certificate for use in the Internet , and this profile included support for the noRevAvail certificate extension. In 2019, ITU-T published an update to ITU-T Recommendation X.509 . With greater use of short-lived certificates in the Internet, the recent Technical Corrigendum to ITU-T Recommendation X.509 allows the noRevAvail certificate extension to be used with public key certificates as well as attribute certificates.

The noRevAvail Certificate Extension The noRevAvail extension, defined in , allows an CA to indicate that no revocation information will be made available for this certificate. This extension MUST NOT be present in CA public key certificates. Conforming CAs MUST include this extension in certificates for which no revocation information will be published. When present, conforming CAs MUST mark this extension as non-critical.

A relying party that does not understand this extension might be able to find a certificate revocation list (CRL) from the CA, but the CRL will never include an entry for the certificate containing this extension.

Other X.509 Certificate Extensions Certificates that include the noRevAvail extension MUST NOT include certificate extensions that point to Certificate Revocation List (CRL) repositories or provide locations of Online Certificate Status Protocol (OCSP) Responders. If the noRevAvail extension is present in a certificate, then:

The certificate MUST NOT also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of .
The certificate MUST NOT also include the Freshest CRL certificate extension; see Section 4.2.1.15 of .
The Authority Information Access certificate extension, if present, MUST NOT include an id-ad-ocsp accessMethod; see Section 4.2.2.1 of .

ASN.1 Module This section provides an ASN.1 module for the noRevAvail certificate extension, and it follows the conventions established in and .

Security Considerations The Security Considerations in are relevant. When the noRevAvail certificate extension is included in a certificate, all revocation checking is bypassed, even if the CRL Distribution Points, Freshest CRL, or Authority Information Access (pointing to an OCSP Responder) certificate extensions are present. CA policies and practices MUST ensure that the noRevAvail is included only when appropriate, as any misuse or misconfiguration could result in a relying party continuing to trust a revoked certificate. Some applications may have dependencies on revocation information or assume its availability. The absence of revocation information may require modifications or alternative configuration settings to ensure proper application security and functionality. Since the absence of revocation information may limit the ability to detect compromised or malicious certificates, relying parties need confidence that the CA is following security practices, implementing certificate issuance policies, and properly using operational controls. Relying parties may evaluate CA reliability, monitoring CA performance, and observe CA incident response capabilities.

Short-lived Certificates No revocation information is made available for short-lived certificates because the certificate validity period is shorter than the time needed to detect, report, and distribute revocation information. If the noRevAvail certificate extension is incorrectly used for a certificate validity period that is not adequately short, it creates a window of opportunity for attackers to exploit a compromised private key. Therefore, it is crucial to carefully assess and set an appropriate certificate validity period before implementing the noRevAvail certificate extension.

Long-lived Certificates No revocation information is made available for some long-lived certificates that contain information that never changes. For example, IDevID certificates are included in devices at the factory, and they are used to obtain LDevID certificates in an operational environment. In this case, cryptographic algorithms need to be chosen that are expected to remain secure to the expected lifetime of the device. If the noRevAvail certificate extension is used, the CA has no means of notifying the relying party about compromise of the factory-installed keying material.

IANA Considerations For the ASN.1 Module in , IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Acknowledgements Many thanks to Erik Anderson for his efforts to make the noRevAvail certificate extension available for use with public key certificates as well as attribute certificates. Many thanks to Carl Wallace and Tim Hollebeek for their review and insightful comments.