rfc9608.original   rfc9608.txt 
LAMPS Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9608 Vigil Security
Updates: 5280 (if approved) T. Okubo Updates: 5280 T. Okubo
Intended status: Standards Track DigiCert Category: Standards Track DigiCert
Expires: 6 October 2024 J. Mandel ISSN: 2070-1721 J. Mandel
SecureG AKAYLA, Inc.
4 April 2024 June 2024
No Revocation Available for X.509 Public Key Certificates No Revocation Available for X.509 Public Key Certificates
draft-ietf-lamps-norevavail-04
Abstract Abstract
X.509v3 public key certificates are profiled in RFC 5280. Short- X.509v3 public key certificates are profiled in RFC 5280. Short-
lived certificates are seeing greater use in the Internet. The lived certificates are seeing greater use in the Internet. The
Certification Authority (CA) that issues these short-lived Certification Authority (CA) that issues these short-lived
certificates do not publish revocation information because the certificates do not publish revocation information because the
certificate lifespan that is shorter than the time needed to detect, certificate lifespan that is shorter than the time needed to detect,
report, and distribute revocation information. Some long-lived report, and distribute revocation information. Some long-lived
X.509v3 public key certificates never expire, and they are never X.509v3 public key certificates never expire, and they are never
revoked. This specification defines the noRevAvail certificate revoked. This specification defines the noRevAvail certificate
extension so that a relying party can readily determine that the CA extension so that a relying party can readily determine that the CA
does not publish revocation information for the certificate, and it does not publish revocation information for the certificate, and it
updates the certification path validation algorithm in RFC 5280 to updates the certification path validation algorithm defined in RFC
skip revocation checking when the noRevAvail certificate extension is 5280 so that revocation checking is skipped when the noRevAvail
present. certificate extension is present.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 October 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9608.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. ASN.1
1.3. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. History
2. The noRevAvail Certificate Extension . . . . . . . . . . . . 4 2. The noRevAvail Certificate Extension
3. Other X.509 Certificate Extensions . . . . . . . . . . . . . 5 3. Other X.509 Certificate Extensions
4. Certification Path Validation . . . . . . . . . . . . . . . . 5 4. Certification Path Validation
5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 5 5. ASN.1 Module
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations
6.1. Short-lived Certificates . . . . . . . . . . . . . . . . 7 6.1. Short-Lived Certificates
6.2. Long-lived Certificates . . . . . . . . . . . . . . . . . 7 6.2. Long-Lived Certificates
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
1. Introduction 1. Introduction
X.509v3 public key certificates [RFC5280] with short validity periods X.509v3 public key certificates [RFC5280] with short validity periods
are seeing greater use in the Internet. For example, Automatic are seeing greater use in the Internet. For example, Automatic
Certificate Management Environment (ACME) [RFC8555] provides a Certificate Management Environment (ACME) [RFC8555] provides a
straightforward way to obtain short-lived certificates. In many straightforward way to obtain short-lived certificates. In many
cases, no revocation information is made available for short-lived cases, no revocation information is made available for short-lived
certificates by the Certification Authority (CA). This is because certificates by the Certification Authority (CA). This is because
short-lived certificates have a validity period that is shorter than short-lived certificates have a validity period that is shorter than
skipping to change at page 3, line 19 skipping to change at line 106
IDevID certificate [IEEE802.1AR] to bind the factory-assigned device IDevID certificate [IEEE802.1AR] to bind the factory-assigned device
identity to a factory-installed public key. This identity might identity to a factory-installed public key. This identity might
include the manufacturer, model, and serial number of the device, include the manufacturer, model, and serial number of the device,
which never change. To indicate that a certificate has no well- which never change. To indicate that a certificate has no well-
defined expiration date, the notAfter date in the certificate defined expiration date, the notAfter date in the certificate
validity period is set to "99991231235959Z" [RFC5280]. validity period is set to "99991231235959Z" [RFC5280].
This specification defines the noRevAvail certificate extension so This specification defines the noRevAvail certificate extension so
that a relying party can readily determine that the CA does not that a relying party can readily determine that the CA does not
publish revocation information for the end-entity certificate, and it publish revocation information for the end-entity certificate, and it
updates the certification path validation algorithm in [RFC5280] to updates the certification path validation algorithm defined in
skip revocation checking when the noRevAvail certificate extension is [RFC5280] so that revocation checking is skipped when the noRevAvail
present. certificate extension is present.
Note that the noRevAvail certificate extension provides similar Note that the noRevAvail certificate extension provides similar
functionality to the ocsp-nocheck certificate extension [RFC6960]. functionality to the ocsp-nocheck certificate extension [RFC6960].
The ocsp-nocheck certificate extension is appropriate for inclusion The ocsp-nocheck certificate extension is appropriate for inclusion
only in certificates issued to OCSP Responders, whereas noRevAvail only in certificates issued to Online Certificate Status Protocol
certificate extension is appropriate in any end-entity certificate (OCSP) responders, whereas the noRevAvail certificate extension is
for which the CA will not publish revocation information. To avoid appropriate in any end-entity certificate for which the CA will not
disruption to the OCSP ecosystem, implementers should not think of publish revocation information. To avoid disruption to the OCSP
the noRevAvail certificate extension a substitute for the ocsp- ecosystem, implementers should not think of the noRevAvail
nocheck certificate extension; however, the noRevAvail certificate certificate extension a substitute for the ocsp-nocheck certificate
extension could be included in certificates issued to OCSP Responders extension; however, the noRevAvail certificate extension could be
in addition to the ocsp-nocheck certificate extension. included in certificates issued to OCSP responders in addition to the
ocsp-nocheck certificate extension.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ASN.1 1.2. ASN.1
skipping to change at page 4, line 32 skipping to change at line 164
In 2019, ITU-T published an update to ITU-T Recommendation X.509 In 2019, ITU-T published an update to ITU-T Recommendation X.509
[X.509-2019]. [X.509-2019].
With greater use of short-lived certificates in the Internet, the With greater use of short-lived certificates in the Internet, the
recent Technical Corrigendum to ITU-T Recommendation X.509 recent Technical Corrigendum to ITU-T Recommendation X.509
[X.509-2019-TC2] allows the noRevAvail certificate extension to be [X.509-2019-TC2] allows the noRevAvail certificate extension to be
used with public key certificates as well as attribute certificates. used with public key certificates as well as attribute certificates.
2. The noRevAvail Certificate Extension 2. The noRevAvail Certificate Extension
The noRevAvail extension, defined in [X.509-2019-TC2], allows an CA The noRevAvail extension, defined in [X.509-2019-TC2], allows a CA to
to indicate that no revocation information will be made available for indicate that no revocation information will be made available for
this certificate. this certificate.
This extension MUST NOT be present in CA public key certificates. This extension MUST NOT be present in CA public key certificates.
Conforming CAs MUST include this extension in certificates for which Conforming CAs MUST include this extension in certificates for which
no revocation information will be published. When present, no revocation information will be published. When present,
conforming CAs MUST mark this extension as non-critical. conforming CAs MUST mark this extension as non-critical.
name id-ce-noRevAvail name id-ce-noRevAvail
OID { id-ce 56 } OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding) syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE criticality MUST be FALSE
A relying party that does not understand this extension might be able 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 to find a Certificate Revocation List (CRL) from the CA, but the CRL
will never include an entry for the certificate containing this will never include an entry for the certificate containing this
extension. extension.
3. Other X.509 Certificate Extensions 3. Other X.509 Certificate Extensions
Certificates for CAs MUST NOT include the noRevAvail extension. Certificates for CAs MUST NOT include the noRevAvail extension.
Certificates that include the noRevAvail extension MUST NOT include Certificates that include the noRevAvail extension MUST NOT include
certificate extensions that point to Certificate Revocation List certificate extensions that point to CRL repositories or provide
(CRL) repositories or provide locations of Online Certificate Status locations of OCSP responders. If the noRevAvail extension is present
Protocol (OCSP) Responders. If the noRevAvail extension is present
in a certificate, then: in a certificate, then:
* The certificate MUST NOT also include the basic constraints * The certificate MUST NOT also include the basic constraints
certificate extension with the cA BOOLEAN set to TRUE; see certificate extension with the cA BOOLEAN set to TRUE; see
Section 4.2.1.9 of [RFC5280]. Section 4.2.1.9 of [RFC5280].
* The certificate MUST NOT also include the CRL Distribution Points * The certificate MUST NOT also include the CRL Distribution Points
certificate extension; see Section 4.2.1.13 of [RFC5280]. certificate extension; see Section 4.2.1.13 of [RFC5280].
* The certificate MUST NOT also include the Freshest CRL certificate * The certificate MUST NOT also include the Freshest CRL certificate
extension; see Section 4.2.1.15 of [RFC5280]. extension; see Section 4.2.1.15 of [RFC5280].
* The Authority Information Access certificate extension, if * The Authority Information Access certificate extension, if
present, MUST NOT include an id-ad-ocsp accessMethod; see present, MUST NOT include an id-ad-ocsp accessMethod; see
Section 4.2.2.1 of [RFC5280]. Section 4.2.2.1 of [RFC5280].
If any of the above bullets is violated in a certificate, then the If any of the above are violated in a certificate, then the relying
relying party MUST consider the certificate invalid. party MUST consider the certificate invalid.
4. Certification Path Validation 4. Certification Path Validation
Section 6.1.3 of [RFC5280] describes basic certificate processing Section 6.1.3 of [RFC5280] describes basic certificate processing
within the certification path validation procedures. In particular, within the certification path validation procedures. In particular,
Step (a)(3) says: Step (a)(3) says:
At the current time, the certificate is not revoked. This | At the current time, the certificate is not revoked. This may be
may be determined by obtaining the appropriate CRL | determined by obtaining the appropriate CRL (Section 6.3), by
(Section 6.3), by status information, or by out-of-band | status information, or by out-of-band mechanisms.
mechanisms.
If the noRevAvail certificate extension that is specified in this If the noRevAvail certificate extension specified in this document is
document is present or the ocsp-nocheck certificate extension present or the ocsp-nocheck certificate extension [RFC6960] is
[RFC6960] is present, then Step (a)(3) is skipped. Otherwise, present, then Step (a)(3) is skipped. Otherwise, revocation status
revocation status determination of certificate is performed. determination of the certificate is performed.
5. ASN.1 Module 5. ASN.1 Module
This section provides an ASN.1 module [X.680] for the noRevAvail This section provides an ASN.1 module [X.680] for the noRevAvail
certificate extension, and it follows the conventions established in certificate extension, and it follows the conventions established in
[RFC5912] and [RFC6268]. [RFC5912] and [RFC6268].
<CODE BEGINS> <CODE BEGINS>
NoRevAvailExtn NoRevAvailExtn
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-noRevAvail(TBD) } id-mod-noRevAvail(110) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912 FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ; id-mod-pkixCommon-02(57) } ;
skipping to change at page 6, line 43 skipping to change at line 268
END END
<CODE ENDS> <CODE ENDS>
6. Security Considerations 6. Security Considerations
The Security Considerations in [RFC5280] are relevant. The Security Considerations in [RFC5280] are relevant.
When the noRevAvail certificate extension is included in a When the noRevAvail certificate extension is included in a
certificate, all revocation checking is bypassed. CA policies and certificate, all revocation checking is bypassed. CA policies and
practices MUST ensure that the noRevAvail is included only when practices MUST ensure that the noRevAvail certificate extension is
appropriate, as any misuse or misconfiguration could result in a included only when appropriate, as any misuse or misconfiguration
relying party continuing to trust a revoked certificate. When such could result in a relying party continuing to trust a revoked
mis-use is discovered, the only possible remediation is the certificate. When such misuse is discovered, the only possible
revocation of the CA. remediation is the revocation of the CA.
Some applications may have dependencies on revocation information or Some applications may have dependencies on revocation information or
assume its availability. The absence of revocation information may assume its availability. The absence of revocation information may
require modifications or alternative configuration settings to ensure require modifications or alternative configuration settings to ensure
proper application security and functionality. proper application security and functionality.
The absence of revocation information limits the ability of relying The absence of revocation information limits the ability of relying
parties to detect compromise of end-entity keying material or parties to detect compromise of end-entity keying material or
malicious certificates. It also limits the ability to detect CAs not malicious certificates. It also limits their ability to detect CAs
following the security practices, certificate issuance policies, and that are not following the security practices, certificate issuance
operational controls that are specified in the Certificate Policy policies, and operational controls that are specified in the
(CP) or the Certification Practices Statement (CPS) [RFC3647]. Certificate Policy (CP) or the Certification Practices Statement
(CPS) [RFC3647].
Since the absence of revocation information may limit the ability to Since the absence of revocation information may limit the ability to
detect compromised keying material or malicious certificates, relying detect compromised keying material or malicious certificates, relying
parties need confidence that the CA is following security practices, parties need confidence that the CA is following security practices,
implementing certificate issuance policies, and properly using implementing certificate issuance policies, and properly using
operational controls. Relying parties may evaluate CA reliability, operational controls. Relying parties may evaluate CA reliability,
monitoring CA performance, and observe CA incident response monitor CA performance, and observe CA incident response
capabilities. capabilities.
6.1. Short-lived Certificates 6.1. Short-Lived Certificates
No revocation information is made available for short-lived No revocation information is made available for short-lived
certificates because the certificate validity period is shorter than certificates because the certificate validity period is shorter than
the time needed to detect, report, and distribute revocation the time needed to detect, report, and distribute revocation
information. If the noRevAvail certificate extension is incorrectly information. If the noRevAvail certificate extension is incorrectly
used for a certificate validity period that is not adequately short, used for a certificate validity period that is not adequately short,
it creates a window of opportunity for attackers to exploit a it creates a window of opportunity for attackers to exploit a
compromised private key. Therefore, it is crucial to carefully compromised private key. Therefore, it is crucial to carefully
assess and set an appropriate certificate validity period before assess and set an appropriate certificate validity period before
implementing the noRevAvail certificate extension. implementing the noRevAvail certificate extension.
6.2. Long-lived Certificates 6.2. Long-Lived Certificates
No revocation information is made available for some long-lived No revocation information is made available for some long-lived
certificates that contain information that never changes. For certificates that contain information that never changes. For
example, IDevID certificates [IEEE802.1AR] are included in devices at example, IDevID certificates [IEEE802.1AR] are included in devices at
the factory, and they are used to obtain LDevID certificates the factory, and they are used to obtain LDevID certificates
[IEEE802.1AR] in an operational environment. In this case, [IEEE802.1AR] in an operational environment. In this case,
cryptographic algorithms need to be chosen that are expected to cryptographic algorithms that are expected to remain secure for the
remain secure to the expected lifetime of the device. If the expected lifetime of the device need to be chosen. If the noRevAvail
noRevAvail certificate extension is used, the CA has no means of certificate extension is used, the CA has no means of notifying the
notifying the relying party about compromise of the factory-installed relying party about compromise of the factory-installed keying
keying material. material.
7. IANA Considerations 7. IANA Considerations
For the ASN.1 Module in Section 5, IANA is requested to assign an IANA has assigned the following object identifier (OID) for the ASN.1
object identifier (OID) for the module identifier. The OID for the module (see Section 5) within the "SMI Security for PKIX Module
module should be allocated in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:
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 | Decimal | Description |
certificates as well as attribute certificates. +=========+===================+
| 110 | id-mod-noRevAvail |
+---------+-------------------+
Many thanks to (in alphabetical order) Corey Bonnell, Hendrik Table 1
Brockhaus, Tim Hollebeek, Mike Ounsworth, Seo Suchan, Carl Wallace,
Éric Vyncke, and Paul Wouters for their review and insightful
comments.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.509-2019-TC2] [X.509-2019-TC2]
ITU-T, "Information Technology -- Open Systems ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute Interconnection -- The Directory: Public-key and attribute
certificate frameworks -- Technical Corrigendum 2", ITU-T certificate frameworks -- Technical Corrigendum 2", ITU-T
Recommendation X.509-2019/Cor.2-2023, October 2023, Recommendation X.509-2019/Cor.2-2023, October 2023,
<https://www.itu.int/rec/T-REC-X.509-202310-I!Cor2>. <https://www.itu.int/rec/T-REC-X.509-202310-I!Cor2>.
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation [X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology -- ASN.1 encoding rules: [X.690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021, (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>. February 2021, <https://www.itu.int/rec/T-REC-X.690>.
9.2. Informative References 8.2. Informative References
[IEEE802.1AR] [IEEE802.1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE 802.1AR-2018, 31 Networks - Secure Device Identity", IEEE 802.1AR-2018,
July 2018, <https://ieeexplore.ieee.org/document/8423794>. DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
<https://ieeexplore.ieee.org/document/8423794>.
[RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999, Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999,
<https://www.rfc-editor.org/rfc/rfc2459>. <https://www.rfc-editor.org/info/rfc2459>.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, Certificate Profile for Authorization", RFC 3281,
DOI 10.17487/RFC3281, April 2002, DOI 10.17487/RFC3281, April 2002,
<https://www.rfc-editor.org/rfc/rfc3281>. <https://www.rfc-editor.org/info/rfc3281>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/rfc/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268, Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011, DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/rfc/rfc6268>. <https://www.rfc-editor.org/info/rfc6268>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[X.509-1988] [X.509-1988]
CCITT, "Series X: Data Communication Networks: Directory CCITT, "The Directory - Authentication Framework", CCITT
-- The Directory -- Authentication Framework", CCITT
Recommendation X.509-1988, November 1988, Recommendation X.509-1988, November 1988,
<https://www.itu.int/rec/T-REC-X.509-198811-S>. <https://www.itu.int/rec/T-REC-X.509-198811-S>.
[X.509-1997] [X.509-1997]
ITU-T, "Information Technology -- Open Systems ITU-T, "Information technology -- Open Systems
Interconnection -- The Directory: Authentication Interconnection -- The Directory: Authentication
framework", ITU-T Recommendation X.509-1997, August 1997, framework", ITU-T Recommendation X.509-1997, August 1997,
<https://www.itu.int/rec/T-REC-X.509-199708-S>. <https://www.itu.int/rec/T-REC-X.509-199708-S>.
[X.509-2000] [X.509-2000]
ITU-T, "Information Technology -- Open Systems ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute Interconnection -- The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509-2000, certificate frameworks", ITU-T Recommendation X.509-2000,
March 2000, March 2000,
<https://www.itu.int/rec/T-REC-X.509-200003-S>. <https://www.itu.int/rec/T-REC-X.509-200003-S>.
[X.509-2019] [X.509-2019]
ITU-T, "Information Technology -- Open Systems ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute Interconnection -- The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509-2019, certificate frameworks", ITU-T Recommendation X.509-2019,
October 2019, October 2019,
<https://www.itu.int/rec/T-REC-X.509-201910-I>. <https://www.itu.int/rec/T-REC-X.509-201910-I>.
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 Authors' Addresses
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
Herndon, VA, Herndon, Virginia
United States of America United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
Tomofumi Okubo Tomofumi Okubo
DigiCert, Inc. DigiCert, Inc.
Fairfax, VA, Fairfax, Virginia
United States of America United States of America
Email: tomofumi.okubo+ietf@gmail.com Email: tomofumi.okubo+ietf@gmail.com
Joseph Mandel Joseph Mandel
SecureG Inc. AKAYLA, Inc.
Tacoma, WA, Tacoma, Washington
United States of America United States of America
Email: joe.mandel@secureg.io Email: joe@akayla.com
 End of changes. 48 change blocks. 
132 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48.