No Revocation Available for X.509 Public Key CertificatesVigil Security, LLCHerndonVirginiaUnited States of Americahousley@vigilsec.comDigiCert, Inc.FairfaxVirginiaUnited States of Americatomofumi.okubo+ietf@gmail.comAKAYLA, Inc.TacomaWashingtonUnited States of Americajoe@akayla.com
SEC
lampsCertificate RevocationX.509v3 public key certificates are profiled in RFC 5280. Short-lived
certificates are seeing greater use in the Internet. The Certification
Authority (CA) that issues these short-lived certificates do not publish
revocation information because the certificate lifespan that is shorter than
the time needed to detect, report, and distribute revocation information. Some
long-lived X.509v3 public key certificates never expire, and they are never
revoked. 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, and it updates the certification
path validation algorithm defined in RFC 5280 so that revocation checking is skipped when the
noRevAvail certificate extension is present.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 at
.
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
() 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
. Introduction
. Terminology
. ASN.1
. History
. The noRevAvail Certificate Extension
. Other X.509 Certificate Extensions
. Certification Path Validation
. ASN.1 Module
. Security Considerations
. Short-Lived Certificates
. Long-Lived Certificates
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionX.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 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
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 end-entity certificate, and it updates the certification
path validation algorithm defined in so that revocation checking is skipped when the
noRevAvail certificate extension is present.Note that the noRevAvail certificate extension provides similar functionality
to the ocsp-nocheck certificate extension . The ocsp-nocheck
certificate extension is appropriate for inclusion only in certificates issued to
Online Certificate Status Protocol (OCSP) responders, whereas the 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.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.1X.509 certificates are generated using ASN.1 , using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .HistoryIn 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 ExtensionThe noRevAvail extension, defined in , allows a 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.Other X.509 Certificate ExtensionsCertificates for CAs MUST NOT include the noRevAvail extension.
Certificates that include the noRevAvail extension MUST NOT include
certificate extensions that point to CRL
repositories or provide locations of 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 .
The certificate MUST NOT also include the CRL Distribution Points certificate extension; see .
The certificate MUST NOT also include the Freshest CRL certificate extension; see .
The Authority Information Access certificate extension, if present, MUST NOT include an id-ad-ocsp accessMethod; see .
If any of the above are violated in a certificate, then
the relying party MUST consider the certificate invalid.Certification Path Validation 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 ), by status information, or by out-of-band
mechanisms.
If the noRevAvail certificate extension specified in this document
is present or the ocsp-nocheck certificate extension is present,
then Step (a)(3) is skipped. Otherwise, revocation status determination of the
certificate is performed.ASN.1 ModuleThis section provides an ASN.1 module for the noRevAvail
certificate extension, and it follows the conventions established
in and .
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
Security ConsiderationsThe Security Considerations in 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 certificate extension is included only when appropriate, as any misuse or
misconfiguration could result in a relying party continuing to trust
a revoked certificate. When such misuse 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 their ability to detect CAs that are 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) .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,
monitor CA performance, and observe CA incident response capabilities.Short-Lived CertificatesNo 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 CertificatesNo 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 that are expected to remain secure
for the expected lifetime of the device need to be chosen. 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 ConsiderationsIANA has assigned the following object identifier (OID) for the ASN.1 module (see ) within the "SMI Security for PKIX Module Identifier"
(1.3.6.1.5.5.7.0) registry:
Decimal
Description
110
id-mod-noRevAvail
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks -- Technical Corrigendum 2ITU-TInformation technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notationITU-TInformation technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)ITU-TInformative ReferencesIEEE Standard for Local and Metropolitan Area Networks - Secure Device IdentityIEEEInternet X.509 Public Key Infrastructure Certificate and CRL ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]An Internet Attribute Certificate Profile for AuthorizationThis specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices FrameworkThis document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSPThis document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.Automatic Certificate Management Environment (ACME)Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.The Directory - Authentication FrameworkCCITTInformation technology -- Open Systems Interconnection -- The Directory: Authentication frameworkITU-TInformation Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworksITU-TInformation Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworksITU-TAcknowledgementsMany thanks to 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)
,
,
,
,
,
,
, and
for their review and insightful comments.Authors' AddressesVigil Security, LLCHerndonVirginiaUnited States of Americahousley@vigilsec.comDigiCert, Inc.FairfaxVirginiaUnited States of Americatomofumi.okubo+ietf@gmail.comAKAYLA, Inc.TacomaWashingtonUnited States of Americajoe@akayla.com