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	<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 415 ¶
	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:	<!-- ##markdown-source:

	H4sIAAAAAAAAA81bWXPbxpZ+71/RQz9YukXCkmx50VQql9ps+mrxiHRyM7fu	H4sIAE1/j2kAA81b63LbRpb+30/RS/+wNEXComzZFncyWUqibDq6eEU6mWwq
	QxNokohANIMGRNGK8tvnO6cbG0nZcaamauSyRQK9nPU7S7d7vZ7I4zzRR7Lz	P5pgk0QMAgwaEEUryrPMs8yTzXdON66kfJmtrVq5bJNAX06fy3durU6nI9Ig
	ObXxNNWR/GdwuPdOnugsjydxqHJtO4J+TU22OpI2j4SITJiqOWZFmZrkvVjn	DXVPtj5EJphHeir/7h0dHMtTnaTBLPBVqk1LqMkk0bc9QV/ncbLpSZNORbBK
	k16i5gvbu8fcnkqmvdSkure/J2wxnsfWxibNVwvMGJyNzqV8JlViDXaN00gv	ejJNMpMeHhwcHxyKaexHaonVpomapZ1Ap7NOqJYr07nDmh0VzjtRHGk8w6qp
	NP5J805XdnQU5yaLVUJfBv1j/DIZPt2MzjsiLeZjnR2JCMQciWJBv+2RPDx4	MNlkGRgTxFG6WWHWcDA+F1G2nGise3x8eCSmGNiThweHLztYPlvRd9OTR4ev
	uydCk1qd2gLf86zQ4u5IvhQq0wp7DHVYZHG+6oilyW6nmSkWeHoRz+Mc7PYj	D4QfR0ZHJjNMgxa3PflcrIKe/CWN/bY0m2WiZwYf4iSlT7+KUEXzntSRUIlW
	7AnyVCIvdThTaWznVk6w7ad/DP4pVRrJ4eXg8qwjbvUKC0RHoietTiY9L6+w	PTkanIp1nHycJ3G26kkmVHzUGzyb9kRHGh3OOo4pfskOIVSWLuKkJ2RHSPwE
	lpS402kB2qT867tI6QTV+RnExulUvqel6PlcxQme24Wy87+TzAOTTemFysIZ	EUhonXnyREe/qWUQtfix5UTrTN0G08arOJmrKPikUhwdQ97E8TzU8uLi1L7W
	XszyfGGPXrygcfQovtNBOewFPXgxzszS6he8wguaOY3zWTHG3EjdxdFYpy9a	SxWEYCLNnOjov+b83vPjpRBRnCwx71Zje/lEnifxUqYLLfujK68rl/E0w0i8
	CqQhCUk5byxfDg3c5CA27Ukvvm4UwSyfJx0hVJHPDLQpe9hEyjiF6jqngTzW	ujk/PTruHvaECKJZdc67n8Y93sUJ/m28lpcq2sgztTHyrTJymIJcHclREPla
	6a9qHqcdfuzMrHNKe669AlcQ4xdFYsWQ98ZMEy0vLk7ca+3EVVL79ym/D0Iz	KpohIboeiU7+mIWRTtQkCIN0871dSCVznfbkIk1Xpvfs2Xq99hbxeolFp1jT
	FyI12Rzz7lhVz+R5ZuYyn2nZH14F+3JuogIj8erm/OTw3f7BkRBxOmnO+fjz	0DLqt3WKNWiJW6xAZ3nGk62EZyo0mr8XvMWPZW/O4HeeHKloqhMTOzYWPH6H
	6Ih38d7zwSzlpUpX8lStrPygrBzkIFenchinoZaKZsDmp0ckAvlTkaQ6U+M4	/4x8+imeJfruaXUYxrE+147cGuYsiSOZan8RxWE838iOvF7RuTcm1UvwIUp1
	gVn+6BZS2VRDzKWUl8tlMDPLORaNsKalZdSvyxxr0BJ3WIF4ecGT2SPkwd7B	Ai2LtM8jO3IMRp8FCb6zDbzPJmHgd6AyEjtKlaZJMMlSXdUWOUtAHKmZaT3K
	K7hcb+8dP6wEjB8n41LKHwM5hMXpzBovy0rQH/HLyudfzCTT98+bwzCOkaHF	rSDNvCBKn2HlZ2kH/3buiOhnUNWSR9fYFZYBa+geb7GKdQoWNP7QGfMDo5NA
	d2dQysWkModhpyYx05XsyesFMb+yuYadD9JcZ3DRVIc8sidHkPZpnOE7o8qn	G5J9PoDfyRsN1i91NHXKx9zJR4yunw0Hp7C9o+MXndc92N0BcXDYOfPYln+L
	YpzEYQ8exq6g8jyLx0Wum84lJxmIIxe2nQbX11gCsADu9zf5ZisB6Iw+90b8	je5M9QoUgiRry4lR3SO7xzQwq1CBMe+uRwMhPM8TotPpSDUxaaL8VIjxIjAS
	wOos1pa0WQ4YDK9fDM5O5LvDd696b48gxD0hgiAQotfrSTW2eabCXIjRLLYS	KJGBglRO9SyIIDglMc3XiziE2Bz+kN2pNEs0qV6cBOmC9Fylcqk2cqJlZjQA
	wFfMgVUy0pM4haSUXCQq1DOTQE4eOgkXVF5kmhQONMtnZF0qhwOv5FjLwuoI	KJKQT6rvUiPXC43BZAoEDNggkfHMfq9IA9tHcSr13QpChF2nsbwFp2YbGimK
	BiUhkFzf51YuZxqDyQAJxrBBJs3EfW+wj+1Tk0t9v4DUACm5kXfgZrKikaLa	TT3ZN3KlktSuEQBGglQ6/CHbYghyx1sG02kIWHhCGpPAAlldhOhH7ixVAu7v
	NJB9Kxcqy90ase3KOJceLcmiGTA9e/M4ihItxDNSUQa7Z/0I0U89L00CHh7+	/4NME7MfHmSiGQlluo4BS9BOiAzazlS//2HYk0GpqMDgOEvBK6DmbyDeqpxc
	gxwCsx8fZaYZGGS+NBICAbjhC5giqgFpRzKuLUOosSlyyArB4FcQ73QsF5kB	JTFInBEMqAjHM5lOPPljoNdBNM8XkoqYPE/UaiHXYKUoNlPEj6nG+RTvfH//
	iRNyPpWCPVvoLJA/xXpJsOcXkoqEPM3UYiaXEKWoNlMkj0iDP8U7Pzz8CPJe	Pch70T16/fCAZ03eYQs9nWsIIF0TRDDTKvS4/YUYRsDdpS7E06aparUKaSky
	7R++fXzEs3XZYQsdTTUUkC/JMVloDXr8/kIMUmnNXFfq6dJUtVgktBRZb6p1	pkjrqYEXwSwVErDky1SOTIafajWFEESNFA+c5rPZIwH1dNjmB9tbKD5gm8Xu
	ZBEIMUsl5M7lMg2WydNyrSIoQbRICSBp5s2xBKzRSZcfbG6hmMEuq92TH4hz	yPfEeZxABwD4Id6UC9OslUoX8laFgbUQuXd/P3IA8JK0oRTfPtgwB4kwfJDH
	xAx9D1xN8KZemGYtVD6TdyqJI/d95+Fh6D3uNVlDrb5diGEKEuFpIA8R09IO	fhA7+LBJGKOEXNLG0tZggZtyj9+e9vc9xpQK1YLXMax09TWrjIEmdOJZZ8I6
	IfyGAy4Uk6+t7bwKcCV3+O1JfzdgL26QLXghy1bXWrQlGZhCz0x6YzYC/I2M	gL/TWFvFTvTvWUBGEwkri6emNCXIxSpkMdxaICkVtvLZ3LCJ3dz4OlJJEBOz
	dpad6d+KmLwmFU4Zz23tS1CMs8hquHNBsipsFbK/UTzlzW2oU5XFhqTNeuh6	WQxtp85MlbBU4fCYE89SKENCwACXTHZFWiZbFQ/aqsoP6lCYa64/IJSAlEYb
	e2aqhKMK3GOOmeSwhkwvMo0MghyLzAxhtg7xnaYCYQ+Vv5YGBEIJumi0lQZe	GcMoYXE035PXGJVIe3jy55m/IG21qgon94JUVd8FYFUaU1hwi3WqrMMkwPJj
	CZej+YG8xqhMOuYx0xbhjMzV2Spiyyu4kr6PIancUBJzh2WaksMc4OBT+YYF	/tyAcDjcCDRDjTaMLOBUfzoNiNcqDDdtq8zji5Hb9fWLFy9hvwBZIhSIGMYb
	3QhzKUiGGa0YWSCoOtlIVl1nzKOLod/07atXr7EpgJDoRPaVmBVBmqXZzY3g	gjRDs6sbwdKm1rQ39T1xflbhDYTBogD+01gAkuMipHLa77AUgXRTu0i7sAkL
	aZFz7VV7T7DPJryCLlgTMcSWMiB5IUIpJ/0eKxFIF7lFupVPOAgrnRxIsqLP	YbmRA0k29Jkwa0OLkK7RFLbcBgqKivqAc97ca8vbQGHDj1G8jiR0Yq6TVQKS
	hFkrWoRMjaaw566hoGhYT1fqYBrIu1hhv9vULFMJi5jqbJGBooAgWzdZYjuy	PMJsXT0TaxJUc7PCWuCNXKhbjRNghJ+xcsN4MpgVFCN6ChNYaP8jOD7ZCEuo
	lF5hKYhGztSdBgMY4RJE8p0CXgWzSJ/DAWY6vIXAxyvh6Aw1wn/WZas1KRZg	rxGJJG3W2zjCAsxFkmjFCxg6w1JrSG0TpfAdgZ/rtuUzQcIOfAW9p/FylTFj
	IZI+G0HAEgtzraG0VZojdMRhadlOzIQIW+AV9J6Y+aJguTTIXV99hgesUqRZ	KuQ2V1/gAcsUkep6ovyPBpHSX+T72KSd3zMVpdlylwuy6h6SCyedgDD8MJvS
	y7EKby3Sk7/JT8bmvd8KlebFfFsEcsaeUJZBJgFdhEkR0V5qTUKIi/SZyUpz	XqrBIThE+sxkRSlOiaGIOg2xDmwwwSed+6eV2oSxIp37ixzaRwUYWsgtdKgt
	cImhSKQtiQ5isPEXXYanhVolRpHJ/U0O3KMKCx3iVibUlZliX0AkTNk+gF4V	E8XWAFcYsYIAvorz5gxxe1vak8B8NNJPYmM6cBaIjeOQQhU6szVT2tBqH8RE
	v6VA/N6O9iy2t1aGmbG2h1iRm9AklBoQz85JaUNnfFATma+nC87oaHJ0zMfx	+uvogjlamiwdy0kwz+KMVZdpsIbYOHcuJXvM076cBKTbcqJM4IMwcs4IBgKW
	tDAFWy7T4Nxwje9SS47Nk74cx2TacqxsHIIwis3IBWLWYUZ7UI00xHQaRf5f	YUJ7UKYxwnQaRQiQGTUnhC+IoN0L+gieFNZB7NGx0gfF5L0MKQFbA4IU6auV
	WDUlgK+IoN0r+gicFNZB+tZz2gfFFLwsGQE7gwELoVq4xJADKkuxoMRJW6uy	jVHZozIXMwrktDEq2TBTvo7fpKU0onzmgMpFEsqKOZqDJnq8Z81JyR/wZRCB
	FQvlz8mbrJRG1M88TPlEQjk1p1PQRI932JuU/MfZJX3f5aiU+bzDhZXtqY1h	DpOFFrQvEWki7DdLuffD4HKfhu+z10pcXGLdzu7QJ2bJFPKysnk0nEriWRBa
	0VcKccJ/Ml3KzCROHFQX7ZJzHWRjKMmlTIKArcKd9cjOLzlNoJANBTnE3RaW	LM/qeV0ThQPI0IZUgoCvwKWm5+eXHEaQS4f8LCTvctttQWRysIK0wgCmaJ0y
	u4LI5GQEyboFDNE6dex/Jk8Ig1Maa1mCp0Q5o6llQGFRURloZefy83BEhSr9	NniCILRiyRfIyjKInJGGeUgJmJGtyw+jcatt/5dX1/z5ZvDfH4Y3gzP6PHrb
	llfX/Pnm7L8+D27OTunz8EP/4qL6UI4Yfrj+fIH3wn+qZ55cX16eXZ26yXgq	v7goPgg3YvT2+sPFWfmpnHl6fXk5uDqzk/FU1h6J1mX/55YVeOv6/Xh4fdW/
	1x5d9n/pOL12rj+NBtdX/YuOy7liKypZk59DJ2PnGgBDnTv5IFcKkVbjC+Yc	aNlorMplAgBIY2JtBiipU+aMQBTlI/7HF8w5OX3/z390X7hw77DbPYa7sF9e
	n3yS+698Tnewv/8OMcF9ebv/BlFJkLQbUOe+Muoj4mtFMR1GkJC9xqhKXBpm	d1/BYzGjKyBov5JDEIgGtCJ/D/mHpMkBUicboZkF4TNpDGnvL8SZX3vyrxN/
	Z4TCZDalMF1wJvOuGgzN1oI3FOvTlJJEwBwqKvJQqj+862Ed7w6bkZC2eyaH	1X3xN/eADlx7mPOs9pB5tv1ka7Jl4o5HO7YpuFl73uB0nd7+z7XvOd8rD//6
	FYaJkalntSZt2JrLvvxOrEoL8Kbo3iC0mYr0K9Mn6YyOh0+MQzTSCexEKxgy	fUghSqf7+vu/CUnac8oQklnnV5QtqgULZxnGxW25ZAD7SHYJsSg/dFCEdRw8
	wjuoqKYOOChiQOYcp3anOOJSuaS3630HYUgnZgms/+OPP+Cxa8Pk9fHHs5OR	bIcGpKxP5KjAdDGOy1m1SVvGZcNRtxOLxcCZUbxTIbQanPULWyedGJ+MHhkH
	HJyeXY0G54OzG3l09IN82Jcvkfvty0P8eYNPL18/8gJsyoi4qKhyiirkL+tL	76xDmIdWsFzEO6CimDrkKAEDEosUJX4EU66+5PS2HVjALeswXsP3/fnnn0Cw
	sixgRmYe5zAhl+61eK2rjp8ocjqGq3lKHg9Gcji6GVy9J2ROdDoFq190Zpy6	xjB5ffJucDqWw7PB1Xh4PhzcyF7vO3nflc8RDHflEf68wqfnLx94AbZghCDI
	Bux2XG1s0ylq4luPxhwBaQ31VCoEcxRl1tesqJpZNRtyhfJb4CGgiDHjwsKn	eFPysgQQzSWZF7CeeBmksBwbANfOWqZhP1IkYQ9czFPyZDiWo/HN8OoNeapQ
	oBwrOdy2YrgvdEowK1XEVUijSEIABdKKuVaEs5OCko6xp4kE+sEsNWcU65QS	R3Mc9ZNOYiuuIeMMp1+7ZIoE/KPzThwR0BrqsdgQRijyOLiaYlbTDDbfwuvt
	7HF2Au/tcX5ION0iAdaKbCRy9dPDA5s1tiSTbNLgGGDjthIAUnuFWIdSKqMm	wEOPPOiCMy0XlHPswOFHLaZxmV+O3rmIOC2rZI0IKOB5xFIr8juzjIKwiaOJ
	VCwuSXhPSrpLo6hAcTFNMMqYRdXPcCUUZXNxWCDhcNxNTALzJRzwXlG6ertS	GPo2XmuOsJqUEs5ztAbQ6nDATH6rRgK0FdHZ1CaU9/es1tiSVLJKgz0AK7eR
	e249GHNS4z4265hXwX5wELxaq2aqoZ/T+LdCD043p7xdn8Ie4Ddwduvjolm4	MOLSKkTTd1BeOaPseU3Me5TTbRpFGZv18YLBNV4VpSabU1J4G/hwqO50sziE
	3NmB39jAZFviFd+ghoQyRqzU80W+8jtYpwaXdnCWySqm7RDdGhJMfCAtdd60	+hIOOKvITb2euj41zvtwkGc/VhO7F17XO/ReNNK7YuiHKPg908Oz7Smvm1PY
	CkuS3Yj63BOgrbotNXsMKzlEQGjMw9B4Tk1CQTDLoL40BUTQgMyn1B84xK57	AtwGVm9dnBCvbDJhIX8SQ2Vr7BVfoIaYMkFwoJerdON2MFYMNgzjqJtFTNvB
	GTBrjgUNQrnd0WVQKUtV4ZL+dnFDZLGZw/3CGbHrySXJe1oJdiiNgghnpbso	nVc4GLrIIZd5VSsMcXYrCuIiCW3VronZYVh+QvjByjwMDZYBZCPwnJCW05t1
	0ey6sDwdOm2FES8k4g21SIa3TdZgwfzVVSsQ8bAhRZVAMym3/Vx5RXIB5Xmr	nIELFdR8TAM8C9plfQeazU6wQiuXgNqMK3n6LmwiVE/4iDLWdIX1Un9BZ3Y0
	7eOJ5g2c1hxS4VOiBXdKsICM3MsitjPsSw23rgd/P7TR96JEdrXQhMlZlKoK	E/sdwYQ9FFuCj4vcZpSo1qKYqRaidmKJ4xSdDhlagrfVw0GN+avN4cDnUYWV
	lAVJxhmQYiTteVT9PDp/O8TsFDnc+iSSQAlRynpXtM1Q0h7+p2LJ6Ph0n/45	KoR4Ii7L2qSTOAPa01oxzBHNG1jRWbjCp1ALrh9hAaq80cssMAvsS1VRWyxb
	qAJK3KpUPIMeKS2TVpfZHpAnZdfmkCphjC6p2g9eBq/hXYf48yagveifgx+e	cMRmR1fqk9Y5UA7H8AeITqaRKjBaEI+sPvFuhK0dh7MfxuevR1gnmntb84gd
	7Z3s7bkNKz1RuKEY1bD3CgfYs12HiL2ldm5OgZ3Njsk+uR2RoNCJVt6DEaJR	OWgp44zTVJ1LffhXeZfDI9ktvEtQS+P4oO0cNg1TVVYhHDrP8prWkS0UBCVB
	+8lvIIkLZWf3yPKtyxKHFC5cmqGrx3zgUYPeZhpb2X0+K1yx1g4drn7YHikZ	Xe+59xLGdoQ/r7zDI6/73ZOD04MDu1shLHI85K0qml8gAtu4LZ6x3ZRmzsmB
	LOsODSf5dYLRwsID8LD/FHw27Z31tzn3zQaOlnrw2WyliSfpqbttG/uJWmCB	Vd0JqSmXakKkgNONs2U4a2TF8guYYp3a4A75D3VKENuMyHHYgEMXj7E2sKCA
	/AbZdSRvdSfysrbV4mtUuL6KH+lqp/tQs3W44uGJjkujFCF/Znd1VfSCe9hc	v+0IvlD+dJHZNLbuRGxmtdtnMmyW1StOf8pQo4aKhzhD9zEgrSq91dKtua+a
	/sh29VM2X1u5ATU6YBICsE8S4ySLF3pKbPF23VNUYItr2FqmJwmBbVnvrheK	c2UhCBd3FqJ4lKCyErm1oSg55skv0F069VrlJs3Tfi0+R4WtOYFUIDAotonl
	VN06a6qLQ7ahqordVPzLTaPhyrhVF2/Mevctc0H+lHiQALoysrEOSxYapJNY	na9ZQWzq9Eg9qpKIkV2zzdoSw4obDpz8yXrul5ema4EClYGgFcJSYCOuvGD0
	Ve4wYkv1yy0FSNIv7OrqsiKtSvWaQyrvKZz78d4UsM4mWw3RciMfwdXlpWEf	KPOC3SpAboIVr6JyiZ6FBL15QaCZSVP6b5WqzJ5ZlYo0f1v+z7d1h0sHtcLB
	CYJJ4KRE8+jm89nWGL1WmddEUpH3LUIFCHW5SD1Px6zXyte+QrJkY849uaJB	1qzjLT/cUBoEVKEDCiAtYxtLMj9ChXRirUotTuwsEHDVBfx0S9vSQ56VF9WM
	7nn/YngWoC5L4tuv5ntPoA63YgU3AMmbfc+TM51m54BSRbb2MDTzuYk41Vzv	8oxUASEPL/MZTn2w0vbRCvZaAIfDtbGq30fQEIcwVyJ7fPNh4H1N+aIkk9Kw
	vcACHE81AlQVZDH/Svm4duRim5GzVc0oblos6XwuTrmbwRb/M3ky8njqr9A2	L5EKEkGsDVHKmTpg6RZ29zmiWa1TRzEtV9J83r8YDTwkbGHw8bOB4CMgxFVr
	m60IWbYM3GlLuz3XrdqCnDDQYWxIMLK+fVBuVS+yTnlrKYppmXb2s77Senrt	rvyk1rpdgZiDoGoVhaJI1n2fWl3xlKPQZpkKumDPhRUL8r08vcyWn8ktGw0q
	FvJ9f1POZtPaSktVvfiiSijZUkQ7NpUHC7QvG3N9AMVnWgbpXJFCr4RSZXnd	w/UycqXNVEdxCWdNfdUg4toOq9RPZNkI8qkYRdtsF2ZkXkCxval6LbNd1FA5
	SgaX5OJlaEW6S22/JFYARt8zwqLIiiIkhUjjtizAHQ2Kio1+CFmUxXvrzr+s	kAD9OChgpbm9l29VLtKkvLYUublEWz1qrtSMve1CrksS57NZxXbSUqQ2LuMS
	bldHiNtgyWSur9YAY+9JvhOdgyhG3Q1rsRw9LMVA5bsOUI+ZpvEXvbUPFkgu	StZEUXdXeRuG9mWlLtt13AGMEehlESRLiJXn3rUwcU3mnntbxMJUIw0DBaB0
	Y9uCEJVWnBQoY045y2+d3jXW2xnmeiF3VLC/S6ppnOBsweA6X/C28pTquKuV	FTQsimhpinAR4d2OBbjKQ46yUrkgnTJ4b2y30Oh66gRXjiPFiUXYWsmIzMmV
	wee4C79+8li1o5sl6JJyplqEWrQ9trshMq9m61pPNJO6FxRl5/go9QQ0xZo6	7VPQxCC8pSyG3Ykhr6hcRQLSiedR8EnvLAp6klPcOh9EIRTLBAqlI84Aaq3O
	ys6EDUPYk6dsVGCUJ0JOqN4c+IQqoXsVHnGot1L7Ax+2MAxs7RPJ1vnZ+p7x	ynp7o1Sv5J7yuvskmUq7awcclxGEU5XHJHdKbZgERscti2abtijdV9PTNUVR
	dJYL7vs30TAFNpDCwgRYTSpLDB8g9ED8JJ4W2fqpjLJrB03c7ORH7H5IeuY6	JQe1qJtse4tlTsrGVuNoJhU0MtIQ7KFnICnQVHy3ChwzjD3akaTEI2+fWZ7m
	ijl6yyFXhZvMl7jJzK+IV1Hu5wfR2SEvbTk9wKoT8uixnpDAC+s761uxm4xa	ygBehgGhnwUcqrqUxsCNKcaA3W5T1nqNzT2D+SIV3CKp4mEEZCB5+SEQmyQW
	NIsxhtvyqgzjLhVLync+neuPNYYvMj7UYBN2agiz1SI3fKDpEiCWVlXVLIps	xrbXAuJnwTxLmh0sZRpdOS788iM2PgRBSz0NLEEjThi3D5/jJh9+Q4cV+X5u
	QZ1t6oNxd1wJ34bOtOvdco+/aQpN76eO95OnAL4lLOgYuqAjCryFx+lGb2Vb	EPVZeWnDgQJWnZE9T/SMGJ4Z14TYid6k06KapDHYjvKm0alLoSzLc8OfaAxf
	bbp+1tUIz6Ldhm5E8kb73LfjY3/mxqgJCii6HPEU5/3rLrPZkpclS0Ed4Fqm	Jdz/YQ22cvCTzSqNuflrwyHmVpHorLJkRU0AKpFxI0EJV7FPtK1jczukqgpV
	NInvHYBha8HyImwDzJm78gDNB5LWXi4NWbMqFw7sFrCrLgyoLfBBDkf3Fahl	26fmwKMNE1ceF9Syz6ibg7cwOF0pu+zKWZt9wYqTFvWSfMWfVzoNrnMRuP4k
	3nJaDx+usqqPKNrQthbmuu3bCu6QzXcfxsTbgvIhbjYWEP/DQ1hmABW9vaaA	YyYoIN/S4ynW+BtObrt5IfMTeaV3q2nSLLiz6IWdBbOLgA0YF9/moaPzIrWt
	Hh8FRDiLkST5g2cSMkH1HHAfeXW3DYBAf0MIJdwLhvuSU5Srd7EpLCn6mwHg	bBGhoVTWF5gdUFfcrVA7wKMtuf7D3YOazTrwsJlW2cypA1vDx7XrFztsO9IV
	yqS9KriJTSO+a1z74RsMKETNlA6muD1DPtLq0T88fPx5tNF08oXQj4PeKV/v	JSZ0thUFRVyGzMD9+3s/d/8FvZ0qgx4eBFi4CCZB3qQnJif5rRon7br8CfK3
	6v2Kib2IKmuSiLt5l1m1f8jF6agVXkiNT7dQrXtVthar6ELNW3eRjcofhsLG	mJCDvWCwz0+K3PU2iDNDcv4i/F/FUafwbGJbh28rd7X4sgcS03hOLTwu3JCJ
	UXXD17hT2mKcIZXdjdJtjqSEVNOMXY2Vj+Wmhcqw31RRYCY75bpHJdIidFKy	1JoW9/fvfhpvlaNcXvT9l28BcbI6rjkXEuPjxVVjX+VFx8K3UFmXDF1PKRdi
	HposK7g660qdhz7Y+p7Iek7KtT2s4i6mfD5d1Ts6c8PsJon8jPqrazkp98Sr	JKx09SumxjXU2sEZUesVIrY9isHZqxJszRO2O1YFLD7PVILd54qcNGktp0Mq
	mVWZ4DIHBhDi1tnJvLzUV5/xq5Rz2Yzu/M2UnTlLhIzZOShFoKQSoqWzbEbf	lAZulCJ4P06SbGVruZWysmhGpxybQj1uA4ruo025mdU7zK7Sys+oBNswWy6b
	Qf+qv4G8z57JS76QJuszAzg3DWUE/Q0Fk78OpKJordeKCdmqzOk6w8tBjfDl	FzOLpMEGEAwkdGyrMMu8qVhejFARZ7lIe0MqAC2sSoLZbCUUKVT6/4zCw/5V
	3UOxsXoHq06ptl01Dh9WvlPz5uDdu8dHpM6/y1MdxnMwR5/Ial3x3Pz5Xd7o	fwuBnzyRl3ydUJZtBVg5DeWy0nTqtLgswmJYssnjudbocljiO53p/Q/Dv4ut
	CSACiZ2Vv4vfe+VP/Wn9p/UGU6jF5NeCxyLkkdeWUNk72Ds4xJt/keP3QN2/	NVuwnjnluZtKV2LjqjavDo+PHx4QNv8hz7QfLHEk+kRKaxPp6s8f8kbPgBB0
	sQtJrDpn+U5JuTap2C6pelVbi+h7xPId4tgQw8vXshZDC7i2sH9TthxPWy3H	bVH+If7o5D/lp+ZP7Q2myO7hoVsLBguHR0abI2Xn8ODwiHY5P+XrqTSM+VQ0
	K8pm+2WPkc/IkMYY5/trTcBuO20mR+D7YXyIm+qlk8j14JRun/I5wFf6nHVj	YL6KP7ZqKnbzp1zLlIz5FmZ8AxO2Dv/8pSwPX0OrHYe+yYuPZ7Xi4xUFsP28
	k2v379fIE7bbEX9FDdt//oKtftty98uV/4Q+NhS5VU50FcNfi3nCSrdvJtqb	1MgtM4QusTX4RgWw3QiUA3d/jpvYkV5bjlwPkWQnPrcFPlfxLOqblLl/tRwe
	NQyYirAKIaqrVMClS8SnKddTsnnNcwfb7oorvoxt5c7l4LgEqBu3pEOu3Y67	0dOW+HeYv/vn39DLLwiKxeBW/gopbImv4A7dSUkdfx5RyN07iPoOFV2lDKuA
	BO1DEJlMueXz8vTH6SS2ohNbQ9eUg8hEAWeyqc6D8l5OUKGrDRa38X1Alip3	gOJaGSD9Ev5nzsmSrF7A3cO2++KKr30buXc5PMlx58YuaQFpv7IF39h2vobU
	NnvEu50tu/GBXj7LNEWRpJj7g32+moE4jALtS3npq22Arhn1LWP6HrvZZiIH	JH/xNG8AWYkERrQCE3txMvem8dTjiDXSqZdfVfIK9DTe6mNw55F2yr1mXXi/
	lVe3m/Dr1nBesF7KXiL7BV2z42qyPvOfK4p5IeIlX+7x7jP0Nx3cNb0bV1ZF	tWMvZl+6SDS5hzBbRsbVHaHFcLfIwj7l9+DqymeLT19SpG/RmW0QKxRvq+be
	cmEQBVfubsDaCebb/YPXnD/wPVG6Z0QRyl2Qdup2jfrqyL0CR2RBdIfoARI2	1ITzjMWT1w/ZJujmIaeM5V2HpSKP5sMR8m0nZzojd7fD3lx0tzqmchXDx23I
	O6hiqxZm1Gte2d55uQt0iXZe78pS4RjtL+k6ve8c7taB1dI30v7Om10fCnb2	FW21MF93D19ymMA3Z+niFfkfe3ndSt2V+av32W2g7a723pLfIO+J1ABEWnWH
	3PgnAsMOpLsrH4U4PTsfXA3owsRQDi4/XQxOBiM56r8f0rmGOD57P7iCt11+	v/jF3Xj/1ePyPnaPvK4oevcFrCJoojrXPSQV7yHlLUqf0071Wv7e833g0nTv
	ur4ZDbHgcPD+qj/6fHPW61+8v74ZjD5c4un5zfVl4/y+dgjshQRXQkoQ3r/8	5b7M1Qaj3dVqqz17R/ul+zX0jXRo79W+cx17B3b8I45kD65mXz4IcTY4H14N
	lfF/M2H/Cxl8vxSactgkcu9g5/AtSUPK/mh0Mzj+PDoruSLY6J1Qcy4drRba	6eLDSA4v318MT4djOe6/GVE7RJwM3gyvYLGX769vxiMqIg7fXPXHH24Gnf7F
	Oo7+/zBErx15zAYGPsr/JMOsa6bKDJuh/0/ekfA8Cd7wO9hqMkSTt/MECmge	m+ub4fjtJZ6e31xfVi4ClPbVod/NkBLchhAKJjFh/wsefDsXqnzYJvLgcO/o
	4jcs0TYcfIuZOXporQaNa1zQ20/9m/7lUPZvzuiCOkgWj8ztnzrG+79ll0jY	NXFDyv54fDM8+TAe5KciFOqcUikvGm9W2tgT/f85EL225PExMPBB/icpeJli
	YSx24AbCVF7TVNlezerol09njeNLxJfBf59JGMFuSxCn8viXzeNQLH92deoO	FWpYDRW+8rKFO5PgDb/hWNUD0eTdZwIFNA+eH5poKkCxQ80sPbRWhcbGKejt
	BAFPIV0DTeiiNLcBxcOR+09DOvqhM1GJ1Z1HChAqvWUEPTZjeYzkvyuvYhQi	+/5N/3Ik+zcDuvoPksUDn/arun//t8clEvaA6IBI0KTSkpxC7cpTjn9+P6g0
	H1S2KO93Ds1iFgM4w9k81lOOrlQKurvp1M9XWbISKImy6iizlTDxYYXfpp/o	POGphv8zkJD/fo0HZ/Lk5+0eKpYfXJ3ZViIQzqertSHdPudqobjv2V900tPv
	e/lerVLjLqa50sSdGiVxyhVQiKUEvfRFX3P+TWEtaixUodrFeVX/b6I4XRR5	WvzbL60HQj4VfWQQvr+/P4kn8gQJwgN1LfH9KkC28lYlK53wI3sn434UrxYB
	IP4HSdsI4Mo1AAA=	oNhfLAM9f7A3BSSlkfZXAKghoJJwI5BOJUVPtBZ3ccej3Lgf6jv5Rm2iOMmX
		szmNbUKFQcRZk48FBb10aWNjlZvMGCRqSGX1Jl9GFXeqIblVlnriX1Z0FnOC
		NgAA

	-->	-->

	</rfc>	</rfc>

End of changes. 63 change blocks.
	459 lines changed or deleted	262 lines changed or added
This html diff was produced by rfcdiff 1.48.