Diff: rfc9925.original.xml

	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 " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<?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>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
	OULD",	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
	document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	xref target="RFC8174"/>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
	when, and only when, they appear in all capitals, as shown here.</t>	nterpreted as
	</section>	described in BCP 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	<!--[rfced] For clarity, may we update the latter part of this sentence
	f a single	as follows?

		Original:
		Senders MAY alternatively use a short placeholder issuer consisting
		of a single relative distinguished name, with a single attribute of
		type id-rdna-unsigned and value a zero-length UTF8String.

		Perhaps:
		Senders MAY alternatively use a short placeholder issuer consisting
		of a single relative distinguished name that has a single attribute of
		type id-rdna-unsigned and a value with a zero-length UTF8String.
		-->

		<t>Senders <bcp14>MAY</bcp14> alternatively use a short placeholder issuer consi
		sting of a single
	relative distinguished name, with a single attribute of type id-rdna-unsigned	relative distinguished name, with a single attribute of type id-rdna-unsigned
	and value a zero-length UTF8String. id-rdna-unsigned is defined as follows:</t>	and value 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	<!--[rfced] To improve readability and avoid the repetition of "include"
	ve name	and
		"includes", may we update this sentence as follows?

		Original:
		Section 4.2.1.1 of [RFC5280] requires
		certificates to include the authority key identifier, but includes an
		exception for self-signed certificates used when distributing a
		public key.

		Perhaps:
		Section 4.2.1.1 of [RFC5280] requires
		certificates to include the authority key identifier, but it also describes a
		n
		exception for self-signed certificates used when distributing a
		public key.
		-->

		<t>Senders <bcp14>SHOULD</bcp14> omit the authority key identifier and issuer al
		ternative 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 includes an exception for self-signed certific ates
	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:<	<!--[rfced] FYI - We've reformatted the following text into an unordered
	/t>	list. Please review and let us know of any objections.
	<t>If the subject is a CA, it SHOULD assert the keyCertSign key usage bi
	t and	Original:
	SHOULD include a basic constraints extensions that sets the cA boolean to TRUE.<	Senders SHOULD fill in these values to reflect the subject. That is:
	/t>
	<t>If the subject is an end entity, it SHOULD NOT assert the keyCertSign	If the subject is a CA, it SHOULD assert the keyCertSign key usage
	key usage	bit and SHOULD include a basic constraints extensions that sets the
	bit, and it SHOULD either omit the basic constraints extension or set the cA	cA boolean to TRUE.

		If the subject is an end entity, it SHOULD NOT assert the keyCertSign
		key usage bit, and it SHOULD either omit the basic constraints
		extension or set the cA 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 extension.

		Current:
		Senders SHOULD fill in these values to reflect the subject. That is:

		* If the subject is a CA, it SHOULD assert the keyCertSign key usage
		bit and SHOULD include a basic constraints extension that sets
		the cA boolean to TRUE.

		* If the subject is an end entity, it SHOULD NOT assert the
		keyCertSign key usage bit, and it SHOULD either omit the basic
		constraints extension or set the cA 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 extension.
		-->

		<t>Senders <bcp14>SHOULD</bcp14> fill in these values to reflect the subject. Th
		at is:</t>
		<ul spacing="normal">
		<li>
		<t>If the subject is a CA, it <bcp14>SHOULD</bcp14> assert the keyCe
		rtSign key usage bit and
		<bcp14>SHOULD</bcp14> include a basic constraints extension that sets the cA boo
		lean to TRUE.</t>
		</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	<!--[rfced] To improve readability, may we update "etc." to "for example"?
	limited
		Original:
		However, some applications might use
		it as an integrity check to guard against accidental storage
		corruption, etc.

		Perhaps:
		However, some applications might, for example, use
		it as an integrity check to guard against accidental storage
		corruption.
		-->

		<t>The signature in a self-signed certificate is self-derived and thus of limite
		d
	use to convey trust. However, some applications might use it as an integrity	use to convey trust. However, some applications might use it as an integrity
	check to guard against accidental storage corruption, etc. An unsigned	check to guard against accidental storage corruption, etc. 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 396?>

	<section anchor="asn1-module">	<section anchor="asn1-module">
	<name>ASN.1 Module</name>	<name>ASN.1 Module</name>

	<artwork><![CDATA[	<!--[rfced] We note that [RFC5912] is only cited in the ASN.1 module.
		In order to have a 1:1 matchup between the references section and the text,
		please review the text and let us know where a citation may be included.
		We suggest adding a sentence before the ASN.1 module to cite [RFC5912].

		Perhaps:
		This ASN.1 module uses the conventions established by [RFC5912].
		-->

		<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 497 ¶
	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
	</section>	for <xref target="JWT"/>. Thanks to <contact fullname="Russ Housley"/> for addit
		ional input.</t>
		<!-- [rfced] FYI - We have added an expansion for the following abbreviati
		on
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.

		Key Encapsulation Mechanism (KEM)
		-->
		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

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

		</section>
	</back>	</back>
	<!-- ##markdown-source:	<!-- ##markdown-source:

	H4sIAAAAAAAAA81bWXPbxpZ+71/RQz9YukXCkmx50VQql9ps+mrxiHRyM7fu	H4sIAN1bjmkAA81c6XLbxpb+30/Rl/5hKUXAomx54WQZWpJtOtYyIh3fTCo1
	QxNokohANIMGRNGK8tvnO6cbG0nZcaamauSyRQK9nPU7S7d7vZ7I4zzRR7Lz	1SSbJGIQYNCAaFqRn+U+yzzZfOd0YyUZy56kZpS6NyQIdJ/1O0sfxPM8kQZp
	ObXxNNWR/GdwuPdOnugsjydxqHJtO4J+TU22OpI2j4SITJiqOWZFmZrkvVjn	qLuy9TYywSzSE/lP/+jgmTzWSRpMg7FKtWkJNRol+ror6OssTtZdadKJCJZJ
	k16i5gvbu8fcnkqmvdSkure/J2wxnsfWxibNVwvMGJyNzqV8JlViDXaN00gv	V6ZJZtLDg4NnB4diEo8jtcBqk0RNUy/Q6dQL1WJpvA9Y01PhzIviSOMaVk2F
	NP5J805XdnQU5yaLVUJfBv1j/DIZPt2MzjsiLeZjnR2JCMQciWJBv+2RPDx4	yUaLwJggjtL1Ek/1T4cvRJQtRhrrPnt2eCQmuLErDw8OH3tYPlvSd9OVR4dP
	uydCk1qd2gLf86zQ4u5IvhQq0wp7DHVYZHG+6oilyW6nmSkWeHoRz+Mc7PYj	D8Q4joyOTGaYBi2uu/KhWAZd+Usaj9vSrBeJnhp8iJOUPv0qQhXNulJHQiVa
	7AnyVCIvdThTaWznVk6w7ad/DP4pVRrJ4eXg8qwjbvUKC0RHoietTiY9L6+w	deXg9Fis4uT9LImzZVcyoeK9XuPapCs8aXQ49ZxQxqU4hFBZOo+TrpCekPgL
	lpS402kB2qT867tI6QTV+RnExulUvqel6PlcxQme24Wy87+TzAOTTemFysIZ	IpDQOvHlcx39phZB1OLLVhKtE3UdTBo/xclMRcFHlYJ13PIyjmehlm/eHNuf
	XszyfGGPXrygcfQovtNBOewFPXgxzszS6he8wguaOY3zWTHG3EjdxdFYpy9a	9UIFIYRIT4509O8z/t0fxwshojhZ4Llrje3lPfkiiRcynWvZG5z7HbmIJxnu
	CqQhCUk5byxfDg3c5CA27Ukvvm4UwSyfJx0hVJHPDLQpe9hEyjiF6jqngTzW	xE9XL46PnnUOu0IE0bT6zOt3wy7v4hT/Kl7JMxWt5YlaG/lKGdlPQa6O5CCI
	6a9qHqcdfuzMrHNKe669AlcQ4xdFYsWQ98ZMEy0vLk7ca+3EVVL79ym/D0Iz	xloqekJCdV1SnfwpCyOdqFEQBun6B7uQSmY67cp5mi5N98GD1Wrlz+PVAotO
	FyI12Rzz7lhVz+R5ZuYyn2nZH14F+3JuogIj8erm/OTw3f7BkRBxOmnO+fjz	sKahZdRvqxRr0BLXWIF4ecAPWw1PVWg0fy9kiz8r3lzAr305UNFEJyZ2Yixk
	6Ih38d7zwSzlpUpX8lStrPygrBzkIFenchinoZaKZsDmp0ckAvlTkaQ6U+M4	/Br/MvL+x3ia6A/3q7fhPrbnGsutfi6SOJKpHs+jOIxna+nJiyXxvTapXkAO
	gVn+6BZS2VRDzKWUl8tlMDPLORaNsKalZdSvyxxr0BJ3WIF4ecGT2SPkwd7B	UaoTWFmkx3ynJ4cQ9EmQ4Dv7wGU2CoOxB5OR2FGqNE2CUZbqqrXIaQLiyMxM
	K7hcb+8dP6wEjB8n41LKHwM5hMXpzBovy0rQH/HLyudfzCTT98+bwzCOkaHF	a6e0gjTzgyh9gJUfpB7+3/tARD+AqZYyusCu8Ax4Q+fZhqjYpuBBw7fekC8Y
	d2dQysWkModhpyYx05XsyesFMb+yuYadD9JcZ3DRVIc8sidHkPZpnOE7o8qn	nQTakO7zG/g3eaUh+oWOJs74WDr5HYOLB/3TY/je0bNH3tMu/O6AJNj3Tnz2
	YpzEYQ8exq6g8jyLx0Wum84lJxmIIxe2nQbX11gCsADu9zf5ZisB6Iw+90b8	5d9io72JXoJCkGR9OTGqc2T3mARmGSoI5vXF4FQI3/eF8DxPqpFJEzVOhRjO
	wOos1pa0WQ4YDK9fDM5O5LvDd696b48gxD0hgiAQotfrSTW2eabCXIjRLLYS	AyOBEhkoSOVET4MIilMSj431PA6hNoc/5HcqzRJNphcnQTonO1epXKi1HGmZ
	wFfMgVUy0pM4haSUXCQq1DOTQE4eOgkXVF5kmhQONMtnZF0qhwOv5FjLwuoI	GQ0AiiT0k+oPqZGrucbN5AoEDNggkfHUfq9oA9tHcSr1hyWUCL9OY3kNSU3X
	BiUhkFzf51YuZxqDyQAJxrBBJs3EfW+wj+1Tk0t9v4DUACm5kXfgZrKikaLa	dKcoNvVlz8ilSlK7RgAYCVLp8Id8iyHIsbcIJpMQsHCPLCaBB7K5CNGLHC9V
	NJB9Kxcqy90ase3KOJceLcmiGTA9e/M4ihItxDNSUQa7Z/0I0U89L00CHh7+	Am5u/kGuiadvb2WiGQlluooBS7BOqAzWzlRf/tjvyqA0VGBwnKWQFVDzNxBv
	gxwCsx8fZaYZGGS+NBICAbjhC5giqgFpRzKuLUOosSlyyArB4FcQ73QsF5kB	TU4ukxgkTgkGVAT2TKYTX/4U6FUQzfKFpCIhzxK1nMsVRCmKzRTJY6LBn+Kd
	iRNyPpWCPVvoLJA/xXpJsOcXkoqEPM3UYiaXEKWoNlMkj0iDP8U7Pzz8CPJe	b25+AHmPOkdPb29xrSk7bKEnMw0FpCuCCBZahR63vxD9CLi70IV62vSoWi5D
	7R++fXzEs3XZYQsdTTUUkC/JMVloDXr8/kIMUmnNXFfq6dJUtVgktBRZb6p1	WoqcKdJ6YhBF8JQKCVjyZSosk+OnWk2gBFEjxYekmTfLElBPh22+sLmFYgbb
	ZBEIMUsl5M7lMg2WydNyrSIoQbRICSBp5s2xBKzRSZcfbG6hmMEuq92TH4hz	rHZHvi9exAlsAIAf4pdyYXpqqdK5vFZhYD1E7t3cDBwAPCZrKNW3DzHMQCIc
	xAx9D1xN8KZemGYtVD6TdyqJI/d95+Fh6D3uNVlDrb5diGEKEuFpIA8R09IO	H+RxHMQOY/gknFFCL2ljaeuwwE25x78e9/Z9xpQK1YLXMWx09TWrgoElePHU
	IfyGAy4Uk6+t7bwKcCV3+O1JfzdgL26QLXghy1bXWrQlGZhCz0x6YzYC/I2M	G7EN4H+TWFvDTvTvWUBOEwmri/umdCXoxRpkcbv1QDIqbDVmd8MmdnMz1pFK
	dpad6d+KmLwmFU4Zz23tS1CMs8hquHNBsipsFbK/UTzlzW2oU5XFhqTNeuh6	gpiEzWpoO3NmqoSlCszjmXiawhgSAgaEZPIrsjLZqkTQVlV/MIfCXXP7AaEE
	e2aqhKMK3GOOmeSwhkwvMo0MghyLzAxhtg7xnaYCYQ+Vv5YGBEIJumi0lQZe	pHS3kTGcEh5Hz/vyAncl0jJP8Twbz8larakiyD0iU9UfAogqjSktuMY6VdHh
	CZej+YG8xqhMOuYx0xbhjMzV2Spiyyu4kr6PIancUBJzh2WaksMc4OBT+YYF	IcDyrnhuQDgCbgSaYUZrRhZIqjeZBCRrFYbrtjXm4ZuB2/Xpo0eP4b8AWSIU
	3QhzKUiGGa0YWSCoOtlIVl1nzKOLod/07atXr7EpgJDoRPaVmBVBmqXZzY3g	iBjGa4I0Q09XN4KnTaxrr+t7gn824TWUwaoA/tO9ACQnRWjluOexFoF0E7tI
	aZFz7VV7T7DPJryCLlgTMcSWMiB5IUIpJ/0eKxFIF7lFupVPOAgrnRxIsqLP	u/AJC2G5kwNJ1vSZMGtNi5Ct0SPsuQ0UFBXzgeT8md+W14HChu+jeBVJ2MRM
	hFkrWoRMjaaw566hoGhYT1fqYBrIu1hhv9vULFMJi5jqbJGBooAgWzdZYjuy	J8sEJPmE2brKE1sSTHO9xFqQjZyraw0OcMc4Y+OG82RwKxhGdB8uMNfj95D4
	lF5hKYhGztSdBgMY4RJE8p0CXgWzSJ/DAWY6vIXAxyvh6Aw1wn/WZas1KRZg	aC0soWONTCRps93GERZgKZJGK1HAEA8LraG1dZQidgTj3LatnAkStuAr6D2O
	IZI+G0HAEgtzraG0VZojdMRhadlOzIQIW+AV9J6Y+aJguTTIXV99hgesUqRZ	F8uMBVMht7n6HBdYp8hUVyM1fm+QKX0jL2OTer9nKkqzxbYQZM09pBBONgFl
	y7EKby3Sk7/JT8bmvd8KlebFfFsEcsaeUJZBJgFdhEkR0V5qTUKIi/SZyUpz	jMNsQnuphoQQEOkzkxWl4BK3Ius0JDqIwQQfdR6flmodxops7hvZt5cKMLSQ
	cImhSKQtiQ5isPEXXYanhVolRpHJ/U0O3KMKCx3iVibUlZliX0AkTNk+gF4V	W9hQWyaKvQGhMGIDAXwV/OYCcXtb2pPAvDdynMTGeAgWyI3jkFIV4tm6KW1o
	v6VA/N6O9iy2t1aGmbG2h1iRm9AklBoQz85JaUNnfFATma+nC87oaHJ0zMfx	rQ9qIvt1dMEdLU2WjsUomGVxxqbLNFhHbPCda8myedyTo4BsW46UCcYgjIIz
	tDAFWy7T4Nxwje9SS47Nk74cx2TacqxsHIIwis3IBWLWYUZ7UI00xHQaRf5f	koGAdZjQHlRpDPA43UUIkBk1I4QviKDdC/oInhTWQe7hWe2DYopehoyAvQFJ
	WDUlgK+IoN0r+gicFNZB+tZz2gfFFLwsGQE7gwELoVq4xJADKkuxoMRJW6uy	ihyrpc1ROaKyFDNK5LQxKlmzUO4mb7JSuqO85oDKZRLKqjmagSa6vGfdSckf
	FQvlz8mbrJRG1M88TPlEQjk1p1PQRI932JuU/MfZJX3f5aiU+bzDhZXtqY1h	8eU0Ah0mCy1onyHTRNpvFnLvx9Ozfbp9n6NW4vISG3a2pz4xa6bQl9XNznQq
	0VcKccJ/Ml3KzCROHFQX7ZJzHWRjKMmlTIKArcKd9cjOLzlNoJANBTnE3RaW	iadBaLE8q9d1TRQOoEObUgkCvgKXmpGff+Q0gkI69GcheVvYbgsik5MVlBUG
	u4LI5GQEyboFDNE6dex/Jk8Ig1Maa1mCp0Q5o6llQGFRURloZefy83BEhSr9	MEXrlLnBPSShFU9+g6osg8oZaViGVIAZ2Tp7Oxi22vbf8vyCP1+d/sfb/tXp
	llfX/Pnm7L8+D27OTunz8EP/4qL6UI4Yfrj+fIH3wn+qZ55cX16eXZ26yXgq	CX0evOq9eVN8EO6OwauLt29Oyk/lk8cXZ2en5yf2YVyVtUuiddb7uWUV3rq4
	1x5d9n/pOL12rj+NBtdX/YuOy7liKypZk59DJ2PnGgBDnTv5IFcKkVbjC+Yc	HPYvzntvWjYbq0qZAADaGFmfAUrqlCUjkEWNkf/jC555fnz53//qPHLp3mGn
	n3yS+698Tnewv/8OMcF9ebv/BlFJkLQbUOe+Muoj4mtFMR1GkJC9xqhKXBpm	8wzhwn552nmCiMWCroCg/UoBQSAb0IriPfQfkiUHKJ1shmbmhM9kMWS9v5Bk
	Z4TCZDalMF1wJvOuGgzN1oI3FOvTlJJEwBwqKvJQqj+862Ed7w6bkZC2eyaH	fu3Kb0fjZefR9+4CMVy7mMusdpFltnll42ErxC2XtmxTSLN2vSHpOr29n2vf
	FYaJkalntSZt2JrLvvxOrEoL8Kbo3iC0mYr0K9Mn6YyOh0+MQzTSCexEKxgy	c7lXLn77Q0gpitd5+sP3QpL1HDOEZDb4FW2LasPCeYZxeVuuGcA+il1CLKoP
	wjuoqKYOOChiQOYcp3anOOJSuaS3630HYUgnZgms/+OPP+Cxa8Pk9fHHs5OR	HRRhHQcPm6kBGes9OSgwXQzj8qnaQxvOZdNRtxOrxSCYUb5TIbSanPUKXyeb
	HJyeXY0G54OzG3l09IN82Jcvkfvty0P8eYNPL18/8gJsyoi4qKhyiirkL+tL	GD4f7LgP0VmHcA+t4LnId0BF8WifswTckFikKPEjmHD3Jae37cACYVmH8Qqx
	sixgRmYe5zAhl+61eK2rjp8ocjqGq3lKHg9Gcji6GVy9J2ROdDoFq190Zpy6	79OnT0Cwxm3y4vnr0+Oh7J+cng/7L/qnV7Lb/U7edORDJMMdeYR/nuDTw8e3
	Bux2XG1s0ylq4luPxhwBaQ31VCoEcxRl1tesqJpZNRtyhfJb4CGgiDHjwsKn	vAB7MFIQVLwpRVkCiOaSLAt4T7wIUniOTYBrvJZl2E+USViGi+eUfN4fysHw
	oBwrOdy2YrgvdEowK1XEVUijSEIABdKKuVaEs5OCko6xp4kE+sEsNWcU65QS	qn/+kiJVqKMZWP2ok9iqq884w+XXNp2iAH/vohNnBLSG2pUbwglFngdXS8xq
	7HF2Au/tcX5ION0iAdaKbCRy9dPDA5s1tiSTbNLgGGDjthIAUnuFWIdSKqMm	mcHuW0S9LXjoUwSdc6XlknLOHTj9qOU0rvLL0TtXEZdllaoRCQUij1hoRXFn
	VCwuSXhPSrpLo6hAcTFNMMqYRdXPcCUUZXNxWCDhcNxNTALzJRzwXlG6ertS	mlESNnI0kUBfxSvNGVaTUsJ5ztYAWh4nzBS3aiTAWpGdTWxBeXPDZo0tySSr
	e249GHNS4z4265hXwX5wELxaq2aqoZ/T+LdCD043p7xdn8Ie4Ddwduvjolm4	NFgG2LiNhBOXXiGasYPqyilVzysS3k5Jt+kuqthsjBcMrvGyaDXZmpLS22CM
	3NmB39jAZFviFd+ghoQyRqzU80W+8jtYpwaXdnCWySqm7RDdGhJMfCAtdd60	gOq4m8YhzJdwwHlF7ur10vW+cdGHkzz7sVrYPfI7/qH/qFHeFbe+jYLfM90/
	CkuS3Yj63BOgrbotNXsMKzlEQGjMw9B4Tk1CQTDLoL40BUTQgMyn1B84xK57	2XzkafMR9gC3gbVblyfES1tMWMgfxTDZmnjFZ6ghoYyQHOjFMl27HYxVg03D
	GTBrjgUNQrnd0WVQKUtV4ZL+dnFDZLGZw/3CGbHrySXJe1oJdiiNgghnpbso	OOtmFdN2COcVCYYuc8h1XrUKQ5LdyIK4SUJbtWtqdhiWc4g4WHkOtwaLALoR
	0ey6sDwdOm2FES8k4g21SIa3TdZgwfzVVSsQ8bAhRZVAMym3/Vx5RXIB5Xmr	uE5Iy+XNKs4ghQpq7rIA34J22d+BZXMQrNDKLaA240pevgtbCNULPqKMLV1h
	7eOJ5g2c1hxS4VOiBXdKsICM3MsitjPsSw23rgd/P7TR96JEdrXQhMlZlKoK	vXQ8J54dzSR+RzBhD+WWkOM89xklqr0oFqqFqK1Y4iRF3KFCS/BrlTmYMX+1
	lAVJxhmQYiTteVT9PDp/O8TsFDnc+iSSQAlRynpXtM1Q0h7+p2LJ6Ph0n/45	NRzk/O0/PO+XZDrWk18ltSDGEBZnmcT0SrsGE8sUOSPUV+tBSa6to7EWyjjL
	qAJK3KpUPIMeKS2TVpfZHpAnZdfmkCphjC6p2g9eBq/hXYf48yagveifgx+e	Nz8IcZEEswCWxT24QUVZKsQKETd+bVlLsod00lq7zYmFWbCAQM1ExkR8CbVt
	7Z3s7bkNKz1RuKEY1bD3CgfYs12HiL2ldm5OgZ3Njsk+uR2RoNCJVt6DEaJR	UmENau/R71lg5mCOWq9tF2byW8sOKMoz6nWul5oCQDKJVBkBSAPWWhXDtucg
	+8lvIIkLZWf3yPKtyxKHFC5cmqGrx3zgUYPeZhpb2X0+K1yx1g4drn7YHikZ	/O3wxdMBFohmENWlTubInf8PmLJtxjnnul/MV+6HTi672PO877GMEH8BZ1W2
	LOsODSf5dYLRwsID8LD/FHw27Z31tzn3zQaOlnrw2WyliSfpqbttG/uJWmCB	xFfqajtD4g6K2pQC5coucJVmWk0w6rffKcM4PJKdIsMIaqW8482FTsNUlZ0o
	/AbZdSRvdSfysrbV4mtUuL6KH+lqp/tQs3W44uGJjkujFCF/Znd1VfSCe9hc	F6GneV/zyDaLgpKgjv/QfwzAPcI/T/zDI7/z3b2D44MDu1uhH0o+KGOpoF8R
	/sh29VM2X1u5ATU6YBICsE8S4ySLF3pKbPF23VNUYItr2FqmJwmBbVnvrheK	FRjnbQOVsbOEei4QLXyNCKrYQsJEq8na4TkSNjlay8/EFZvYnH6A99NpGfLb
	VN06a6qLQ7ahqordVPzLTaPhyrhVF2/Mevctc0H+lHiQALoysrEOSxYapJNY	ASUPNunUxWWsjXhQhMDNKq4AwHSe2VZGPZGw1fX2vIlDZ9nB5BK4TDdrkfEQ
	Ve4wYkv1yy0FSNIv7OrqsiKtSvWaQyrvKZz78d4UsM4mWw3RciMfwdXlpWEf	PHR2BdOqnVt/23j2yUZUrQIncvBggRzpmrxYTVx+YL3vOg4mrh+21GmQa79l
	CYJJ4KRE8+jm89nWGL1WmddEUpH3LUIFCHW5SD1Px6zXyte+QrJkY849uaJB	+zS6xZE2/2Zam8BbQVn5Zyi7weovjtxfi1SQbqy1/NK8X+RyyB2ytM3KnEbq
	7nn/YngWoC5L4tuv5ntPoA63YgU3AMmbfc+TM51m54BSRbb2MDTzuYk41Vzv	5NKR4IexZrOyRfeuTmZZwhMAsH9zuKcllnxa5ToHdXj9+7lJ67b5N7HVhFVX
	vcACHE81AlQVZDH/Svm4duRim5GzVc0oblos6XwuTrmbwRb/M3ky8njqr9A2	qRaOu9N8y7OLDfMUpX/58jNWXpYBO0QlvkjxdxSP2CWeqmxkvVeUH2XVCgtq
	m60IWbYM3GlLuz3XrdqCnDDQYWxIMLK+fVBuVS+yTnlrKYppmXb2s77Senrt	G0NLAjkjSYwrtLzBvFN0wXa4oLSSQaoCT4mehpSq5Q3EZueN2oUWgMpuG8NO
	FvJ9f1POZtPaSktVvfiiSijZUkQ7NpUHC7QvG3N9AMVnWgbpXJFCr4RSZXnd	0RbcxIqHmzjDrcZao3HjqWd/ijAvfu5LT77T9xlibB3Hh4W1ioPOtagHFFvE
	SgaX5OJlaEW6S22/JFYARt8zwqLIiiIkhUjjtizAHQ2Kio1+CFmUxXvrzr+s	jBNOAEUIFfjyMqReL56+DvSKzStE6gzQpQ47h+xoLWNm3eXgW9M4Z8AoB0MX
	bldHiNtgyWSur9YAY+9JvhOdgyhG3Q1rsRw9LMVA5bsOUI+ZpvEXvbUPFkgu	4rAoh2S2qlygFUH6EppWqQ1xdKa72eDkrjH06xa3rdO8q1h0YwuZ0yrUxCUm
	Y9uCEJVWnBQoY045y2+d3jXW2xnmeiF3VLC/S6ppnOBsweA6X/C28pTquKuV	3CO546stsq7omxMplAxcbTOA9FD5xBBNRNQPr96e+ruIrHdhS2qpm7SdYlqo
	wee4C79+8li1o5sl6JJyplqEWrQ9trshMq9m61pPNJO6FxRl5/go9QQ0xZo6	NBRQbEut8lEdsNUVaLBBu0UkR75kj7N31ul+0XszOIWc30Zh8L5R0jZgsr0r
	ys6EDUPYk6dsVGCUJ0JOqN4c+IQqoXsVHnGot1L7Ax+2MAxs7RPJ1vnZ+p7x	mpZHcAw77qyL6zluCNM6tidMNTF75pgO7mOOUxtNd9iG466gn05CsiSBBP9i
	dJYL7vs30TAFNpDCwgRYTSpLDB8g9ED8JJ4W2fqpjLJrB03c7ORH7H5IeuY6	i/rmrzKqr7Sr0qzcIpsaKi1rO7F3My63/Fb672xfbpHtnNzZxNwqO3snd7Oy
	ijl6yyFXhZvMl7jJzK+IV1Hu5wfR2SEvbTk9wKoT8uixnpDAC+s761uxm4xa	fJymYWtfZmhukU1zQ/DdiLxfZGallW09l/lCC8ttC/R+nXXttKs7nBrdBa9q
	NIsxhtvyqgzjLhVLync+neuPNYYvMj7UYBN2agiz1SI3fKDpEiCWVlXVLIps	zvA1cLXLkGi5DVPaBlZ3tyE+cNuFVV8FVELWoMp29bPFn7T0G3NBplq31jrM
	QZ1t6oNxd1wJ34bOtOvdco+/aQpN76eO95OnAL4lLOgYuqAjCryFx+lGb2Vb	ik/OVjTOFkR8pMYm9Y4SJNQNdAZI22yeh8n83MqOBNWPkNvF0TWX66AfjCI7
	bbp+1tUIz6Ldhm5E8kb73LfjY3/mxqgJCii6HPEU5/3rLrPZkpclS0Ed4Fqm	a27v51uVizQpry1FlWWirR01V2q2PO1Cbjglzp9mE9tKS9FRdo1uoWRNFfUK
	NInvHYBha8HyImwDzJm78gDNB5LWXi4NWbMqFw7sFrCrLgyoLfBBDkf3Fahl	MZ9+oX3ZqMspKR68ig0ymAiapcQvP/KodedW5O55gTvSgo6mw0Ah33QHl1h0
	3nJaDx+usqqPKNrQthbmuu3bCu6QzXcfxsTbgvIhbjYWEP/DQ1hmABW9vaaA	loF4lFf+tgX4cI1q08qBEdmUwe/GDmkZXe9Yo3oGS3FiE9XaSR25k5uWSEET
	Hh8FRDiLkST5g2cSMkH1HHAfeXW3DYBAf0MIJdwLhvuSU5Srd7EpLCn6mwHg	57IbxmI4JzdUiCp3EATtxLMo+Ki3nsX6kk8W6nIQhVKsEKiDGXHjtTZhVllv
	yqS9KriJTSO+a1z74RsMKETNlA6muD1DPtLq0T88fPx5tNF08oXQj4PeKV/v	b5DqpdxTfmefNFOZMtqS1ZZFuzOVXZo7pumXBE7HkyLN6bhiYqJ6KrCixkUp
	6v2Kib2IKmuSiLt5l1m1f8jF6agVXkiNT7dQrXtVthar6ELNW3eRjcofhsLG	QS3qLtveEJnTsrGHoPQknSNlZCHYQ09BUqBp5sEacMwwtnMQjCrwfGrJyjQ3
	UXXD17hT2mKcIZXdjdJtjqSEVNOMXY2Vj+Wmhcqw31RRYCY75bpHJdIidFKy	BsgyDAj9LODQYVfpDDwPxBiwvfqQtRGv5p7BbJ4Knkyp4mEEZCB9jUMgNmks
	HposK7g660qdhz7Y+p7Iek7KtT2s4i6mfD5d1Ts6c8PsJon8jPqrazkp98Sr	jO2IC4ifBrMsadalyjSGofi8nS+x86GSXOhJYAkacJ9+k/kcN5n5NTEr8v3c
	mVWZ4DIHBhDi1tnJvLzUV5/xq5Rz2Yzu/M2UnTlLhIzZOShFoKQSoqWzbEbf	TTTexksbrrew6pT8eUSlCXXK3ezHVvQmmxbV3jiD7SCf1Tl2nWsr8tzxUaCn
	Qf+qv4G8z57JS76QJuszAzg3DWUE/Q0Fk78OpKJordeKCdmqzOk6w8tBjfDl	gEoeu2ELtnoYJ+tlGvPMna0qWVpFR3GZJUuavaCTSZ7fUMINSiTajg/wFErV
	3UOxsXoHq06ptl01Dh9WvlPz5uDdu8dHpM6/y1MdxnMwR5/Ial3x3Pz5Xd7o	FKq+TzMZO+dU3FSCoEnJjIZo8CscTldOu7YdFTTHsSpBWtQnISrxvDLg4QZG
	CSACiZ2Vv4vfe+VP/Wn9p/UGU6jF5NeCxyLkkdeWUNk72Ds4xJt/keP3QN2/	AjcWxpgJCii2dPkR6/yNILc5MyJzjvwyutUsaRp8sOiFnQWLi4ANGBdf5xW4
	sQtJrDpn+U5JuTap2C6pelVbi+h7xPId4tgQw8vXshZDC7i2sH9TthxPWy3H	iyK1rezZTcOobCwwW6CuOE5QW8CjLfnYzVamVZ914GGbm+UMTR3YGjGuXZ+n
	K8pm+2WPkc/IkMYY5/trTcBuO20mR+D7YXyIm+qlk8j14JRun/I5wFf6nHVj	tVNg7ixoRLwtKSni098M0r+5Gefhv6DXqwro9lZAhPMAeZKbjSQhJ/kws9N2
	k2v379fIE7bbEX9FDdt//oKtftty98uV/4Q+NhS5VU50FcNfi3nCSrdvJtqb	Xf8E+RtCyMFeMNjnnC6pUI8zQ3r+LPyfx5FXRDaxacPXlRF5nrFFVR/PaHKK
	NQyYirAKIaqrVMClS8SnKddTsnnNcwfb7oorvoxt5c7l4LgEqBu3pEOu3Y67	z8vIRWqzIjc3r98NN04BXXPph88PX3N/+PMd0mazs6XTsd8imlqV87RWs9dZ
	BO1DEJlMueXz8vTH6SS2ohNbQ9eUg8hEAWeyqc6D8l5OUKGrDRa38X1Alip3	+BefV9e4ZRglx+BqNXXxkwBqxuBilY4NZplKYH8zReGY7JP7RyqUBgHTVYPj
	NnvEu50tu/GBXj7LNEWRpJj7g32+moE4jALtS3npq22Arhn1LWP6HrvZZiIH	OEkybna1JVFW71F+jor6meBfT1PZWxzWojj5y+7hAWN/yg/ViyBOYwuEqHpC
	lVe3m/Dr1nBesF7KXiL7BV2z42qyPvOfK4p5IeIlX+7x7jP0Nx3cNb0bV1ZF	vTsOOZWpVf9OMt/CnLgzcxvSlpVpCbG1giR7Cqh6itZNceLpKol8jc7cGrDI
	cmEQBVfubsDaCebb/YPXnD/wPVG6Z0QRyl2Qdup2jfrqyL0CR2RBdIfoARI2	0yDFk0VRZhM0Bmri1jrkIp+VK+d9VcSt2ASGSadzc+vykDGjEGVilbFWjnL9
	O6hiqxZm1Gte2d55uQt0iXZe78pS4RjtL+k6ve8c7taB1dI30v7Om10fCnb2	3nlvI8LduyfP+C0ZWU7LAEXpVj7zm0w2On24LVnn+XJrcNYv4yfxdPlj/59i
	3PgnAsMOpLsrH4U4PTsfXA3owsRQDi4/XQxOBiM56r8f0rmGOD57P7iCt11+	Y80WfG9G7dh1Zdhm7Q6inhw+e3Z7i7LkD3mix8ECLNEnAgXb763+/SGv9BQI
	ur4ZDbHgcPD+qj/6fHPW61+8v74ZjD5c4un5zfVl4/y+dgjshQRXQkoQ3r/8	TGcS8g/xh5f/lZ+af7Vf8IjsHB66tQCISCgIFPNI5B0eHB7RLi+O+a0ruo3l
	lfF/M2H/Cxl8vxSactgkcu9g5/AtSUPK/mh0Mzj+PDoruSLY6J1Qcy4drRba	VMwV3Uk+dhhAbJdPuZYpBfMlwvgCIWww//CxLJmvRYMtTF/lR6gntSPUcyoQ
	Oo7+/zBErx15zAYGPsr/JMOsa6bKDJuh/0/ekfA8Cd7wO9hqMkSTt/MECmge	evmZKU+CITWMrZ83DjXbjUIkcK+F8GxmpFdWIhf9E9Q7Y552+bPj6OKgljoj
	4jcs0TYcfIuZOXporQaNa1zQ20/9m/7lUPZvzuiCOkgWj8ztnzrG+79ll0jY	d9bDDjttia8R/va/r7DLzyiK1eBWvoMWNtRXSIdGrfOO/Q6D3L6DqO9QsVWq
	YSx24AbCVF7TVNlezerol09njeNLxJfBf59JGMFuSxCn8viXzeNQLH92deoO	YAsIKN6WAJKfIb7PuBiV1ffK9rDtvjjntxmN3DvrP89x58ouaQFpv7IFv4ho
	BAFPIV0DTeiiNLcBxcOR+09DOvqhM1GJ1Z1HChAqvWUEPTZjeYzkvyuvYhQi	J+7ZTPIf7udzTVYjgRGtwMR+nMz8STzxuSKIdOrnE/h+gZ7GX74PPvhknXKv
	H1S2KO93Ds1iFgM4w9k81lOOrlQKurvp1M9XWbISKImy6iizlTDxYYXfpp/o	edS939qyF4svnSeaYkSYLSLjDsdgxUhnUOV+zF/vqBufbe59zpC+xGY2Qaww
	e/lerVLjLqa50sSdGiVxyhVQiKUEvfRFX3P+TWEtaixUodrFeVX/b6I4XRR5	vI0xgqYlvMhYPfkxF/sEvVDDJXk5wrtQFNHGiIY8xO9cZ+BGlu0LOW5YeSKX
	IP4HSdsI4Mo1AAA=	MWLcmkLRxmTe087hY07D+IUwep+A4o99J9NqvZ6hveOTdzdq8ot7V/NXHh6g
		acJxkJbNm/qbnVRQ00lTZcKp0+3YKadsWX0xi5qsVtLlJGxemVBa3xbL2iFV
		fn3jtMr1Doiqsmrl+WfupyLWvqPaaTajqhG4lL8O4Y7RXZnaZIUYYEZL/hs5
		H59Y1h7J8tcnOF2KbLqBXaFViw8IsJXVuCP96dMnqCzyO6KY4y1iETJ5yvNu
		IPh4r7NfHmtOvOorunsP9wHmk73H+zL3NdztXrO0Lrd3tF/mLIa+kePtPdl3
		8XbvwN6/I/ruIT7vy1shTk5f9M/7NAQ9kP2zyzf94/5QDnsvBzQWI56fvuyf
		A+bOLi+uhgPqbPdfnveGb69Ovd6blxdX/eGrM1x9cXVxVhkKLkHJo/e0pYSJ
		wrYKQTFh/wsZfLkUqnLYJPLgcO/oKUlDyt5weNV//nZ4mnNF0O0dU385Gq6X
		2liO/v8wRD9b8pgN3Hgr/41Qoaz7CzOs5ld3HLx2PHFt8yVsVRmih7fzBAro
		OaRLsERTQdctZmbp4cPbksYGF/TrZe+qdzaQvatTeg0YJItb5vZOU2B/L7tE
		wh7CIOIKaFJpSU5hdiWXw58vTyuDbwjv/f88ldD/fk0GJ/L5z5uDdFj+9PzE
		jpQhLIwJVkN6E5Vb2OKma/+jB3ryXYvfhG/dUmBW0XuOXDc3N8/jkXyOquqW
		ptfw/TxAnfdKJUud8CU7n30ziJfzAPFrPF8EenZrp4YdvrsmoVZJuBaA3aSY
		jaslq3wMV27cC/UH+VKtozjJl7OFoAX5MIi43iQcF/Sj62U0VrnKjEFRm5lQ
		r/NlVPF+JTS3zFLXw5DNIQwX5Tjd5ZGYpbJnXvZF1WoKYv8rFYEN2xBNMdmE
		vIcYpRThyUNUQnst+jhI14gpLzOYVmu/ObJBTUxRbuZicZHSj5FD2Mn7lF7d
		NtzjQk2NDamLTIfPn30BjONTjefLjYDc6lOQNZSn5u9JtZCIJKXuNKUMyEZE
		hR35bfW/LoDFPQ1hxwmljA8M3UenMPoBtQMPH9wL8j3+K3R7fC+aSUBgR1aI
		gZl2s4M8rU+n1C7Lym3JwVvxiihqDsiAXwPkIwJqYQWGZpztbvl7aHh0rsNl
		PohIvSvkzpDleZErxVkibUqJUmnCjYlpqGZMm31tLKgfmdG5hB3rm3PzUSDZ
		t+czVsr5W221lrdNHf4HRr393B5FAAA=

	-->	-->

	</rfc>	</rfc>

End of changes. 62 change blocks.
	458 lines changed or deleted	375 lines changed or added
This html diff was produced by rfcdiff 1.48.