No Revocation Available for X.509 Public Key Certificates

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 October 2024.¶

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 are seeing greater use in the Internet. For example, Automatic Certificate Management Environment (ACME) [RFC8555] 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 a short-lived certificate that is used for authentication or key management is unnecessary and pointless. On the other hand, revoking a certificate associated with a long-lived signature, such as document signing or code signing, provides some important information about when a compromise was discovered.¶

Some long-lived X.509v3 public key certificates never expire, and they are never 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. 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" [RFC5280].¶

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 end-entity certificate, and it updates the certification path validation algorithm in [RFC5280] to skip revocation checking when the noRevAvail certificate extension is present.¶

Note that the noRevAvail certificate extension provides similar functionality to the ocsp-nocheck certificate extension [RFC6960]. The ocsp-nocheck certificate extension is appropriate for inclusion only in certificates issued to OCSP Responders, whereas noRevAvail certificate extension is appropriate in any end-entity certificate for which the CA will not publish revocation information. To avoid disruption to the OCSP ecosystem, implementers should not think of the noRevAvail certificate extension a substitute for the ocsp-nocheck certificate extension; however, the noRevAvail certificate extension could be included in certificates issued to OCSP Responders in addition to the ocsp-nocheck certificate extension.¶

2. The noRevAvail Certificate Extension

The noRevAvail extension, defined in [X.509-2019-TC2], 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.¶

• name           id-ce-noRevAvail
  OID            { 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 to find a certificate revocation list (CRL) from the CA, but the CRL will never include an entry for the certificate containing this extension.¶

3. Other X.509 Certificate Extensions

Certificates for CAs MUST NOT include the noRevAvail extension. 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 basic constraints certificate extension with the cA BOOLEAN set to TRUE; see Section 4.2.1.9 of [RFC5280].¶

• The certificate MUST NOT also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of [RFC5280].¶

• The certificate MUST NOT also include the Freshest CRL certificate extension; see Section 4.2.1.15 of [RFC5280].¶

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

If any of the above bullets is violated in a certificate, then the relying party MUST consider the certificate invalid.¶

4. Certification Path Validation

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

• At the current time, the certificate is not revoked.  This
  may be determined by obtaining the appropriate CRL
  (Section 6.3), by status information, or by out-of-band
  mechanisms.
  

  ¶

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

5. ASN.1 Module

This section provides an ASN.1 module [X.680] for the noRevAvail certificate extension, and it follows the conventions established in [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(TBD) }

  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 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. When such mis-use is discovered, the only possible remediation is the revocation of the CA.¶

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.¶

The absence of revocation information limits the ability of relying parties to detect compromise of end-entity keying material or malicious certificates. It also limits the ability to detect CAs not following the security practices, certificate issuance policies, and operational controls that are specified in the Certificate Policy (CP) or the Certification Practices Statement (CPS) [RFC3647].¶

Since the absence of revocation information may limit the ability to detect compromised keying material 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.¶

7. IANA Considerations

For the ASN.1 Module in Section 5, 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), and the Description for the new OID should be set to "id-mod-noRevAvail".¶

8. Acknowledgements

Many thanks to Erik Anderson for his efforts to make the noRevAvail certificate extension available for use with public key end-entity certificates 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, and Paul Wouters for their review and insightful comments.¶

Authors' Addresses