rfc9608.original.xml   rfc9608.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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.1 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
0) --> -ietf-lamps-norevavail-04" number="9608" category="std" consensus="true" submiss
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ionType="IETF" updates="5280" obsoletes="" tocInclude="true" sortRefs="true" sym
-ietf-lamps-norevavail-04" category="std" consensus="true" submissionType="IETF" Refs="true" version="3" xml:lang="en">
updates="5280" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.20.1 -->
<front> <front>
<title abbrev="NoRevAvail for Public Key Certificates">No Revocation Availab le for X.509 Public Key Certificates</title> <title abbrev="NoRevAvail for Public Key Certificates">No Revocation Availab le for X.509 Public Key Certificates</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-norevavail-04"/> <seriesInfo name="RFC" value="9608"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<city>Herndon, VA</city> <city>Herndon</city>
<country>US</country> <region>Virginia</region>
<country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Okubo" fullname="Tomofumi Okubo"> <author initials="T." surname="Okubo" fullname="Tomofumi Okubo">
<organization abbrev="DigiCert">DigiCert, Inc.</organization> <organization abbrev="DigiCert">DigiCert, Inc.</organization>
<address> <address>
<postal> <postal>
<city>Fairfax, VA</city> <city>Fairfax</city>
<country>US</country> <region>Virginia</region>
<country>United States of America</country>
</postal> </postal>
<email>tomofumi.okubo+ietf@gmail.com</email> <email>tomofumi.okubo+ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Mandel" fullname="Joseph Mandel"> <author initials="J." surname="Mandel" fullname="Joseph Mandel">
<organization abbrev="SecureG">SecureG Inc.</organization> <organization abbrev="AKAYLA, Inc.">AKAYLA, Inc.</organization>
<address> <address>
<postal> <postal>
<city>Tacoma, WA</city> <city>Tacoma</city>
<country>USA</country> <region>Washington</region>
<country>United States of America</country>
</postal> </postal>
<email>joe.mandel@secureg.io</email> <email>joe@akayla.com</email>
</address> </address>
</author> </author>
<date year="2024" month="April" day="04"/> <date year="2024" month="June"/>
<area>Security</area> <area>SEC</area>
<workgroup>LAMPS Working Group</workgroup> <workgroup>lamps</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 139?>
<keyword>Certificate Revocation</keyword>
<abstract>
<t>X.509v3 public key certificates are profiled in RFC 5280. Short-lived <t>X.509v3 public key certificates are profiled in RFC 5280. Short-lived
certificates are seeing greater use in the Internet. The Certification certificates are seeing greater use in the Internet. The Certification
Authority (CA) that issues these short-lived certificates do not publish Authority (CA) that issues these short-lived certificates do not publish
revocation information because the certificate lifespan that is shorter than revocation information because the certificate lifespan that is shorter than
the time needed to detect, report, and distribute revocation information. Some the time needed to detect, report, and distribute revocation information. Some
long-lived X.509v3 public key certificates never expire, and they are never long-lived X.509v3 public key certificates never expire, and they are never
revoked. This specification defines the noRevAvail certificate extension so revoked. This specification defines the noRevAvail certificate extension so
that a relying party can readily determine that the CA does not publish that a relying party can readily determine that the CA does not publish
revocation information for the certificate, and it updates the certification revocation information for the certificate, and it updates the certification
path validation algorithm in RFC 5280 to skip revocation checking when the path validation algorithm defined in RFC 5280 so that revocation checking is ski pped when the
noRevAvail certificate extension is present.</t> noRevAvail certificate extension is present.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 153?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>X.509v3 public key certificates <xref target="RFC5280"/> with short val idity periods are <t>X.509v3 public key certificates <xref target="RFC5280"/> with short val idity periods are
seeing greater use in the Internet. For example, Automatic Certificate seeing greater use in the Internet. For example, Automatic Certificate
Management Environment (ACME) <xref target="RFC8555"/> provides a straightforwar d way Management Environment (ACME) <xref target="RFC8555"/> provides a straightforwar d way
to obtain short-lived certificates. In many cases, no revocation to obtain short-lived certificates. In many cases, no revocation
information is made available for short-lived certificates by the information is made available for short-lived certificates by the
Certification Authority (CA). This is because short-lived certificates Certification Authority (CA). This is because short-lived certificates
have a validity period that is shorter than the time needed to detect, report, have a validity period that is shorter than the time needed to detect, report,
skipping to change at line 92 skipping to change at line 96
<t>Some long-lived X.509v3 public key certificates never expire, and they are <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"/> 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 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, identity might include the manufacturer, model, and serial number of the device,
which never change. To indicate that a certificate has no well-defined expirati on which never change. To indicate that a certificate has no well-defined expirati on
date, the notAfter date in the certificate validity period is set to date, the notAfter date in the certificate validity period is set to
"99991231235959Z" <xref target="RFC5280"/>.</t> "99991231235959Z" <xref target="RFC5280"/>.</t>
<t>This specification defines the noRevAvail certificate extension so that a <t>This specification defines the noRevAvail certificate extension so that a
relying party can readily determine that the CA does not publish revocation relying party can readily determine that the CA does not publish revocation
information for the end-entity certificate, and it updates the certification information for the end-entity certificate, and it updates the certification
path validation algorithm in <xref target="RFC5280"/> to skip revocation checkin g when the path validation algorithm defined in <xref target="RFC5280"/> so that revocation checking is skipped when the
noRevAvail certificate extension is present.</t> noRevAvail certificate extension is present.</t>
<t>Note that the noRevAvail certificate extension provides similar functio nality <t>Note that the noRevAvail certificate extension provides similar functio nality
to the ocsp-nocheck certificate extension <xref target="RFC6960"/>. The ocsp-no check to the ocsp-nocheck certificate extension <xref target="RFC6960"/>. The ocsp-no check
certificate extension is appropriate for inclusion only in certificates issued t o certificate extension is appropriate for inclusion only in certificates issued t o
OCSP Responders, whereas noRevAvail certificate extension is appropriate in any Online Certificate Status Protocol (OCSP) responders, whereas the noRevAvail cer tificate extension is appropriate in any
end-entity certificate for which the CA will not publish revocation information. To 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 avoid disruption to the OCSP ecosystem, implementers should not think of the
noRevAvail certificate extension a substitute for the ocsp-nocheck certificate noRevAvail certificate extension a substitute for the ocsp-nocheck certificate
extension; however, the noRevAvail certificate extension could be included in extension; however, the noRevAvail certificate extension could be included in
certificates issued to OCSP Responders in addition to the ocsp-nocheck certificates issued to OCSP responders in addition to the ocsp-nocheck
certificate extension.</t> certificate extension.</t>
<section anchor="terms"> <section anchor="terms">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="asn1"> <section anchor="asn1">
<name>ASN.1</name> <name>ASN.1</name>
<t>X.509 certificates are generated using ASN.1 <xref target="X.680"/>, using the Basic <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> Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X. 690"/>.</t>
</section> </section>
<section anchor="history"> <section anchor="history">
<name>History</name> <name>History</name>
<t>In 1988, CCITT defined the X.509v1 certificate <xref target="X.509-19 88"/>.</t> <t>In 1988, CCITT defined the X.509v1 certificate <xref target="X.509-19 88"/>.</t>
skipping to change at line 141 skipping to change at line 149
<t>In 2019, ITU-T published an update to ITU-T Recommendation X.509 <t>In 2019, ITU-T published an update to ITU-T Recommendation X.509
<xref target="X.509-2019"/>.</t> <xref target="X.509-2019"/>.</t>
<t>With greater use of short-lived certificates in the Internet, the rec ent <t>With greater use of short-lived certificates in the Internet, the rec ent
Technical Corrigendum to ITU-T Recommendation X.509 <xref target="X.509-2019-TC2 "/> allows 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 the noRevAvail certificate extension to be used with public key certificates
as well as attribute certificates.</t> as well as attribute certificates.</t>
</section> </section>
</section> </section>
<section anchor="the-norevavail-certificate-extension"> <section anchor="the-norevavail-certificate-extension">
<name>The noRevAvail Certificate Extension</name> <name>The noRevAvail Certificate Extension</name>
<t>The noRevAvail extension, defined in <xref target="X.509-2019-TC2"/>, a llows an CA to indicate that <t>The noRevAvail extension, defined in <xref target="X.509-2019-TC2"/>, a llows a CA to indicate that
no revocation information will be made available for this certificate.</t> no revocation information will be made available for this certificate.</t>
<t>This extension <bcp14>MUST NOT</bcp14> be present in CA public key cert ificates.</t> <t>This extension <bcp14>MUST NOT</bcp14> be present in CA public key cert ificates.</t>
<t>Conforming CAs <bcp14>MUST</bcp14> include this extension in certificat es for which no <t>Conforming CAs <bcp14>MUST</bcp14> include this extension in certificat es for which no
revocation information will be published. When present, conforming CAs revocation information will be published. When present, conforming CAs
<bcp14>MUST</bcp14> mark this extension as non-critical.</t> <bcp14>MUST</bcp14> mark this extension as non-critical.</t>
<ul empty="true">
<li> <artwork><![CDATA[
<artwork><![CDATA[
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
]]></artwork> ]]></artwork>
</li>
</ul>
<t>A relying party that does not understand this extension might be able t o <t>A relying party that does not understand this extension might be able t o
find a certificate revocation list (CRL) from the CA, but the CRL will find a Certificate Revocation List (CRL) from the CA, but the CRL will
never include an entry for the certificate containing this extension.</t> never include an entry for the certificate containing this extension.</t>
</section> </section>
<section anchor="other-x509-certificate-extensions"> <section anchor="other-x509-certificate-extensions">
<name>Other X.509 Certificate Extensions</name> <name>Other X.509 Certificate Extensions</name>
<t>Certificates for CAs <bcp14>MUST NOT</bcp14> include the noRevAvail ext ension. <t>Certificates for CAs <bcp14>MUST NOT</bcp14> include the noRevAvail ext ension.
Certificates that include the noRevAvail extension <bcp14>MUST NOT</bcp14> inclu de Certificates that include the noRevAvail extension <bcp14>MUST NOT</bcp14> inclu de
certificate extensions that point to Certificate Revocation List (CRL) certificate extensions that point to CRL
repositories or provide locations of Online Certificate Status Protocol repositories or provide locations of OCSP responders. If the noRevAvail extensi
(OCSP) Responders. If the noRevAvail extension is present in a on is present in a
certificate, then:</t> certificate, then:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The certificate <bcp14>MUST NOT</bcp14> also include the basic cons traints certificate extension with the cA BOOLEAN set to TRUE; see Section 4.2.1 .9 of <xref target="RFC5280"/>.</t> <t>The certificate <bcp14>MUST NOT</bcp14> also include the basic cons traints certificate extension with the cA BOOLEAN set to TRUE; see <xref target= "RFC5280" sectionFormat="of" section="4.2.1.9"/>.</t>
</li> </li>
<li> <li>
<t>The certificate <bcp14>MUST NOT</bcp14> also include the CRL Distri bution Points certificate extension; see Section 4.2.1.13 of <xref target="RFC52 80"/>.</t> <t>The certificate <bcp14>MUST NOT</bcp14> also include the CRL Distri bution Points certificate extension; see <xref target="RFC5280" sectionFormat="o f" section="4.2.1.13"/>.</t>
</li> </li>
<li> <li>
<t>The certificate <bcp14>MUST NOT</bcp14> also include the Freshest C RL certificate extension; see Section 4.2.1.15 of <xref target="RFC5280"/>.</t> <t>The certificate <bcp14>MUST NOT</bcp14> also include the Freshest C RL certificate extension; see <xref target="RFC5280" sectionFormat="of" section= "4.2.1.15"/>.</t>
</li> </li>
<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> <t>The Authority Information Access certificate extension, if present, <bcp14>MUST NOT</bcp14> include an id-ad-ocsp accessMethod; see <xref target="R FC5280" sectionFormat="of" section="4.2.2.1"/>.</t>
</li> </li>
</ul> </ul>
<t>If any of the above bullets is violated in a certificate, then <t>If any of the above are violated in a certificate, then
the relying party <bcp14>MUST</bcp14> consider the certificate invalid.</t> the relying party <bcp14>MUST</bcp14> consider the certificate invalid.</t>
</section> </section>
<section anchor="certification-path-validation"> <section anchor="certification-path-validation">
<name>Certification Path Validation</name> <name>Certification Path Validation</name>
<t><xref section="6.1.3" sectionFormat="of" target="RFC5280"/> describes b asic certificate processing within <t><xref section="6.1.3" sectionFormat="of" target="RFC5280"/> describes b asic certificate processing within
the certification path validation procedures. In particular, Step (a)(3) says:< /t> the certification path validation procedures. In particular, Step (a)(3) says:< /t>
<ul empty="true"> <blockquote>
<li>
<artwork><![CDATA[
At the current time, the certificate is not revoked. This At the current time, the certificate is not revoked. This
may be determined by obtaining the appropriate CRL may be determined by obtaining the appropriate CRL
(Section 6.3), by status information, or by out-of-band (Section <xref target="RFC5280" section="6.3" sectionFormat="bare"/>), by status information, or by out-of-band
mechanisms. mechanisms.
]]></artwork> </blockquote>
</li> <t>If the noRevAvail certificate extension specified in this document
</ul>
<t>If the noRevAvail certificate extension that is specified in this docum
ent
is present or the ocsp-nocheck certificate extension <xref target="RFC6960"/> is present, is present or the ocsp-nocheck certificate extension <xref target="RFC6960"/> is present,
then Step (a)(3) is skipped. Otherwise, revocation status determination of then Step (a)(3) is skipped. Otherwise, revocation status determination of the
certificate is performed.</t> certificate is performed.</t>
</section> </section>
<section anchor="asn1-mod"> <section anchor="asn1-mod">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>This section provides an ASN.1 module <xref target="X.680"/> for the no RevAvail <t>This section provides an ASN.1 module <xref target="X.680"/> for the no RevAvail
certificate extension, and it follows the conventions established certificate extension, and it follows the conventions established
in <xref target="RFC5912"/> and <xref target="RFC6268"/>.</t> in <xref target="RFC5912"/> and <xref target="RFC6268"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[ <sourcecode type="asn.1" markers="true"><![CDATA[
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 line 247 skipping to change at line 248
id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 } id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 }
END END
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="sec-cons"> <section anchor="sec-cons">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations in <xref target="RFC5280"/> are relevant.</ t> <t>The Security Considerations in <xref target="RFC5280"/> are relevant.</ t>
<t>When the noRevAvail certificate extension is included in a certificate, <t>When the noRevAvail certificate extension is included in a certificate,
all revocation checking is bypassed. CA policies and practices <bcp14>MUST</bcp 14> ensure all revocation checking is bypassed. CA policies and practices <bcp14>MUST</bcp 14> ensure
that the noRevAvail is included only when appropriate, as any misuse or that the noRevAvail certificate extension is included only when appropriate, as any misuse or
misconfiguration could result in a relying party continuing to trust misconfiguration could result in a relying party continuing to trust
a revoked certificate. When such mis-use is discovered, the only possible a revoked certificate. When such misuse is discovered, the only possible
remediation is the revocation of the CA.</t> remediation is the revocation of the CA.</t>
<t>Some applications may have dependencies on revocation information or as sume <t>Some applications may have dependencies on revocation information or as sume
its availability. The absence of revocation information may require modification s its availability. The absence of revocation information may require modification s
or alternative configuration settings to ensure proper application security and or alternative configuration settings to ensure proper application security and
functionality.</t> functionality.</t>
<t>The absence of revocation information limits the ability of relying <t>The absence of revocation information limits the ability of relying
parties to detect compromise of end-entity keying material or malicious parties to detect compromise of end-entity keying material or malicious
certificates. It also limits the ability to detect CAs not following certificates. It also limits their ability to detect CAs that are not following
the security practices, certificate issuance policies, and operational the security practices, certificate issuance policies, and operational
controls that are specified in the Certificate Policy (CP) or the controls that are specified in the Certificate Policy (CP) or the
Certification Practices Statement (CPS) <xref target="RFC3647"/>.</t> Certification Practices Statement (CPS) <xref target="RFC3647"/>.</t>
<t>Since the absence of revocation information may limit the ability to <t>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 capabilities.</t> monitor CA performance, and observe CA incident response capabilities.</t>
<section anchor="short-lived-certificates"> <section anchor="short-lived-certificates">
<name>Short-lived Certificates</name> <name>Short-Lived Certificates</name>
<t>No revocation information is made available for short-lived certifica tes <t>No revocation information is made available for short-lived certifica tes
because the certificate validity period is shorter than the time needed to because the certificate validity period is shorter than the time needed to
detect, report, and distribute revocation information. If the noRevAvail detect, report, and distribute revocation information. If the noRevAvail
certificate extension is incorrectly used for a certificate validity certificate extension is incorrectly used for a certificate validity
period that is not adequately short, it creates a window of opportunity for period that is not adequately short, it creates a window of opportunity for
attackers to exploit a compromised private key. Therefore, it is crucial attackers to exploit a compromised private key. Therefore, it is crucial
to carefully assess and set an appropriate certificate validity period to carefully assess and set an appropriate certificate validity period
before implementing the noRevAvail certificate extension.</t> before implementing the noRevAvail certificate extension.</t>
</section> </section>
<section anchor="long-lived-certificates"> <section anchor="long-lived-certificates">
<name>Long-lived Certificates</name> <name>Long-Lived Certificates</name>
<t>No revocation information is made available for some long-lived certi ficates <t>No revocation information is made available for some long-lived certi ficates
that contain information that never changes. For example, IDevID certificates that contain information that never changes. For example, IDevID certificates
<xref target="IEEE802.1AR"/> are included in devices at the factory, and they ar e used to <xref target="IEEE802.1AR"/> are included in devices at the factory, and they ar e used to
obtain LDevID certificates <xref target="IEEE802.1AR"/> in an operational enviro nment. In this obtain LDevID certificates <xref target="IEEE802.1AR"/> in an operational enviro nment. In this
case, cryptographic algorithms need to be chosen that are expected to remain sec case, cryptographic algorithms that are expected to remain secure
ure for the expected lifetime of the device need to be chosen. If the noRevAvail cer
to the expected lifetime of the device. If the noRevAvail certificate extension tificate extension is
is
used, the CA has no means of notifying the relying party about compromise of the used, the CA has no means of notifying the relying party about compromise of the
factory-installed keying material.</t> factory-installed keying material.</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>For the ASN.1 Module in <xref target="asn1-mod"/>, IANA is requested to <t>IANA has assigned the following object identifier (OID) for the ASN.1 m
assign an odule (see <xref target="asn1-mod"/>) within the "SMI Security for PKIX Module I
object identifier (OID) for the module identifier. The OID for the module dentifier"
should be allocated in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:</t>
registry (1.3.6.1.5.5.7.0), and the Description for the new OID should be set
to "id-mod-noRevAvail".</t> <table anchor="iana-table">
</section> <name></name>
<section anchor="acknowledgements"> <thead>
<name>Acknowledgements</name> <tr>
<t>Many thanks to Erik Anderson for his efforts to make the noRevAvail <th>Decimal</th>
certificate extension available for use with public key end-entity <th>Description</th>
certificates as well as attribute certificates.</t> </tr>
<t>Many thanks to (in alphabetical order) </thead>
Corey Bonnell, <tbody>
Hendrik Brockhaus, <tr>
Tim Hollebeek, <td>110</td>
Mike Ounsworth, <td>id-mod-noRevAvail</td>
Seo Suchan, </tr>
Carl Wallace, </tbody>
Éric Vyncke, and </table>
Paul Wouters
for their review and insightful comments.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5280">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<title>Internet X.509 Public Key Infrastructure Certificate and Cert 80.xml"/>
ificate 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 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="X.509-2019-TC2" target="https://www.itu.int/rec/T-REC -X.509-202310-I!Cor2"> <reference anchor="X.509-2019-TC2" target="https://www.itu.int/rec/T-REC -X.509-202310-I!Cor2">
<front> <front>
<title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks -- Technical Corrige ndum 2</title> <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks -- Technical Corrige ndum 2</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2023" month="October"/> <date year="2023" month="October"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.509-2019/Cor.2-2023"/ > <seriesInfo name="ITU-T Recommendation" value="X.509-2019/Cor.2-2023"/ >
</reference> </reference>
skipping to change at line 358 skipping to change at line 345
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference> </reference>
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690"> <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
<front> <front>
<title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1-2021"/> <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
</reference> </reference>
<reference anchor="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 119.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 174.xml"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IEEE802.1AR" target="https://ieeexplore.ieee.org/docu ment/8423794"> <reference anchor="IEEE802.1AR" target="https://ieeexplore.ieee.org/docu ment/8423794">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secu re Device Identity</title> <title>IEEE Standard for Local and Metropolitan Area Networks - Secu re Device Identity</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2018" month="July" day="31"/> <date year="2018" month="August" day="02"/>
</front> </front>
<seriesInfo name="IEEE" value="802.1AR-2018"/> <seriesInfo name="IEEE" value="802.1AR-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
</reference> </reference>
<reference anchor="RFC2459">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>Internet X.509 Public Key Infrastructure Certificate and CRL 459.xml"/>
Profile</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="R. Housley" initials="R." surname="Housley"/> 281.xml"/>
<author fullname="W. Ford" initials="W." surname="Ford"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="W. Polk" initials="W." surname="Polk"/> 647.xml"/>
<author fullname="D. Solo" initials="D." surname="Solo"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<date month="January" year="1999"/> 912.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>This memo profiles the X.509 v3 certificate and X.509 v2 CRL fo 268.xml"/>
r use in the Internet. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</abstract> 960.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="RFC" value="2459"/> 555.xml"/>
<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 Attri
bute Certificates in Internet Protocols. Attribute certificates may be used in a
wide range of applications and environments covering a broad spectrum of intero
perability goals and a broader spectrum of operational and assurance requirement
s. The goal of this document is to establish a common baseline for generic appli
cations requiring broad interoperability as well as limited special purpose requ
irements. The profile places emphasis on attribute certificate support for Inter
net 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 a
nd 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 cer
tificate policies or certification practice statements for participants within p
ublic 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 w
riter's discretion) need to be covered in a certificate policy or a certificatio
n 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.5
09 (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 fo
rmat, 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 c
hanges to any of the formats; this is simply a change to the syntax. This docume
nt is not an Internet Standards Track specification; it is published for informa
tional 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 Sy
ntax (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 associa
ted 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 co
nform 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 s
imply a change to the syntax. This document is not an Internet Standards Track s
pecification; 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 S
tatus 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 cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (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 u
sed for a number of purposes, the most significant of which is the authenticatio
n of domain names. Thus, certification authorities (CAs) in the Web PKI are trus
ted to verify that an applicant for a certificate legitimately represents the do
main name(s) in the certificate. As of this writing, this verification is done t
hrough a collection of ad hoc mechanisms. This document describes a protocol tha
t a CA and an applicant can use to automate the process of verification and cert
ificate issuance. The protocol also provides facilities for other certificate ma
nagement functions, such as certificate revocation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8555"/>
<seriesInfo name="DOI" value="10.17487/RFC8555"/>
</reference>
<reference anchor="X.509-1988" target="https://www.itu.int/rec/T-REC-X.5 09-198811-S"> <reference anchor="X.509-1988" target="https://www.itu.int/rec/T-REC-X.5 09-198811-S">
<front> <front>
<title>Series X: Data Communication Networks: Directory -- The Direc tory -- Authentication Framework</title> <title>The Directory - Authentication Framework</title>
<author> <author>
<organization>CCITT</organization> <organization>CCITT</organization>
</author> </author>
<date year="1988" month="November"/> <date year="1988" month="November"/>
</front> </front>
<seriesInfo name="CCITT Recommendation" value="X.509-1988"/> <seriesInfo name="CCITT Recommendation" value="X.509-1988"/>
</reference> </reference>
<reference anchor="X.509-1997" target="https://www.itu.int/rec/T-REC-X.5 09-199708-S"> <reference anchor="X.509-1997" target="https://www.itu.int/rec/T-REC-X.5 09-199708-S">
<front> <front>
<title>Information Technology -- Open Systems Interconnection -- The Directory: Authentication framework</title> <title>Information technology -- Open Systems Interconnection -- The Directory: Authentication framework</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="1997" month="August"/> <date year="1997" month="August"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.509-1997"/> <seriesInfo name="ITU-T Recommendation" value="X.509-1997"/>
</reference> </reference>
<reference anchor="X.509-2000" target="https://www.itu.int/rec/T-REC-X.5 09-200003-S"> <reference anchor="X.509-2000" target="https://www.itu.int/rec/T-REC-X.5 09-200003-S">
<front> <front>
<title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title> <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2000" month="March"/> <date year="2000" month="March"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.509-2000"/> <seriesInfo name="ITU-T Recommendation" value="X.509-2000"/>
</reference> </reference>
skipping to change at line 550 skipping to change at line 428
<reference anchor="X.509-2019" target="https://www.itu.int/rec/T-REC-X.5 09-201910-I"> <reference anchor="X.509-2019" target="https://www.itu.int/rec/T-REC-X.5 09-201910-I">
<front> <front>
<title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title> <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2019" month="October"/> <date year="2019" month="October"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.509-2019"/> <seriesInfo name="ITU-T Recommendation" value="X.509-2019"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Erik Anderson"/> for his efforts to m
ake 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>
</back> </back>
<!-- ##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
</rfc> </rfc>
 End of changes. 54 change blocks. 
425 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.48.