Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9608.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

X.509v3 public key certificates[RFC5280] with short validity periods areseeing greater use in the Internet. For example, Automatic CertificateManagement Environment (ACME)[RFC8555] provides a straightforward wayto obtain short-lived certificates. In many cases, no revocationinformation is made available for short-lived certificates by theCertification Authority (CA). This is because short-lived certificateshave a validity period that is shorter than the time needed to detect, report,and distribute revocation information. As a result, revoking a short-livedcertificate that is used for authentication or key management is unnecessaryand pointless. On the other hand, revoking a certificate associated with along-lived signature, such as document signing or code signing, provides someimportant information about when a compromise was discovered.¶

Some long-lived X.509v3 public key certificates never expire, and they arenever revoked. For example, a factory might include an IDevID certificate[IEEE802.1AR]to bind the factory-assigned device identity to a factory-installed public key. Thisidentity might include the manufacturer, model, and serial number of the device,which never change. To indicate that a certificate has no well-defined expirationdate, the notAfter date in the certificate validity period is set to"99991231235959Z"[RFC5280].¶

This specification defines the noRevAvail certificate extension so that arelying party can readily determine that the CA does not publish revocationinformation for the end-entity certificate, and it updates the certificationpath validation algorithm defined in[RFC5280] so that revocation checking is skipped when thenoRevAvail certificate extension is present.¶

Note that the noRevAvail certificate extension provides similar functionalityto the ocsp-nocheck certificate extension[RFC6960]. The ocsp-nocheckcertificate extension is appropriate for inclusion only in certificates issued toOnline Certificate Status Protocol (OCSP) responders, whereas the noRevAvail certificate extension is appropriate in anyend-entity certificate for which the CA will not publish revocation information. Toavoid disruption to the OCSP ecosystem, implementers should not think of thenoRevAvail certificate extension a substitute for the ocsp-nocheck certificateextension; however, the noRevAvail certificate extension could be included incertificates issued to OCSP responders in addition to the ocsp-nocheckcertificate extension.¶

2.The noRevAvail Certificate Extension

The noRevAvail extension, defined in[X.509-2019-TC2], allows a CA to indicate thatno revocation information will be made available for this certificate.¶

This extensionMUST NOT be present in CA public key certificates.¶

Conforming CAsMUST include this extension in certificates for which norevocation information will be published. When present, conforming CAsMUST mark this extension as non-critical.¶

name           id-ce-noRevAvailOID            { id-ce 56 }syntax         NULL (i.e. '0500'H is the DER encoding)criticality    MUST be FALSE

A relying party that does not understand this extension might be able tofind a Certificate Revocation List (CRL) from the CA, but the CRL willnever include an entry for the certificate containing this extension.¶

3.Other X.509 Certificate Extensions

Certificates for CAsMUST NOT include the noRevAvail extension.Certificates that include the noRevAvail extensionMUST NOT includecertificate extensions that point to CRLrepositories or provide locations of OCSP responders. If the noRevAvail extension is present in acertificate, then:¶

• The certificateMUST NOT also include the basic constraints certificate extension with the cA BOOLEAN set to TRUE; seeSection 4.2.1.9 of [RFC5280].¶

• The certificateMUST NOT also include the CRL Distribution Points certificate extension; seeSection 4.2.1.13 of [RFC5280].¶

• The certificateMUST NOT also include the Freshest CRL certificate extension; seeSection 4.2.1.15 of [RFC5280].¶

• The Authority Information Access certificate extension, if present,MUST NOT include an id-ad-ocsp accessMethod; seeSection 4.2.2.1 of [RFC5280].¶

If any of the above are violated in a certificate, thenthe relying partyMUST consider the certificate invalid.¶

4.Certification Path Validation

Section 6.1.3 of [RFC5280] describes basic certificate processing withinthe certification path validation procedures. In particular, Step (a)(3) says:¶

At the current time, the certificate is not revoked. Thismay be determined by obtaining the appropriate CRL(Section6.3), by status information, or by out-of-bandmechanisms.¶

If the noRevAvail certificate extension specified in this documentis present or the ocsp-nocheck certificate extension[RFC6960] is present,then Step (a)(3) is skipped. Otherwise, revocation status determination of thecertificate is performed.¶

5.ASN.1 Module

This section provides an ASN.1 module[X.680] for the noRevAvailcertificate extension, and it follows the conventions establishedin[RFC5912] and[RFC6268].¶

<CODE BEGINS>  NoRevAvailExtn    { iso(1) identified-organization(3) dod(6) internet(1)      security(5) mechanisms(5) pkix(7) id-mod(0)      id-mod-noRevAvail(110) }  DEFINITIONS IMPLICIT TAGS ::=  BEGIN  IMPORTS    EXTENSION    FROM PKIX-CommonTypes-2009  -- RFC 5912      { iso(1) identified-organization(3) dod(6) internet(1)        security(5) mechanisms(5) pkix(7) id-mod(0)        id-mod-pkixCommon-02(57) } ;  -- noRevAvail Certificate Extension  ext-noRevAvail EXTENSION ::= {    SYNTAX NULL    IDENTIFIED BY id-ce-noRevAvail    CRITICALITY { FALSE } }  -- noRevAvail Certificate Extension OID  id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }  id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 }  END<CODE ENDS>

6.Security Considerations

The Security Considerations in[RFC5280] are relevant.¶

When the noRevAvail certificate extension is included in a certificate,all revocation checking is bypassed. CA policies and practicesMUST ensurethat the noRevAvail certificate extension is included only when appropriate, as any misuse ormisconfiguration could result in a relying party continuing to trusta revoked certificate. When such misuse is discovered, the only possibleremediation is the revocation of the CA.¶

Some applications may have dependencies on revocation information or assumeits availability. The absence of revocation information may require modificationsor alternative configuration settings to ensure proper application security andfunctionality.¶

The absence of revocation information limits the ability of relyingparties to detect compromise of end-entity keying material or maliciouscertificates. It also limits their ability to detect CAs that are not followingthe security practices, certificate issuance policies, and operationalcontrols that are specified in the Certificate Policy (CP) or theCertification Practices Statement (CPS)[RFC3647].¶

Since the absence of revocation information may limit the ability todetect compromised keying material or malicious certificates, relyingparties need confidence that the CA is following security practices,implementing certificate issuance policies, and properly usingoperational controls. Relying parties may evaluate CA reliability,monitor CA performance, and observe CA incident response capabilities.¶

7.IANA Considerations

IANA has assigned the following object identifier (OID) for the ASN.1 module (seeSection 5) within the "SMI Security for PKIX Module Identifier"(1.3.6.1.5.5.7.0) registry:¶

Acknowledgements

Many thanks toErik Anderson for his efforts to make the noRevAvailcertificate extension available for use with public key end-entitycertificates as well as attribute certificates.¶

Many thanks to (in alphabetical order)Corey Bonnell,Hendrik Brockhaus,Tim Hollebeek,Mike Ounsworth,Seo Suchan,Carl Wallace,Éric Vyncke, andPaul Woutersfor their review and insightful comments.¶

Authors' Addresses