<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 2.6.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-norevavail-04" number="9608" category="std" consensus="true" submissionType="IETF" updates="5280" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.1 --> version="3" xml:lang="en">

  <front>
    <title abbrev="NoRevAvail for Public Key Certificates">No Revocation Available for X.509 Public Key Certificates</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-norevavail-04"/> name="RFC" value="9608"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <city>Herndon, VA</city>
          <country>US</country>
          <city>Herndon</city>
	  <region>Virginia</region>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="T." surname="Okubo" fullname="Tomofumi Okubo">
      <organization abbrev="DigiCert">DigiCert, Inc.</organization>
      <address>
        <postal>
          <city>Fairfax, VA</city>
          <country>US</country>
         <city>Fairfax</city>
          <region>Virginia</region>
          <country>United States of America</country>
        </postal>
        <email>tomofumi.okubo+ietf@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Mandel" fullname="Joseph Mandel">
      <organization abbrev="SecureG">SecureG Inc.</organization>
      <address>
        <postal>
          <city>Tacoma, WA</city>
          <country>USA</country>
          <city>Tacoma</city>
	  <region>Washington</region>
          <country>United States of America</country>
        </postal>
        <email>joe.mandel@secureg.io</email>
      </address>
    </author>
    <date year="2024" month="April" day="04"/>
    <area>Security</area>
    <workgroup>LAMPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="June"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 139?>

<t>X.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 to skip so that revocation checking is skipped when the
noRevAvail certificate extension is present.</t>
    </abstract>
  </front>
  <middle>
    <?line 153?>

<section anchor="intro">
      <name>Introduction</name>
      <t>X.509v3 public key certificates <xref target="RFC5280"/> with short validity periods are
seeing greater use in the Internet.  For example, Automatic Certificate
Management Environment (ACME) <xref target="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.</t>
      <t>Some long-lived X.509v3 public key certificates never expire, and they are
never revoked. For example, a factory might include an IDevID certificate <xref target="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" <xref target="RFC5280"/>.</t>
      <t>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 <xref target="RFC5280"/> to skip so that revocation checking is skipped when the
noRevAvail certificate extension is present.</t>
      <t>Note that the noRevAvail certificate extension provides similar functionality
to the ocsp-nocheck certificate extension <xref target="RFC6960"/>.  The ocsp-nocheck
certificate extension is appropriate for inclusion only in certificates issued to
OCSP Responders,
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 responders in addition to the ocsp-nocheck
certificate extension.</t>
      <section anchor="terms">
        <name>Terminology</name>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
        <?line -18?> here.
        </t>

</section>
      <section anchor="asn1">
        <name>ASN.1</name>
        <t>X.509 certificates are generated using ASN.1 <xref target="X.680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690"/>.</t>
      </section>
      <section anchor="history">
        <name>History</name>
        <t>In 1988, CCITT defined the X.509v1 certificate <xref target="X.509-1988"/>.</t>
        <t>In 1997, ITU-T defined the X.509v3 certificate and the attribute
certificate <xref target="X.509-1997"/>.</t>
        <t>In 1999, the IETF first profiled the X.509v3 certificate for use in the
Internet <xref target="RFC2459"/>.</t>
        <t>In 2000, ITU-T defined the noRevAvail certificate extension for use with
attribute certificates <xref target="X.509-2000"/>.</t>
        <t>In 2002, the IETF first profiled the attribute certificate for use in the
Internet <xref target="RFC3281"/>, and this profile included support for the
noRevAvail certificate extension.</t>
        <t>In 2019, ITU-T published an update to ITU-T Recommendation X.509
<xref target="X.509-2019"/>.</t>
        <t>With greater use of short-lived certificates in the Internet, the recent
Technical Corrigendum to ITU-T Recommendation X.509 <xref target="X.509-2019-TC2"/> allows
the noRevAvail certificate extension to be used with public key certificates
as well as attribute certificates.</t>
      </section>
    </section>
    <section anchor="the-norevavail-certificate-extension">
      <name>The noRevAvail Certificate Extension</name>
      <t>The noRevAvail extension, defined in <xref target="X.509-2019-TC2"/>, allows an a CA to indicate that
no revocation information will be made available for this certificate.</t>
      <t>This extension <bcp14>MUST NOT</bcp14> be present in CA public key certificates.</t>
      <t>Conforming CAs <bcp14>MUST</bcp14> include this extension in certificates for which no
revocation information will be published.  When present, conforming CAs
<bcp14>MUST</bcp14> mark this extension as non-critical.</t>

<!-- [rfced] Is this considered pseudocode or some other type of sourcecode, or is <artwork> correct?  See the list of sourcecode types at  <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.  If the current list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.

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

      <ul empty="true">
        <li>
          <artwork><![CDATA[
name           id-ce-noRevAvail
OID            { id-ce 56 }
syntax         NULL (i.e. '0500'H is the DER encoding)
criticality    MUST be FALSE
]]></artwork>
        </li>
      </ul>
      <t>A relying party that does not understand this extension might be able to
find a certificate revocation list Certificate Revocation List (CRL) from the CA, but the CRL will
never include an entry for the certificate containing this extension.</t>
    </section>
    <section anchor="other-x509-certificate-extensions">
      <name>Other X.509 Certificate Extensions</name>
      <t>Certificates for CAs <bcp14>MUST NOT</bcp14> include the noRevAvail extension.
Certificates that include the noRevAvail extension <bcp14>MUST NOT</bcp14> include
certificate extensions that point to Certificate Revocation List (CRL) CRL
repositories or provide locations of Online Certificate Status Protocol
(OCSP) Responders. OCSP responders.  If the noRevAvail extension is present in a
certificate, then:</t>
      <ul spacing="normal">
        <li>
          <t>The certificate <bcp14>MUST NOT</bcp14> also include the basic constraints certificate extension with the cA BOOLEAN set to TRUE; see Section 4.2.1.9 of <xref target="RFC5280"/>.</t> target="RFC5280" sectionFormat="of" section="4.2.1.9"/>.</t>
        </li>
        <li>
          <t>The certificate <bcp14>MUST NOT</bcp14> also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of <xref target="RFC5280"/>.</t> target="RFC5280" sectionFormat="of" section="4.2.1.13"/>.</t>
        </li>
        <li>
          <t>The certificate <bcp14>MUST NOT</bcp14> also include the Freshest CRL certificate extension; see Section 4.2.1.15 of <xref target="RFC5280"/>.</t> target="RFC5280" sectionFormat="of" section="4.2.1.15"/>.</t>
        </li>
        <li>
          <t>The Authority Information Access certificate extension, if present, <bcp14>MUST NOT</bcp14> include an id-ad-ocsp accessMethod; see Section 4.2.2.1 of <xref target="RFC5280"/>.</t> target="RFC5280" sectionFormat="of" section="4.2.2.1"/>.</t>
        </li>
      </ul>
      <t>If any of the above bullets is are violated in a certificate, then
the relying party <bcp14>MUST</bcp14> consider the certificate invalid.</t>
    </section>
    <section anchor="certification-path-validation">
      <name>Certification Path Validation</name>
      <t><xref section="6.1.3" sectionFormat="of" target="RFC5280"/> describes basic certificate processing within
the certification path validation procedures.  In particular, Step (a)(3) says:</t>
      <ul empty="true">
        <li>
          <artwork><![CDATA[
<blockquote>
At the current time, the certificate is not revoked.  This
may be determined by obtaining the appropriate CRL
(Section 6.3), <xref target="RFC5280" section="6.3" sectionFormat="bare"/>), by status information, or by out-of-band
mechanisms.
]]></artwork>
        </li>
      </ul>
</blockquote>
      <t>If the noRevAvail certificate extension that is specified in this document
is present or the ocsp-nocheck certificate extension <xref target="RFC6960"/> is present,
then Step (a)(3) is skipped.  Otherwise, revocation status determination of the
certificate is performed.</t>
    </section>
    <section anchor="asn1-mod">
      <name>ASN.1 Module</name>
      <t>This section provides an ASN.1 module <xref target="X.680"/> for the noRevAvail
certificate extension, and it follows the conventions established
in <xref target="RFC5912"/> and <xref target="RFC6268"/>.</t>
      <sourcecode type="asn.1" markers="true"><![CDATA[
  NoRevAvailExtn
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-noRevAvail(TBD)
      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
]]></sourcecode>
    </section>
    <section anchor="sec-cons">
      <name>Security Considerations</name>
      <t>The Security Considerations in <xref target="RFC5280"/> are relevant.</t>
      <t>When the noRevAvail certificate extension is included in a certificate,
all revocation checking is bypassed.  CA policies and practices <bcp14>MUST</bcp14> 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 mis-use misuse is discovered, the only possible
remediation is the revocation of the CA.</t>
      <t>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.</t>
      <t>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 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) <xref target="RFC3647"/>.</t>
<!-- [rfced] Are there two or three items in the list?

Original:
   Relying parties may evaluate CA reliability,
   monitoring CA performance, and observe CA incident response
   capabilities.

If two, perhaps (RPs may evaluate and observe):
   Relying parties may evaluate CA reliability by
   monitoring CA performance and observe CA incident response
   capabilities.

If three, perhaps (RPs may evaluate, monitor, and observe):
   Relying parties may evaluate CA reliability,
   monitor CA performance, and observe CA incident response
   capabilities.
-->

      <t>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.</t>
      <section anchor="short-lived-certificates">
        <name>Short-lived
        <name>Short-Lived Certificates</name>
        <t>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.</t>
      </section>
      <section anchor="long-lived-certificates">
        <name>Long-lived
        <name>Long-Lived Certificates</name>
        <t>No revocation information is made available for some long-lived certificates
that contain information that never changes.  For example, IDevID certificates
<xref target="IEEE802.1AR"/> are included in devices at the factory, and they are used to
obtain LDevID certificates <xref target="IEEE802.1AR"/> in an operational environment. In this
case, cryptographic algorithms need to be chosen that are expected to remain secure
to
for the expected lifetime of the device. 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.</t>
      </section>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>For
      <t>IANA has assigned the ASN.1 Module in <xref target="asn1-mod"/>, IANA is requested to assign an following object identifier (OID) for the ASN.1 module identifier. The OID for the module
should be allocated in (see <xref target="asn1-mod"/>) within 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".</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>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.</t>
      <t>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.</t>
(1.3.6.1.5.5.7.0) registry:</t>

<table anchor="iana-table">
  <name></name>
  <thead>
    <tr>
      <th>Decimal</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>110</td>
      <td>id-mod-noRevAvail</td>
    </tr>
  </tbody>
</table>

    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>

        <reference anchor="X.509-2019-TC2" target="https://www.itu.int/rec/T-REC-X.509-202310-I!Cor2">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks -- Technical Corrigendum 2</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2023" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2019/Cor.2-2023"/>
        </reference>

        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>

<!-- [rfced] [X.690] URL is correct -->
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

        <reference anchor="IEEE802.1AR" target="https://ieeexplore.ieee.org/document/8423794">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" month="July" day="31"/> month="August" day="02"/>
          </front>
          <seriesInfo name="IEEE" value="802.1AR-2018"/>
        </reference>
        <reference anchor="RFC2459">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Ford" initials="W." surname="Ford"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <author fullname="D. Solo" initials="D." surname="Solo"/>
            <date month="January" year="1999"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2459"/>
          <seriesInfo name="DOI" value="10.17487/RFC2459"/>
        </reference>
        <reference anchor="RFC3281">
          <front>
            <title>An Internet Attribute Certificate Profile for Authorization</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="April" year="2002"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3281"/>
          <seriesInfo name="DOI" value="10.17487/RFC3281"/>
        </reference>
        <reference anchor="RFC3647">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
            <author fullname="S. Chokhani" initials="S." surname="Chokhani"/>
            <author fullname="W. Ford" initials="W." surname="Ford"/>
            <author fullname="R. Sabett" initials="R." surname="Sabett"/>
            <author fullname="C. Merrill" initials="C." surname="Merrill"/>
            <author fullname="S. Wu" initials="S." surname="Wu"/>
            <date month="November" year="2003"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3647"/>
          <seriesInfo name="DOI" value="10.17487/RFC3647"/>
        </reference>
        <reference anchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
        <reference anchor="RFC6960">
          <front>
            <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="M. Myers" initials="M." surname="Myers"/>
            <author fullname="R. Ankney" initials="R." surname="Ankney"/>
            <author fullname="A. Malpani" initials="A." surname="Malpani"/>
            <author fullname="S. Galperin" initials="S." surname="Galperin"/>
            <author fullname="C. Adams" initials="C." surname="Adams"/>
            <date month="June" year="2013"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6960"/>
          <seriesInfo name="DOI" value="10.17487/RFC6960"/>
        </reference>
        <reference anchor="RFC8555">
          <front>
            <title>Automatic Certificate Management Environment (ACME)</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews"/>
            <author fullname="D. McCarney" initials="D." surname="McCarney"/>
            <author fullname="J. Kasten" initials="J." surname="Kasten"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8555"/>
          <seriesInfo name="DOI" value="10.17487/RFC8555"/> value="10.1109/IEEESTD.2018.8423794"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2459.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3281.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>

        <reference anchor="X.509-1988" target="https://www.itu.int/rec/T-REC-X.509-198811-S">
          <front>
            <title>Series X: Data Communication Networks:
            <title>The Directory -- The Directory -- - Authentication Framework</title>
            <author>
              <organization>CCITT</organization>
            </author>
            <date year="1988" month="November"/>
          </front>
          <seriesInfo name="CCITT Recommendation" value="X.509-1988"/>
        </reference>

        <reference anchor="X.509-1997" target="https://www.itu.int/rec/T-REC-X.509-199708-S">
          <front>
            <title>Information Technology technology -- Open Systems Interconnection -- The Directory: Authentication framework</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="1997" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-1997"/>
        </reference>

        <reference anchor="X.509-2000" target="https://www.itu.int/rec/T-REC-X.509-200003-S">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2000"/>
        </reference>

        <reference anchor="X.509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2019"/>
        </reference>

      </references>
    </references>
  </back>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>Many thanks to <contact fullname="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.</t>
      <t>Many thanks to (in alphabetical order)
<contact fullname="Corey Bonnell"/>,
<contact fullname="Hendrik Brockhaus"/>,
<contact fullname="Tim Hollebeek"/>,
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Seo Suchan"/>,
<contact fullname="Carl Wallace"/>,
<contact fullname="Éric Vyncke"/>, and
<contact fullname="Paul Wouters"/>
for their review and insightful comments.</t>
    </section>

<!-- ##markdown-source:
H4sIAFDXDmYAA9Vb63IbyXX+30/Rpn6IjDEQAIoigbXXC4HgCjZvIaDVblKp
VGOmQfRyMA1PzxDLsLj//RZ5luTF8p3uueIiUlo7lcguezDTl3O+Pvc+9DyP
mUREwb+LUEeyx5M4lUwtY/tkkk6r1W11WKD9SCzwOYjFLPGUTGZeKBZL40U6
lvfiXqjQa71l6TIQiTQ9ftQ5aTFfJD1ukoD5OjIyMik+vKYNXrOl6jHOE+3j
zYM0r/HD6DiJ5cxU3jwsqi8SlYQg4fWl5jfyXmN1pSPep73FNJR8pmP+Y/Oo
1eXX6TRUPv+LfOADGSdqpnwi6zUT0ynI7fFLjRXsTDtrx3hm0ulCGYNtJg9L
bD0aTs7Y6rbHz/sX12P+Scd3Krrl38c6XTIRS9HjY+mnsUoe2N0K46NExpFM
vFOCjRE2Pd5pdd4CK4KLiTSZ67jHPO7gvUmN4R90akL5AAB0jL1+ULcgM1+3
wc/PB/iUc1L/ig8+/q/HP2DfQEcN/kOf3uk0SmK8/jjGL7kA3z0+d9t8d08r
GOk3fb0oCJnohZ6lC8Wv7tKpzkk5xVACqAHO/GaFivxDsf+ZUPFM/PK5/ZNs
i6amLX5PMvXdLX2qEfJnbeRyzi8gojLM6bDsyu/XqcheF0RMBFYSDf5pjYZ+
ScTPWjYXdu3vjJ1921SaMRVBLBYQsHtJcjoaDocnrU6z3b+hnxBcEd9KCPc8
SZam9+aNklL+sgyhC016bILKN9CZdCGj5M3J287hcfetm+hkeI9W5GNSPBEH
VgbPIdAhxwt+IZNYL3Wo8Jn3IVX8UiYryJrhXsYjP5X3ypd8FGAD8LpnF8+l
iZ49hxTtY3/nstc+8VrH3mHbvjQyVtIQs26SHd7jGasejcb7m7NB5+1Rt+ce
Dzsn7fzx3dvj7PGo2+5kj+86707yx+67VvZ4cnR0RI9WQb129+RkO5Kr1aqp
krSpAFws/TcT72Y48MpZ7bY3riL5rSMcuBAr/EfIokgEH+jFIo1UZiNy/EhQ
sWii4wcOw+dmTuay9pr3ASPBmk0+iyGINH0XxoPBaDKpgExkeu0dCLvRMGAQ
TUhHYPfoVWCpYNQ9/hqMusetk+0YjXKpBlcT6c8jHerbChJXSxnx8YNJ5MI4
2wXDHQEYmrAdr946WrPn0BpNPnp1tLrHXutkB1p29E60uscFWnBUrS9Hi2a1
Dv8X0XKexruDpyFVF0kSq2maSO6XfqfE0LwUROLDax1+BYg0swJiu/s1ILa7
7ZY3+v8PYhtC1foqENtdxqKqyyCbiBioV8PWmww6X4Nv55Dw/d1Ax53/qyBX
1iEKFDkz0BurW4CVLnjn5afQOfz6U3iDPZsdC5lF/t3JF1oFTHgO4mQLxP2p
SWLhJ4A5SsQvCDATN/gqkny/P75stg9yHsZL6TsAaYCe8akwiD6jbMoXANX2
Wp0vBCrnDyPGV29GwwHc/QkC0naP1nOYdb8Us+7XYUaocBn5OqAoOk5Dyhw2
0Hlv0Rnmw25oGN9/P7w5aOQuVUTaSdz6qAFGWfE9VSbB+1SZuQw2hp1i2D8Y
9u422I+8tmdhZx7iDpHJEGNWnu8P+dLlJaSDFa0zHKkGX8Z6pkIwoyIyNjbj
akK4QH/ihbBCSLvW5xgpietbxJQwAjw1kmbDfxeZStPZgTILIoHsW1QQZgLQ
/gHGi4QjLUqxKuZiEVNuWic00CTWjg8zZ3GZtqmKcEylL4gWIqRqXUI1k2Yp
onxHtw8Ix++I0ehELSSPpAywcaJ5ICFnyE5iudSUpdDJBzj5zHJt355A0wvJ
kP/eZjw8h38k70EFIn6YS7cLiHmwENtPltE7GVg0ie6aTAdypiKHHdApEtEq
5/KXBPkyDTaaWe4FqA8f6PSWIsZJ+IAFxxio8MGyHS+wpgOK1h30gT1R+jz6
lHysIe94UgnP8vm17yQTS5HM+b0IlZNxLsJbEpH5oiqPdCbmTi2ryPtz6dus
eYWwkRZmz2IABJcx5CxKmk5TFioIQsnYK5LbWAepc2WPrxT9fHpegR4fM//8
9MRXoNpJluOH5HwJxdaBVRr2IqU50yQPYrEMAR70RRO4frWawJDCiltJGSHs
z72KdWSf9/uDi+GBo4iSJFAE1b5XAeksJ4ugbucJDmlFmeJKPDCAqqeJABG7
9K5JxpcjryU5MdI0IAeVM2DV4we4CxFILmp1lJ0aPX2wZ1YzELxuIHKpx39z
zd61HJuLe2y9DvxWhefPKzx7qcL3jVUok4Z2MpSVjlhU6axaz4Ie8OKydVHP
evCGZGxRHjENphhLGiPiB0vYUkM84W/oeK4cOxr/E3MwF9TIqG4tjNG+wlPg
JFVUDZVRt5FIUrJCJvXxkUyuKzvYb7QcaIO3k/nvRilehsyeWhB0gkiuSIWY
6jRxKgpy9AJzFgoHuaIdlPE1rBzsG2NkOvnfxXQy96kwnTWVEnwmXIK+IHUA
rX6YktRGfHQq70enNcweHysVm6cn0pipclvl63jAFYCA4sCVUlRWSiGxKnbz
VGQSEZKbLRlqWvFmxYQ6RbQH5CClFXAwcYMvgH7oeKWAAWFKlC6mYBXBDY12
BDTYaq5whA4FHzJxK0mTNFYOKlJYl465IBvPVzIMPedXAgeuU/TAGnPnaJL+
jFSJXuUGrLrSugqS9kk4E832uvjXRg7SOTzqHnX/Za9qPiECv93FZZyx3+ri
dtm43MUhIvOyQ/s7eruqM/kHODykEhWun51bardawKDHfJZG1j2C+sQ6D2t4
fLP0Im1p27GQZYsqeDhkFxVWJ7GdlIslSFjGyuaHAN4qhv2oI5wkAKsZBBtI
kjFnV4PxNUJns9RRIGM4LQCG8zfP87y2K7aA62PbT9vS5FQtk6KVCsMdUrTm
NiaaiXutrI+J06XLbByglniE/cam2Q2uyG6RHQYn5FbSMLB7JHMV3WWa/7wg
wCOlyAqQdGWEf+7sWDHvGz7XK7IjjZfJjG/Jm8rciFFSwbafEl87JQt2AMNR
weJ5OYFYv3rFJ1alXVb4+IoU3DyROZHWbax0jAhs7+LjeLLXcP/PL6/s883w
nz+Oboan9Dz+0D8/Lx5YNmL84erj+Wn5VM4cXF1cDC9P3WS85bVXbO+i/9Oe
swh7V9eT0dVl/3zP2UtVca4U6pNXIchAOLSVHLQwDJrnI/pwedn7wfV//Wf7
LVTpd1REb7e7MBHux0n7+C0Fn7AJbjerHO4neUQGgZYitvBCPH2xVHBEUAph
xWkVcVIO4PhP/0rI/FuP/2HqL9tvv81eEMO1lzlmtZcWs803G5MdiFtebdmm
QLP2fg3pOr39n2q/c9wrL//wp5CMv9c++dO3zAqPrR5kkf5mdnwrIxnboAmm
B7bX1RoeH20B5Ompkb0mabX1BbatvpCHJy+oHrilu84hgroPmIH4gTHE4VTV
b2R1/9xH06ouVGqvRS7lTYBdy87vHjeyysLm/MN6tJhRXJTr2PbVu8eV1bvO
TNDtJp+p2CRlcWHXPmSLykyI5ZmQcxp0W5QvT/XlbcQ/a5PyHSjoZVurj6bg
hzapbNj5PD87Spmf44guvUhqHLzWPdsFS4Np0iXF0bmRfta058S2uzk6mfch
MxJloQiZmG0VJXckrGS/7fD+RAlCNVGFn9mZya0lsQ6zGBlLlLDtNdzPUsOr
1FChG9YNlkuvDHvReTtrahMsm+fsSCAY7B9Fu2QHt0sFKaANVypbVvJwPsy3
dK6mMqogplGIqg3v1vlqZIzRQSF+SNZCdFZLtmtplQ01pnJbxm3FqsJHHliX
COVmnRbIwkOiDxTswApLDLTdnazVAEmvXaLMVGrLrwdmZZwU6V21o5yfQnYR
JH2iMDejr4HQokoAswQsRHy3vrsN8yIPvpOS6hCkf8t+/fVXRl0AvPynAs+X
Xnlm7AqpX+XfoxvBj97xJ2ZcLT7/d/kRnm1fNZFWvW4dtVqvP1DgaO378Kao
Qx+wnAYKHPHPkgwez/rn46GlifXXinE2Oi+SkdQGRklhK0omXaaIteypI+Sd
UVZaz+gqSAPShO8Pbs4P+Az5dxavNjhE3j3fnNsTyDLnSk4sqdVhW2WPzoNK
R875VYmzanNl6xFOn7fqjGGV0k8mJIVgkWxW0+BtqtWsz3eFlWfmbKy+PajM
VrNlFlLKKgOVhqHzAlVGZSOj4KipdQCcZLkTD7OxhgzoVWRDj+pq40QkqeHX
sU60r0O2T0HxQSUqpgLcbDc/ZX5n47sqO9YMRz3EddaGVRktUEAcqGuguQsk
6rKicmGUmB021hpWKxF9/v7q6nzYv8ySfD65+Tj8hi4IqMPE4vS22Wm2m12C
oJ7vfwllJKKneUGOVr3Wu+nbtn/78LcRcAac5xInTpS8fNejXbuWpc7q9Vbf
p0Lf9vWRC85Ke7ihKNBWmCwReJQ1cWEXupDYJNgkDKRt0gVBo0JvVkwSU30P
gUjDUCa2BHuvdGgDYRXVLY2TNOa8ftWaWRJJmKAKmwZERbYOYs1FvQp8TUWS
H4oiCUN8khP/DpjagywrJXmiZHLprewBPSQYbNFEUcbMNkoyfL0kY+cEaZxX
v4kX5aehQBI8TuSS74uD/cMDbsSD6eXepe8MqZ/GMSkjVZcbmxw7s16/02EL
8UCWvChMBVQad3X5PLOo1iQgfmy/hOPwoEHjjTMkFZfaIDtEK6WJp2feFF6E
LSSVA5VZwKNb/7NpW3bEVHkZ3RXnnBDUEllWMUXPlBe2l4YqtqxBpxTVwKa9
7xQyWYLNOpeVMrJRdXIZBDmO+bUvWzuBpYwJI+kEz6VzFzpABsYfXwkTtb2F
Dp7yYmSGc3mREmVTFtmUPBEsfGQlpNihxVmRcKZd7GelREf3VGEiTwEbI7Ig
iBVFwW7bhsGY6SDrvHNZHU7xV4Q8UZNu3MtmVLhZd/2PMMbo/fZBVpWmo/N0
fAsh+A8LEGEb6GD/3YGrPyB+x+jshtlkzaD7Rwe8FB36tbxTv+wf06qE1n4r
n+F+V8Kq/cn70wNEUPh+OjwbXY4oIR/z0cX1+Qh5LJ/0vx/zXu+P+P5++P3o
kgbi49XNxLVSDX+cDC/HmGN/nd1cXfDrv4x+9KgtzzXTGkraupz67extIZBi
RQj39bx/DfcF/zTAUei1OvtHGPrEvyHWQOTzyQQnYalgWIJASPFHu9v4p8tJ
/0cbitrfo9Ph5WR0Nhqe8vc/bUa3trvhBugP+uejyU/AxkahoOvphXRxBMg0
1IXFV+//PBxMyl1vHGn8Z/LKHnD3fF8lyX4HEFvMOl230zplO1eqhN8c84aX
p1bY2WOPG53GvqS7KI8yAIRJf3Td4E+k0nkLMzJO53myCOzxFU7UI3eU1QZ3
DVyrxFMVCH5N3gtbRf+UFd9fVEyulEHXfCajYty24j5ddj4shTHW1FFOppGS
KWt7AhgiAYsEn+acK/XCx5JtK+pXdy9KglVPYiuA5PAXytgUP2YLupCLZuo2
jTOqbD3X3W86HtZuVpAEqCi1fkq7Rn8mcgdXS0KzdM5eLmIbz1ZIqleAzl1a
ShFLG4XEBmE17LQqrpddhFFAlgUqg35+ewjmQpUH3ORW7aVwIJcSsXRkMdTR
roya7mKNSekiE/FOllIryt2aNl4TU7gm31ZCdqxAO8byr6mCwMAKFBGGYbR2
SBbGdvXxOsaIm6kmaAhBd57kbuCmqvwU1oikgNVuYppOmp+nL1QLYs0Fd5Yz
N9geKLNhjjTlZXj1thbjKpcgd9KKwIKqQ3QLCfYWgoRUp6ZW7W/yUeIi6S17
lxtR3keBkfOIRAyNKzguZL6xFk2ZVBDHuYJk5e9lpsgipD8XSWIdZvmcbVyq
BzD1bOyaFqLWA6RgWfVtLTAttI8SN3c/j9HjrOuC2titVx4roit5sdRYdNbA
YRunEHwW+FrNpbFxrNTq4AQvkI648vZTmRL6bbCz4g6KBrzgDJz8QpNtcZxV
joTnRwKDcFMxJUQiIQErG6Y2zLWlEZXh0WDwpTa/tuWfPIijrbNTB87xveMG
mk4On8zWkv5eiO483DrKFfVeVZvb6n+owy53lty+rL+F7epF23Y9/vnmFPaV
3Wgbwf3uq1ZgpmPq2LVnlrembKWbrXXWkOIClr/SqWG25aVB8a1vy8fUHwO5
CvSKdEDb2nYaEf/YgsrxwicHbo0f/eGLSmp9IiRL6p72z/ol4CowUdodqM4Z
pz40gW6jfej3DOnqA9lxSqJdn0RCMXs1gfrMYeDQaHFek/eX+HonVedl98pv
FKq1XpiaYFngs+pbbS37odr1Ydb7yTY7XAxba3GxVrIatrimEqqRV7te1poV
rcxAUrN2svPNfdZbadzdetVaw8MUzWxNSrwpv2TUdga7Hz8sE30bi+UcGX7R
NJGZNVfx9+fayKg09RAnCLT7HNNfaWVOVOatC8UAag+1Klfro9miQDsDPUYA
NHJ7mvXSLKRwhT+oiJo95LJUj6Bcf1Td1ZLj2ewbWjP+Nn0d9S/7m3GuEpFA
jHuWZaS1HNcGt0Wa+9RwS0AMKXJB6unwcj1NOCCc6M/khYoUKub7SAQOinQ3
y4PL7y5aomp6fQjLeheoaB3aumjphPfGF6MyHLd/SIkkLyd5VKy9h4jwlgwf
nHS7edikatAR/nPcbB00yktWWxBa1hp2IrmyNJVEwDKQIOxtpKx7rjDg30V6
BdxdGx6U+IJiZTLRd9ZaDWN1x/u2SJvtY6vgMzwldsBC3K1XoncY4Lry53eV
1cuYMvha68V+wR3WGt37thFgORdTaS8nEESAhwM2gOF74O/p7znCsME+YEvi
8H2s/bs5PFmDTdSCf0CcIKdS3jXYhQJ/V2lkVuB43mBjqfk4JcvTYAMRh/wT
zllQP9p//y0GHz88RDD17pjYtUgxAKIP+Fh2SMr27CmclK2QABvqV00pZljY
M8iadqdwGex/AP67+U9wPAAA [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>

</rfc>