rfc9925.original.xml   rfc9925.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!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.29 (Ruby 3.4. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 2.5.
4) --> 9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-lamps-x509-alg-none-10" category="std" consensus="true" submissionType="IE -ietf-lamps-x509-alg-none-latest" category="std" consensus="true" submissionType
TF" updates="5280" tocInclude="true" sortRefs="true" symRefs="true" version="3"> ="IETF" xml:lang="en" number="9925" updates="5280" tocInclude="true" sortRefs="t
<!-- xml2rfc v2v3 conversion 3.30.1 --> rue" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.31.0 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-alg-none-la
test" rel="prev"/>
<front> <front>
<title>Unsigned X.509 Certificates</title> <title>Unsigned X.509 Certificates</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-x509-alg-none-10"/ > <seriesInfo name="RFC" value="9925"/>
<author initials="D." surname="Benjamin" fullname="David Benjamin"> <author initials="D." surname="Benjamin" fullname="David Benjamin">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>davidben@google.com</email> <email>davidben@google.com</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="05"/> <date year="2026" month="February"/>
<area>Security</area> <area>SEC</area>
<workgroup>Limited Additional Mechanisms for PKIX and SMIME</workgroup> <workgroup>lamps</workgroup>
<keyword>self-signed certificate</keyword> <keyword>self-signed certificate</keyword>
<abstract> <abstract>
<?line 55?> <?line 56?>
<t>This document defines a placeholder X.509 signature algorithm that may be use d <t>This document defines a placeholder X.509 signature algorithm that may be use d
in contexts where the consumer of the certificate is not expected to verify the in contexts where the consumer of the certificate is not expected to verify the
signature. As part of this, it updates RFC 5280.</t> signature. As part of this, it updates RFC 5280.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
davidben.github.io/x509-alg-none/draft-ietf-lamps-x509-alg-none.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-lamps-x509-alg-none/"/>.
</t>
<t>
Discussion of this document takes place on the
Limited Additional Mechanisms for PKIX and SMIME Working Group mailing l
ist (<eref target="mailto:spasm@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/spasm/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/davidben/x509-alg-none"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 61?> <?line 62?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>An X.509 certificate <xref target="RFC5280"/> relates two entities in t he PKI: information <t>An X.509 certificate <xref target="RFC5280"/> relates two entities in t he PKI: information
about a subject and a proof from an issuer. Viewing the PKI as a graph with about a subject and a proof from an issuer. Viewing the PKI as a graph with
entities as nodes, as in <xref target="RFC4158"/>, a certificate is an edge betw een the entities as nodes, as in <xref target="RFC4158"/>, a certificate is an edge betw een the
subject and issuer.</t> subject and issuer.</t>
<t>In some contexts, an application needs standalone subject information i nstead of <t>In some contexts, an application needs standalone subject information i nstead of
a certificate. In the graph model, the application needs a node, not an edge. a certificate. In the graph model, the application needs a node, not an edge.
For example, certification path validation (<xref section="6" sectionFormat="of" target="RFC5280"/>) begins at For example, certification path validation (<xref section="6" sectionFormat="of" target="RFC5280"/>) begins at
a trust anchor, or root certification authority (root CA). The application a trust anchor or root certification authority (root CA). The application
trusts this trust anchor information out-of-band and does not require an trusts this trust anchor information out-of-band and does not require an
issuer's signature.</t> issuer's signature.</t>
<t>X.509 does not define a structure for this scenario. Instead, X.509 tru st <t>X.509 does not define a structure for this scenario. Instead, X.509 tru st
anchors are often represented with "self-signed" certificates, where the anchors are often represented with "self-signed" certificates, where the
subject's key signs over itself. Other formats, such as <xref target="RFC5914"/> exist to subject's key signs over itself. Other formats, such as <xref target="RFC5914"/> , exist to
convey trust anchors, but self-signed certificates remain widely used.</t> convey trust anchors, but self-signed certificates remain widely used.</t>
<t>Additionally, some TLS <xref target="RFC8446"/> server deployments use self-signed <t>Additionally, some TLS <xref target="RFC8446"/> server deployments use self-signed
end entity certificates when they do not intend to present a CA-issued end entity certificates when they do not intend to present a CA-issued
identity, instead expecting the relying party to authenticate the certificate identity, instead expecting the relying party to authenticate the certificate
out-of-band, e.g. via a known fingerprint.</t> out-of-band, e.g., via a known fingerprint.</t>
<t>These self-signatures typically have no security value, aren't checked by <t>These self-signatures typically have no security value, aren't checked by
the receiver, and only serve as placeholders to meet syntactic requirements of the receiver, and only serve as placeholders to meet syntactic requirements of
an X.509 certificate.</t> an X.509 certificate.</t>
<t>Computing signatures as placeholders has some drawbacks:</t> <t>Computing signatures as placeholders has some drawbacks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Post-quantum signature algorithms are large, so including a self-si gnature <t>Post-quantum signature algorithms are large, so including a self-si gnature
significantly increases the size of the payload.</t> significantly increases the size of the payload.</t>
</li> </li>
<li> <li>
<t>If the subject is an end entity, rather than a CA, computing an X.5 09 <t>If the subject is an end entity, rather than a CA, computing an X.5 09
signature risks cross-protocol attacks with the intended use of the key.</t> signature risks cross-protocol attacks with the intended use of the key.</t>
</li> </li>
<li> <li>
<t>It is ambiguous whether such a self-signature requires the CA bit i n basic <t>It is ambiguous whether such a self-signature requires the CA bit i n basic
constraints or keyCertSign in key usage. If the key is intended for a constraints or keyCertSign in key usage. If the key is intended for a
non-X.509 use, asserting those capabilities is an unnecessary risk.</t> non-X.509 use, asserting those capabilities is an unnecessary risk.</t>
</li> </li>
<li> <li>
<t>If the subject is an end entity, and the end entity's key is not a signing <t>If the subject is an end entity, and the end entity's key is not a signing
key (e.g. a KEM key), there is no valid signature algorithm to use with the key. </t> key (e.g., a Key Encapsulation Mechanism (KEM) key), there is no valid signature algorithm to use with the key.</t>
</li> </li>
</ul> </ul>
<t>This document defines a profile for unsigned X.509 certificates, which may be <t>This document defines a profile for unsigned X.509 certificates, which may be
used when the certificate is used as a container for subject information, used when the certificate is used as a container for subject information,
without any specific issuer.</t> without any specific issuer.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="requirements-language">
<name>Conventions and Definitions</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < ",
xref target="RFC8174"/> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</section> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<?line -18?>
</section>
<section anchor="constructing-unsigned-certificates"> <section anchor="constructing-unsigned-certificates">
<name>Constructing Unsigned Certificates</name> <name>Constructing Unsigned Certificates</name>
<t>This section describes how a sender constructs an unsigned certificate. </t> <t>This section describes how a sender constructs an unsigned certificate. </t>
<section anchor="signature"> <section anchor="signature">
<name>Signature</name> <name>Signature</name>
<t>To construct an unsigned X.509 certificate, the sender MUST set the <t>To construct an unsigned X.509 certificate, the sender <bcp14>MUST</b cp14> set the
Certificate's signatureAlgorithm and TBSCertificate's signature fields each to Certificate's signatureAlgorithm and TBSCertificate's signature fields each to
an AlgorithmIdentifier with algorithm id-alg-unsigned, defined below:</t> an AlgorithmIdentifier with algorithm id-alg-unsigned, defined below:</t>
<artwork><![CDATA[ <artwork><![CDATA[
id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36} id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}
]]></artwork> ]]></artwork>
<t>The parameters for id-alg-unsigned MUST be omitted. The Certificate's <t>The parameters for id-alg-unsigned <bcp14>MUST</bcp14> be omitted. Th
signatureValue field MUST be a BIT STRING of length zero.</t> e Certificate's
signatureValue field <bcp14>MUST</bcp14> be a BIT STRING of length zero.</t>
</section> </section>
<section anchor="issuer"> <section anchor="issuer">
<name>Issuer</name> <name>Issuer</name>
<t>An unsigned certificate takes the place of a self-signed certificate in <t>An unsigned certificate takes the place of a self-signed certificate in
scenarios where the application only requires subject information. It has no scenarios where the application only requires subject information. It has no
issuer, so some requirements in the profile defined in <xref target="RFC5280"/> cannot issuer, so some requirements in the profile defined in <xref target="RFC5280"/> cannot
meaningfully be applied. However, the application may have pre-existing meaningfully be applied. However, the application may have pre-existing
requirements derived from <xref target="X.509"/> and <xref target="RFC5280"/>, s o senders MAY construct requirements derived from <xref target="X.509"/> and <xref target="RFC5280"/>, s o senders <bcp14>MAY</bcp14> construct
the certificate as if it were a self-signed certificate, if needed for the certificate as if it were a self-signed certificate, if needed for
interoperability.</t> interoperability.</t>
<t>In particular, the following fields describe a certificate's issuer:< /t> <t>In particular, the following fields describe a certificate's issuer:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>issuer (<xref section="4.1.2.4" sectionFormat="of" target="RFC528 0"/>)</t> <t>issuer (<xref section="4.1.2.4" sectionFormat="of" target="RFC528 0"/>)</t>
</li> </li>
<li> <li>
<t>issuerUniqueID (<xref section="4.1.2.8" sectionFormat="of" target ="RFC5280"/>)</t> <t>issuerUniqueID (<xref section="4.1.2.8" sectionFormat="of" target ="RFC5280"/>)</t>
</li> </li>
</ul> </ul>
<t>The issuer field is not optional, and both <xref target="X.509"/> and <t>The issuer field is not optional, and both <xref target="X.509"/> and
<xref section="4.1.2.4" sectionFormat="of" target="RFC5280"/> forbid empty issue rs, so such a value may not be <xref section="4.1.2.4" sectionFormat="of" target="RFC5280"/> forbid empty issue rs, so such a value may not be
interoperable with existing applications.</t> interoperable with existing applications.</t>
<t>If the subject is not empty, senders MAY set the issuer to the subjec <t>If the subject is not empty, senders <bcp14>MAY</bcp14> set the issue
t, similar r to the subject, similar
how they would construct a self-signed certificate. to how they would construct a self-signed certificate.
This may be useful in applications that, for example, This may be useful in applications that, for example,
expect trust anchors to have matching issuer and subject. This is, however, a expect trust anchors to have a matching issuer and subject. This is, however, a
placeholder value. The unsigned certificate is not considered self-signed or placeholder value. The unsigned certificate is not considered self-signed or
self-issued.</t> self-issued.</t>
<t>Senders MAY alternatively use a short placeholder issuer consisting o <t>Senders <bcp14>MAY</bcp14> alternatively use a short placeholder issu
f a single er consisting of a single
relative distinguished name, with a single attribute of type id-rdna-unsigned relative distinguished name that has a single attribute with a type of id-rdna-u
and value a zero-length UTF8String. id-rdna-unsigned is defined as follows:</t> nsigned
and value of a zero-length UTF8String. id-rdna-unsigned is defined as follows:</
t>
<artwork><![CDATA[ <artwork><![CDATA[
id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 TBD1 TBD2} id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}
]]></artwork> ]]></artwork>
<t>This placeholder name, in the string representation of <xref target=" RFC4514"/>, is:</t> <t>This placeholder name, in the string representation of <xref target=" RFC4514"/>, is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
1.3.6.1.5.5.7.TBD1.TBD2=#0C00 1.3.6.1.5.5.7.25.1=#0C00
]]></artwork> ]]></artwork>
<t>Senders MUST omit the issuerUniqueID field, as it is optional, not ap plicable, <t>Senders <bcp14>MUST</bcp14> omit the issuerUniqueID field, as it is o ptional, not applicable,
and already forbidden by <xref section="4.1.2.8" sectionFormat="of" target="RFC5 280"/>.</t> and already forbidden by <xref section="4.1.2.8" sectionFormat="of" target="RFC5 280"/>.</t>
</section> </section>
<section anchor="extensions"> <section anchor="extensions">
<name>Extensions</name> <name>Extensions</name>
<t>Some X.509 extensions also describe the certificate issuer and thus a re not <t>Some X.509 extensions also describe the certificate issuer and thus a re not
meaningful for an unsigned certificate:</t> meaningful for an unsigned certificate:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>authority key identifier (<xref section="4.2.1.1" sectionFormat=" of" target="RFC5280"/>)</t> <t>authority key identifier (<xref section="4.2.1.1" sectionFormat=" of" target="RFC5280"/>)</t>
</li> </li>
<li> <li>
<t>issuer alternative name (<xref section="4.2.1.7" sectionFormat="o f" target="RFC5280"/>)</t> <t>issuer alternative name (<xref section="4.2.1.7" sectionFormat="o f" target="RFC5280"/>)</t>
</li> </li>
</ul> </ul>
<t>Senders SHOULD omit the authority key identifier and issuer alternati ve name <t>Senders <bcp14>SHOULD</bcp14> omit the authority key identifier and i ssuer alternative name
extensions. <xref section="4.2.1.1" sectionFormat="of" target="RFC5280"/> requir es certificates to include extensions. <xref section="4.2.1.1" sectionFormat="of" target="RFC5280"/> requir es certificates to include
the authority key identifier, but includes an exception for self-signed certific ates the authority key identifier, but it permits an exception for self-signed certif icates
used when distributing a public key. This document updates <xref target="RFC5280 "/> to also used when distributing a public key. This document updates <xref target="RFC5280 "/> to also
permit omitting authority key identifier in unsigned certificates.</t> permit omitting the authority key identifier in unsigned certificates.</t>
<t>Some extensions reflect whether the subject is a CA or an end entity: </t> <t>Some extensions reflect whether the subject is a CA or an end entity: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>key usage (<xref section="4.2.1.3" sectionFormat="of" target="RFC 5280"/>)</t> <t>key usage (<xref section="4.2.1.3" sectionFormat="of" target="RFC 5280"/>)</t>
</li> </li>
<li> <li>
<t>basic constraints (<xref section="4.2.1.9" sectionFormat="of" tar get="RFC5280"/>)</t> <t>basic constraints (<xref section="4.2.1.9" sectionFormat="of" tar get="RFC5280"/>)</t>
</li> </li>
</ul> </ul>
<t>Senders SHOULD fill in these values to reflect the subject. That is:< <t>Senders <bcp14>SHOULD</bcp14> fill in these values to reflect the sub
/t> ject. That is:</t>
<t>If the subject is a CA, it SHOULD assert the keyCertSign key usage bi <ul spacing="normal">
t and <li>
SHOULD include a basic constraints extensions that sets the cA boolean to TRUE.< <t>If the subject is a CA, it <bcp14>SHOULD</bcp14> assert the keyCe
/t> rtSign key usage bit and
<t>If the subject is an end entity, it SHOULD NOT assert the keyCertSign <bcp14>SHOULD</bcp14> include a basic constraints extension that sets the cA boo
key usage lean to TRUE.</t>
bit, and it SHOULD either omit the basic constraints extension or set the cA </li>
<li>
<t>If the subject is an end entity, it <bcp14>SHOULD NOT</bcp14> ass
ert the keyCertSign key usage
bit, and it <bcp14>SHOULD</bcp14> either omit the basic constraints extension or
set the cA
boolean to FALSE. Unlike a self-signed certificate, an unsigned certificate does boolean to FALSE. Unlike a self-signed certificate, an unsigned certificate does
not issue itself, so there is no need to accommodate a self-signature in either not issue itself, so there is no need to accommodate a self-signature in either
extension.</t> extension.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="consuming-unsigned-certificates"> <section anchor="consuming-unsigned-certificates">
<name>Consuming Unsigned Certificates</name> <name>Consuming Unsigned Certificates</name>
<t>X.509 signatures of type id-alg-unsigned are always invalid:</t> <t>X.509 signatures of type id-alg-unsigned are always invalid:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>When processing X.509 certificates without verifying signatures, re ceivers MAY <t>When processing X.509 certificates without verifying signatures, re ceivers <bcp14>MAY</bcp14>
accept id-alg-unsigned.</t> accept id-alg-unsigned.</t>
</li> </li>
<li> <li>
<t>When verifying X.509 signatures, receivers MUST reject id-alg-unsig ned.</t> <t>When verifying X.509 signatures, receivers <bcp14>MUST</bcp14> reje ct id-alg-unsigned.</t>
</li> </li>
</ul> </ul>
<t>In particular, X.509 validators MUST NOT accept id-alg-unsigned in the place of <t>In particular, X.509 validators <bcp14>MUST NOT</bcp14> accept id-alg-u nsigned in the place of
a signature in the certification path.</t> a signature in the certification path.</t>
<t>It is expected that most unmodified X.509 applications will already be <t>It is expected that most unmodified X.509 applications will already be
compliant with this guidance. X.509 applications are thus RECOMMENDED to satisfy compliant with this guidance. X.509 applications are thus <bcp14>RECOMMENDED</bc
these p14> to satisfy these
requirements by ignoring this document, and instead treating id-alg-unsigned as requirements by ignoring this document and instead treating id-alg-unsigned as
the same as an unrecognized signature algorithm. An unmodified X.509 the same as an unrecognized signature algorithm. An unmodified X.509
validator will be unable to verify the signature (Step (a.1) of validator will be unable to verify the signature (Step (a.1) of
<xref section="6.1.3" sectionFormat="of" target="RFC5280"/>) and thus reject the certification path. <xref section="6.1.3" sectionFormat="of" target="RFC5280"/>) and thus reject the certification path.
Conversely, in contexts where an X.509 application was ignoring the Conversely, in contexts where an X.509 application was ignoring the
self-signature, id-alg-unsigned will also be ignored, but more efficiently.</t> self-signature, id-alg-unsigned will also be ignored but more efficiently.</t>
<t>In other contexts, an application may require modifications, or limit i <t>In other contexts, an application may require modifications or limit it
tself to self to
particular forms of unsigned certificate. For example, an application might particular forms of unsigned certificates. For example, an application might
check self-signedness to classify locally-configured certificates as trust check self-signedness to classify locally configured certificates as trust
anchors or untrusted intermediates. Such an application may need to modify its anchors or untrusted intermediates. Such an application may need to modify its
configuration model or user interface before using an unsigned certificate as a configuration model or user interface before using an unsigned certificate as a
trust anchor.</t> trust anchor.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>It is best practice to limit cryptographic keys to a single purpose eac h. If a <t>It is best practice to limit cryptographic keys to a single purpose eac h. If a
key is reused across contexts, applications risk cross-protocol attacks when the key is reused across contexts, applications risk cross-protocol attacks when the
two uses collide. However, in applications that use self-signed end entity two uses collide. However, in applications that use self-signed end entity
certificates, the subject's key is necessarily used in two ways: the X.509 certificates, the subject's key is necessarily used in two ways: the X.509
self-signature, and the end entity protocol. Unsigned certificates fix this key self-signature and the end entity protocol. Unsigned certificates fix this key
reuse by removing the X.509 self-signature.</t> reuse by removing the X.509 self-signature.</t>
<t>If an application accepts id-alg-unsigned as part of a certification pa th, or <t>If an application accepts id-alg-unsigned as part of a certification pa th, or
in any other context where it is necessary to verify the X.509 signature, the in any other context where it is necessary to verify the X.509 signature, the
signature check would be bypassed. Thus, <xref target="consuming-unsigned-certif icates"/> signature check would be bypassed. Thus, <xref target="consuming-unsigned-certif icates"/>
prohibits this and recommends that applications treat id-alg-unsigned the same prohibits this and recommends that applications treat id-alg-unsigned the same
as any other previously unrecognized signature algorithm. Non-compliant as any other previously unrecognized signature algorithm. Non-compliant
applications risk vulnerabilities analogous to those described in <xref target=" JWT"/> and applications risk vulnerabilities analogous to those described in <xref target=" JWT"/> and
<xref section="1.1" sectionFormat="of" target="I-D.ietf-jose-deprecate-none-rsa1 5"/>.</t> <xref section="1.1" sectionFormat="of" target="I-D.ietf-jose-deprecate-none-rsa1 5"/>.</t>
<t>The signature in a self-signed certificate is self-derived and thus of limited <t>The signature in a self-signed certificate is self-derived and thus of limited
use to convey trust. However, some applications might use it as an integrity use to convey trust. However, some applications might, for example, use it as an
check to guard against accidental storage corruption, etc. An unsigned integrity
check to guard against accidental storage corruption. An unsigned
certificate does not provide any integrity check. Applications checking certificate does not provide any integrity check. Applications checking
self-signature for integrity SHOULD instead use some other mechanism, such as an self-signature for integrity <bcp14>SHOULD</bcp14> instead use some other mechan
external hash that is verified out of band.</t> ism, such as an
external hash that is verified out-of-band.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="module-identifier"> <section anchor="module-identifier">
<name>Module Identifier</name> <name>Module Identifier</name>
<t>IANA is requested to add the following entry in the "SMI Security for PKIX <t>IANA has added the following entry in the "SMI Security for PKIX
Module Identifier" registry, defined by <xref target="RFC7299"/>:</t> Module Identifier" registry, defined by <xref target="RFC7299"/>:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD</td> <td align="left">122</td>
<td align="left">id-mod-algUnsigned-2025</td> <td align="left">id-mod-algUnsigned-2025</td>
<td align="left">[this-RFC]</td> <td align="left">RFC 9925</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="algorithm"> <section anchor="algorithm">
<name>Algorithm</name> <name>Algorithm</name>
<t>IANA is requested to add the following entry to the <t>IANA has added the following entry to the
"SMI Security for PKIX Algorithms" registry <xref target="RFC7299"/>:</t> "SMI Security for PKIX Algorithms" registry <xref target="RFC7299"/>:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">36</td> <td align="left">36</td>
<td align="left">id-alg-unsigned</td> <td align="left">id-alg-unsigned</td>
<td align="left">[this-RFC]</td> <td align="left">RFC 9925</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="relative-distinguished-name-attribute"> <section anchor="relative-distinguished-name-attribute">
<name>Relative Distinguished Name Attribute</name> <name>Relative Distinguished Name Attribute</name>
<t>To allocate id-rdna-unsigned, this document introduces a new PKIX OID arc for <t>To allocate id-rdna-unsigned, this document introduces a new PKIX OID arc for
relative distinguished name attributes:</t> relative distinguished name attributes:</t>
<t>IANA is requested to add the following entry to the "SMI Security for PKIX" <t>IANA has added the following entry to the "SMI Security for PKIX"
registry <xref target="RFC7299"/>:</t> registry <xref target="RFC7299"/>:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD1</td> <td align="left">25</td>
<td align="left">Relative Distinguished Name Attribute</td> <td align="left">Relative Distinguished Name Attribute</td>
<td align="left">[this-RFC]</td> <td align="left">RFC 9925</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IANA is requested to create the "SMI Security for PKIX Relative Disti nguished <t>IANA has created the "SMI Security for PKIX Relative Distinguished
Name Attribute" registry within the "Structure of Management Information (SMI) Name Attribute" registry within the "Structure of Management Information (SMI)
Numbers (MIB Module Registrations)" group.</t> Numbers (MIB Module Registrations)" registry group.</t>
<t>The new registry's description is <t>The new registry's description is
"iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.TBD1)".</t> "iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.25)".</t>
<t>The new registry has three columns and is initialized with the follow ing values:</t> <t>The new registry has three columns and is initialized with the follow ing values:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD2</td> <td align="left">1</td>
<td align="left">id-rdna-unsigned</td> <td align="left">id-rdna-unsigned</td>
<td align="left">[this-RFC]</td> <td align="left">RFC 9925</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Future updates to this table are to be made according to the Specific ation <t>Future updates to this table are to be made according to the Specific ation
Required policy as defined in <xref target="RFC8126"/>.</t> Required policy as defined in <xref target="RFC8126"/>.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-jose-deprecate-none-rsa15" to="JOSE"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-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="RFC5912"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 912.xml"/>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
09 (PKIX)</title> 280.xml"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="J. Schaad" initials="J." surname="Schaad"/> 119.xml"/>
<date month="June" year="2010"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 174.xml"/>
<t>The Public Key Infrastructure using X.509 (PKIX) certificate fo <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
rmat, and many associated formats, are expressed using ASN.1. The current ASN.1 126.xml"/>
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="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
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="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 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>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="JWT" target="https://www.howmanydayssinceajwtalgnonev uln.com/"> <reference anchor="JWT" target="https://www.howmanydayssinceajwtalgnonev uln.com/">
<front> <front>
<title>How Many Days Has It Been Since a JWT alg:none Vulnerability? </title> <title>How Many Days Has It Been Since a JWT alg:none Vulnerability? </title>
<author initials="J." surname="Sanderson" fullname="James 'zofrex' S anderson"> <author initials="J." surname="Sanderson" fullname="James 'zofrex' S anderson">
<organization/> <organization/>
</author> </author>
<date year="2024" month="October" day="09"/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="X.509"> <reference anchor="X.509" target="https://www.itu.int/rec/t-rec-x.509/en ">
<front> <front>
<title>Information technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title> <title>Information technology - Open Systems Interconnection - The D irectory: 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="ISO/IEC 9594-8:2020" value=""/> <seriesInfo name="ITU-T Recommendation" value="X.509"/>
</reference> <seriesInfo name="ISO/IEC" value="9594-8:2020"/>
<reference anchor="RFC4158">
<front>
<title>Internet X.509 Public Key Infrastructure: Certification Path
Building</title>
<author fullname="M. Cooper" initials="M." surname="Cooper"/>
<author fullname="Y. Dzambasow" initials="Y." surname="Dzambasow"/>
<author fullname="P. Hesse" initials="P." surname="Hesse"/>
<author fullname="S. Joseph" initials="S." surname="Joseph"/>
<author fullname="R. Nicholas" initials="R." surname="Nicholas"/>
<date month="September" year="2005"/>
<abstract>
<t>This document provides guidance and recommendations to develope
rs building X.509 public-key certification paths within their applications. By f
ollowing the guidance and recommendations defined in this document, an applicati
on developer is more likely to develop a robust X.509 certificate-enabled applic
ation that can build valid certification paths across a wide range of PKI enviro
nments. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4158"/>
<seriesInfo name="DOI" value="10.17487/RFC4158"/>
</reference>
<reference anchor="RFC5914">
<front>
<title>Trust Anchor Format</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="S. Ashmore" initials="S." surname="Ashmore"/>
<author fullname="C. Wallace" initials="C." surname="Wallace"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes a structure for representing trust anch
or information. A trust anchor is an authoritative entity represented by a publi
c key and associated data. The public key is used to verify digital signatures,
and the associated data is used to constrain the types of information or actions
for which the trust anchor is authoritative. The structures defined in this doc
ument are intended to satisfy the format-related requirements defined in Trust A
nchor Management Requirements. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5914"/>
<seriesInfo name="DOI" value="10.17487/RFC5914"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC4514">
<front>
<title>Lightweight Directory Access Protocol (LDAP): String Represen
tation of Distinguished Names</title>
<author fullname="K. Zeilenga" initials="K." role="editor" surname="
Zeilenga"/>
<date month="June" year="2006"/>
<abstract>
<t>The X.500 Directory uses distinguished names (DNs) as primary k
eys to entries in the directory. This document defines the string representation
used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguis
hed names. The string representation is designed to give a clean representation
of commonly used distinguished names, while being able to represent any distingu
ished name. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4514"/>
<seriesInfo name="DOI" value="10.17487/RFC4514"/>
</reference>
<reference anchor="I-D.ietf-jose-deprecate-none-rsa15">
<front>
<title>JOSE: Deprecate 'none' and 'RSA1_5'</title>
<author fullname="Neil Madden" initials="N." surname="Madden">
<organization>Teya</organization>
</author>
<date day="2" month="April" year="2025"/>
<abstract>
<t> This document updates [RFC7518] to deprecate the JWS algorit
hm "none"
and the JWE algorithm "RSA1_5". These algorithms have known security
weaknesses. It also updates the Review Instructions for Designated
Experts to establish baseline security requirements that future
algorithm registrations should meet.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-deprecate-non
e-rsa15-02"/>
</reference>
<reference anchor="RFC7299">
<front>
<title>Object Identifier Registry for the PKIX Working Group</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="July" year="2014"/>
<abstract>
<t>When the Public-Key Infrastructure using X.509 (PKIX) Working G
roup was chartered, an object identifier arc was allocated by IANA for use by th
at working group. This document describes the object identifiers that were assig
ned in that arc, returns control of that arc to IANA, and establishes IANA alloc
ation policies for any future assignments within that arc.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7299"/>
<seriesInfo name="DOI" value="10.17487/RFC7299"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-jose-deprecate-none-rsa15.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
158.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
914.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
299.xml"/>
</references> </references>
</references> </references>
<?line 307?> <?line 322?>
<section anchor="asn1-module"> <section anchor="asn1-module">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<artwork><![CDATA[ <t>This ASN.1 module uses the conventions established by <xref target="RFC
5912"/>.</t>
<sourcecode type="asn.1"><![CDATA[
SignatureAlgorithmNone SignatureAlgorithmNone
{ 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-algUnsigned-2025(TBD) } id-mod-algUnsigned-2025(122) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
SIGNATURE-ALGORITHM SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- in [RFC5912] FROM AlgorithmInformation-2009 -- in [RFC5912]
{ 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-algorithmInformation-02(58) } id-mod-algorithmInformation-02(58) }
skipping to change at line 565 skipping to change at line 420
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) 36 } mechanisms(5) pkix(7) alg(6) 36 }
sa-unsigned SIGNATURE-ALGORITHM ::= { sa-unsigned SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-unsigned IDENTIFIER id-alg-unsigned
PARAMS ARE absent PARAMS ARE absent
} }
id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1) id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) rdna(TBD1) TBD2 } mechanisms(5) pkix(7) rdna(25) 1 }
at-unsigned ATTRIBUTE ::= { at-unsigned ATTRIBUTE ::= {
TYPE UTF8String (SIZE (0)) TYPE UTF8String (SIZE (0))
IDENTIFIED BY id-rdna-unsigned IDENTIFIED BY id-rdna-unsigned
} }
END END
]]></artwork> ]]></sourcecode>
</section> </section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Bob Beck, Nick Harper, and Sophie Schmieg for reviewing an ea <t>Thanks to <contact fullname="Bob Beck"/>, <contact fullname="Nick Harpe
rly r"/>, and <contact fullname="Sophie Schmieg"/> for reviewing an early
iteration of this document. Thanks to Alex Gaynor for providing a link to cite iteration of this document. Thanks to <contact fullname="Alex Gaynor"/> for prov
for <xref target="JWT"/>. Thanks to Russ Housley for additional input.</t> iding a link to cite
for <xref target="JWT"/>. Thanks to <contact fullname="Russ Housley"/> for addit
ional input.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81bWXPbxpZ+71/RQz9YukXCkmx50VQql9ps+mrxiHRyM7fu
QxNokohANIMGRNGK8tvnO6cbG0nZcaamauSyRQK9nPU7S7d7vZ7I4zzRR7Lz
ObXxNNWR/GdwuPdOnugsjydxqHJtO4J+TU22OpI2j4SITJiqOWZFmZrkvVjn
k16i5gvbu8fcnkqmvdSkure/J2wxnsfWxibNVwvMGJyNzqV8JlViDXaN00gv
NP5J805XdnQU5yaLVUJfBv1j/DIZPt2MzjsiLeZjnR2JCMQciWJBv+2RPDx4
uydCk1qd2gLf86zQ4u5IvhQq0wp7DHVYZHG+6oilyW6nmSkWeHoRz+Mc7PYj
7AnyVCIvdThTaWznVk6w7ad/DP4pVRrJ4eXg8qwjbvUKC0RHoietTiY9L6+w
lpS402kB2qT867tI6QTV+RnExulUvqel6PlcxQme24Wy87+TzAOTTemFysIZ
XszyfGGPXrygcfQovtNBOewFPXgxzszS6he8wguaOY3zWTHG3EjdxdFYpy9a
CqQhCUk5byxfDg3c5CA27Ukvvm4UwSyfJx0hVJHPDLQpe9hEyjiF6jqngTzW
6a9qHqcdfuzMrHNKe669AlcQ4xdFYsWQ98ZMEy0vLk7ca+3EVVL79ym/D0Iz
FyI12Rzz7lhVz+R5ZuYyn2nZH14F+3JuogIj8erm/OTw3f7BkRBxOmnO+fjz
6Ih38d7zwSzlpUpX8lStrPygrBzkIFenchinoZaKZsDmp0ckAvlTkaQ6U+M4
gVn+6BZS2VRDzKWUl8tlMDPLORaNsKalZdSvyxxr0BJ3WIF4ecGT2SPkwd7B
K7hcb+8dP6wEjB8n41LKHwM5hMXpzBovy0rQH/HLyudfzCTT98+bwzCOkaHF
d2dQysWkModhpyYx05XsyesFMb+yuYadD9JcZ3DRVIc8sidHkPZpnOE7o8qn
YpzEYQ8exq6g8jyLx0Wum84lJxmIIxe2nQbX11gCsADu9zf5ZisB6Iw+90b8
wOos1pa0WQ4YDK9fDM5O5LvDd696b48gxD0hgiAQotfrSTW2eabCXIjRLLYS
wFfMgVUy0pM4haSUXCQq1DOTQE4eOgkXVF5kmhQONMtnZF0qhwOv5FjLwuoI
BiUhkFzf51YuZxqDyQAJxrBBJs3EfW+wj+1Tk0t9v4DUACm5kXfgZrKikaLa
NJB9Kxcqy90ase3KOJceLcmiGTA9e/M4ihItxDNSUQa7Z/0I0U89L00CHh7+
gxwCsx8fZaYZGGS+NBICAbjhC5giqgFpRzKuLUOosSlyyArB4FcQ73QsF5kB
iRNyPpWCPVvoLJA/xXpJsOcXkoqEPM3UYiaXEKWoNlMkj0iDP8U7Pzz8CPJe
7R++fXzEs3XZYQsdTTUUkC/JMVloDXr8/kIMUmnNXFfq6dJUtVgktBRZb6p1
ZBEIMUsl5M7lMg2WydNyrSIoQbRICSBp5s2xBKzRSZcfbG6hmMEuq92TH4hz
xAx9D1xN8KZemGYtVD6TdyqJI/d95+Fh6D3uNVlDrb5diGEKEuFpIA8R09IO
IfyGAy4Uk6+t7bwKcCV3+O1JfzdgL26QLXghy1bXWrQlGZhCz0x6YzYC/I2M
dpad6d+KmLwmFU4Zz23tS1CMs8hquHNBsipsFbK/UTzlzW2oU5XFhqTNeuh6
e2aqhKMK3GOOmeSwhkwvMo0MghyLzAxhtg7xnaYCYQ+Vv5YGBEIJumi0lQZe
CZej+YG8xqhMOuYx0xbhjMzV2Spiyyu4kr6PIancUBJzh2WaksMc4OBT+YYF
3QhzKUiGGa0YWSCoOtlIVl1nzKOLod/07atXr7EpgJDoRPaVmBVBmqXZzY3g
aZFz7VV7T7DPJryCLlgTMcSWMiB5IUIpJ/0eKxFIF7lFupVPOAgrnRxIsqLP
hFkrWoRMjaaw566hoGhYT1fqYBrIu1hhv9vULFMJi5jqbJGBooAgWzdZYjuy
lF5hKYhGztSdBgMY4RJE8p0CXgWzSJ/DAWY6vIXAxyvh6Aw1wn/WZas1KRZg
IZI+G0HAEgtzraG0VZojdMRhadlOzIQIW+AV9J6Y+aJguTTIXV99hgesUqRZ
y7EKby3Sk7/JT8bmvd8KlebFfFsEcsaeUJZBJgFdhEkR0V5qTUKIi/SZyUpz
cImhSKQtiQ5isPEXXYanhVolRpHJ/U0O3KMKCx3iVibUlZliX0AkTNk+gF4V
v6VA/N6O9iy2t1aGmbG2h1iRm9AklBoQz85JaUNnfFATma+nC87oaHJ0zMfx
tDAFWy7T4Nxwje9SS47Nk74cx2TacqxsHIIwis3IBWLWYUZ7UI00xHQaRf5f
WDUlgK+IoN0r+gicFNZB+tZz2gfFFLwsGQE7gwELoVq4xJADKkuxoMRJW6uy
FQvlz8mbrJRG1M88TPlEQjk1p1PQRI932JuU/MfZJX3f5aiU+bzDhZXtqY1h
0VcKccJ/Ml3KzCROHFQX7ZJzHWRjKMmlTIKArcKd9cjOLzlNoJANBTnE3RaW
u4LI5GQEyboFDNE6dex/Jk8Ig1Maa1mCp0Q5o6llQGFRURloZefy83BEhSr9
llfX/Pnm7L8+D27OTunz8EP/4qL6UI4Yfrj+fIH3wn+qZ55cX16eXZ26yXgq
1x5d9n/pOL12rj+NBtdX/YuOy7liKypZk59DJ2PnGgBDnTv5IFcKkVbjC+Yc
n3yS+698Tnewv/8OMcF9ebv/BlFJkLQbUOe+Muoj4mtFMR1GkJC9xqhKXBpm
Z4TCZDalMF1wJvOuGgzN1oI3FOvTlJJEwBwqKvJQqj+862Ed7w6bkZC2eyaH
FYaJkalntSZt2JrLvvxOrEoL8Kbo3iC0mYr0K9Mn6YyOh0+MQzTSCexEKxgy
wjuoqKYOOChiQOYcp3anOOJSuaS3630HYUgnZgms/+OPP+Cxa8Pk9fHHs5OR
HJyeXY0G54OzG3l09IN82Jcvkfvty0P8eYNPL18/8gJsyoi4qKhyiirkL+tL
sixgRmYe5zAhl+61eK2rjp8ocjqGq3lKHg9Gcji6GVy9J2ROdDoFq190Zpy6
Bux2XG1s0ylq4luPxhwBaQ31VCoEcxRl1tesqJpZNRtyhfJb4CGgiDHjwsKn
oBwrOdy2YrgvdEowK1XEVUijSEIABdKKuVaEs5OCko6xp4kE+sEsNWcU65QS
7HF2Au/tcX5ION0iAdaKbCRy9dPDA5s1tiSTbNLgGGDjthIAUnuFWIdSKqMm
VCwuSXhPSrpLo6hAcTFNMMqYRdXPcCUUZXNxWCDhcNxNTALzJRzwXlG6ertS
e249GHNS4z4265hXwX5wELxaq2aqoZ/T+LdCD043p7xdn8Ie4Ddwduvjolm4
3NmB39jAZFviFd+ghoQyRqzU80W+8jtYpwaXdnCWySqm7RDdGhJMfCAtdd60
CkuS3Yj63BOgrbotNXsMKzlEQGjMw9B4Tk1CQTDLoL40BUTQgMyn1B84xK57
GTBrjgUNQrnd0WVQKUtV4ZL+dnFDZLGZw/3CGbHrySXJe1oJdiiNgghnpbso
0ey6sDwdOm2FES8k4g21SIa3TdZgwfzVVSsQ8bAhRZVAMym3/Vx5RXIB5Xmr
7eOJ5g2c1hxS4VOiBXdKsICM3MsitjPsSw23rgd/P7TR96JEdrXQhMlZlKoK
lAVJxhmQYiTteVT9PDp/O8TsFDnc+iSSQAlRynpXtM1Q0h7+p2LJ6Ph0n/45
qAJK3KpUPIMeKS2TVpfZHpAnZdfmkCphjC6p2g9eBq/hXYf48yagveifgx+e
7Z3s7bkNKz1RuKEY1bD3CgfYs12HiL2ldm5OgZ3Njsk+uR2RoNCJVt6DEaJR
+8lvIIkLZWf3yPKtyxKHFC5cmqGrx3zgUYPeZhpb2X0+K1yx1g4drn7YHikZ
LOsODSf5dYLRwsID8LD/FHw27Z31tzn3zQaOlnrw2WyliSfpqbttG/uJWmCB
/AbZdSRvdSfysrbV4mtUuL6KH+lqp/tQs3W44uGJjkujFCF/Znd1VfSCe9hc
/sh29VM2X1u5ATU6YBICsE8S4ySLF3pKbPF23VNUYItr2FqmJwmBbVnvrheK
VN06a6qLQ7ahqordVPzLTaPhyrhVF2/Mevctc0H+lHiQALoysrEOSxYapJNY
Ve4wYkv1yy0FSNIv7OrqsiKtSvWaQyrvKZz78d4UsM4mWw3RciMfwdXlpWEf
CYJJ4KRE8+jm89nWGL1WmddEUpH3LUIFCHW5SD1Px6zXyte+QrJkY849uaJB
7nn/YngWoC5L4tuv5ntPoA63YgU3AMmbfc+TM51m54BSRbb2MDTzuYk41Vzv
vcACHE81AlQVZDH/Svm4duRim5GzVc0oblos6XwuTrmbwRb/M3ky8njqr9A2
m60IWbYM3GlLuz3XrdqCnDDQYWxIMLK+fVBuVS+yTnlrKYppmXb2s77Senrt
FvJ9f1POZtPaSktVvfiiSijZUkQ7NpUHC7QvG3N9AMVnWgbpXJFCr4RSZXnd
SgaX5OJlaEW6S22/JFYARt8zwqLIiiIkhUjjtizAHQ2Kio1+CFmUxXvrzr+s
bldHiNtgyWSur9YAY+9JvhOdgyhG3Q1rsRw9LMVA5bsOUI+ZpvEXvbUPFkgu
Y9uCEJVWnBQoY045y2+d3jXW2xnmeiF3VLC/S6ppnOBsweA6X/C28pTquKuV
wee4C79+8li1o5sl6JJyplqEWrQ9trshMq9m61pPNJO6FxRl5/go9QQ0xZo6
ys6EDUPYk6dsVGCUJ0JOqN4c+IQqoXsVHnGot1L7Ax+2MAxs7RPJ1vnZ+p7x
dJYL7vs30TAFNpDCwgRYTSpLDB8g9ED8JJ4W2fqpjLJrB03c7ORH7H5IeuY6
ijl6yyFXhZvMl7jJzK+IV1Hu5wfR2SEvbTk9wKoT8uixnpDAC+s761uxm4xa
NIsxhtvyqgzjLhVLync+neuPNYYvMj7UYBN2agiz1SI3fKDpEiCWVlXVLIps
QZ1t6oNxd1wJ34bOtOvdco+/aQpN76eO95OnAL4lLOgYuqAjCryFx+lGb2Vb
bbp+1tUIz6Ldhm5E8kb73LfjY3/mxqgJCii6HPEU5/3rLrPZkpclS0Ed4Fqm
NInvHYBha8HyImwDzJm78gDNB5LWXi4NWbMqFw7sFrCrLgyoLfBBDkf3Fahl
3nJaDx+usqqPKNrQthbmuu3bCu6QzXcfxsTbgvIhbjYWEP/DQ1hmABW9vaaA
Hh8FRDiLkST5g2cSMkH1HHAfeXW3DYBAf0MIJdwLhvuSU5Srd7EpLCn6mwHg
yqS9KriJTSO+a1z74RsMKETNlA6muD1DPtLq0T88fPx5tNF08oXQj4PeKV/v
6v2Kib2IKmuSiLt5l1m1f8jF6agVXkiNT7dQrXtVthar6ELNW3eRjcofhsLG
UXXD17hT2mKcIZXdjdJtjqSEVNOMXY2Vj+Wmhcqw31RRYCY75bpHJdIidFKy
HposK7g660qdhz7Y+p7Iek7KtT2s4i6mfD5d1Ts6c8PsJon8jPqrazkp98Sr
mVWZ4DIHBhDi1tnJvLzUV5/xq5Rz2Yzu/M2UnTlLhIzZOShFoKQSoqWzbEbf
Qf+qv4G8z57JS76QJuszAzg3DWUE/Q0Fk78OpKJordeKCdmqzOk6w8tBjfDl
3UOxsXoHq06ptl01Dh9WvlPz5uDdu8dHpM6/y1MdxnMwR5/Ial3x3Pz5Xd7o
CSACiZ2Vv4vfe+VP/Wn9p/UGU6jF5NeCxyLkkdeWUNk72Ds4xJt/keP3QN2/
sQtJrDpn+U5JuTap2C6pelVbi+h7xPId4tgQw8vXshZDC7i2sH9TthxPWy3H
K8pm+2WPkc/IkMYY5/trTcBuO20mR+D7YXyIm+qlk8j14JRun/I5wFf6nHVj
k2v379fIE7bbEX9FDdt//oKtftty98uV/4Q+NhS5VU50FcNfi3nCSrdvJtqb
NQyYirAKIaqrVMClS8SnKddTsnnNcwfb7oorvoxt5c7l4LgEqBu3pEOu3Y67
BO1DEJlMueXz8vTH6SS2ohNbQ9eUg8hEAWeyqc6D8l5OUKGrDRa38X1Alip3
NnvEu50tu/GBXj7LNEWRpJj7g32+moE4jALtS3npq22Arhn1LWP6HrvZZiIH
lVe3m/Dr1nBesF7KXiL7BV2z42qyPvOfK4p5IeIlX+7x7jP0Nx3cNb0bV1ZF
cmEQBVfubsDaCebb/YPXnD/wPVG6Z0QRyl2Qdup2jfrqyL0CR2RBdIfoARI2
O6hiqxZm1Gte2d55uQt0iXZe78pS4RjtL+k6ve8c7taB1dI30v7Om10fCnb2
3PgnAsMOpLsrH4U4PTsfXA3owsRQDi4/XQxOBiM56r8f0rmGOD57P7iCt11+
ur4ZDbHgcPD+qj/6fHPW61+8v74ZjD5c4un5zfVl4/y+dgjshQRXQkoQ3r/8
lfF/M2H/Cxl8vxSactgkcu9g5/AtSUPK/mh0Mzj+PDoruSLY6J1Qcy4drRba
Oo7+/zBErx15zAYGPsr/JMOsa6bKDJuh/0/ekfA8Cd7wO9hqMkSTt/MECmge
4jcs0TYcfIuZOXporQaNa1zQ20/9m/7lUPZvzuiCOkgWj8ztnzrG+79ll0jY
YSx24AbCVF7TVNlezerol09njeNLxJfBf59JGMFuSxCn8viXzeNQLH92deoO
BAFPIV0DTeiiNLcBxcOR+09DOvqhM1GJ1Z1HChAqvWUEPTZjeYzkvyuvYhQi
H1S2KO93Ds1iFgM4w9k81lOOrlQKurvp1M9XWbISKImy6iizlTDxYYXfpp/o
e/lerVLjLqa50sSdGiVxyhVQiKUEvfRFX3P+TWEtaixUodrFeVX/b6I4XRR5
IP4HSdsI4Mo1AAA=
</rfc> </rfc>
 End of changes. 63 change blocks. 
463 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.48.