<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 1.7.30 (Ruby 3.4.4) 2.5.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-x509-alg-none-10" docName="draft-ietf-lamps-x509-alg-none-latest" category="std" consensus="true" submissionType="IETF" xml:lang="en" number="9925" updates="5280" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.1 3.31.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-alg-none-latest" rel="prev"/>
  <front>
    <title>Unsigned X.509 Certificates</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-x509-alg-none-10"/> name="RFC" value="9925"/>
    <author initials="D." surname="Benjamin" fullname="David Benjamin">
      <organization>Google LLC</organization>
      <address>
        <email>davidben@google.com</email>
      </address>
    </author>
    <date year="2025" month="September" day="05"/>
    <area>Security</area>
    <workgroup>Limited Additional Mechanisms for PKIX and SMIME</workgroup> year="2026" month="February"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <keyword>self-signed certificate</keyword>
    <abstract>
      <?line 55?> 56?>

<t>This document defines a placeholder X.509 signature algorithm that may be used
in contexts where the consumer of the certificate is not expected to verify the
signature. As part of this, it updates RFC 5280.</t>
    </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 list (<eref target="mailto:spasm@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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>
  <middle>
    <?line 61?> 62?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>An X.509 certificate <xref target="RFC5280"/> relates two entities in the PKI: information
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 between the
subject and issuer.</t>
      <t>In some contexts, an application needs standalone subject information instead of
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
a trust anchor, anchor or root certification authority (root CA). The application
trusts this trust anchor information out-of-band and does not require an
issuer's signature.</t>
      <t>X.509 does not define a structure for this scenario. Instead, X.509 trust
anchors are often represented with "self-signed" certificates, where the
subject's key signs over itself. Other formats, such as <xref target="RFC5914"/> target="RFC5914"/>, exist to
convey trust anchors, but self-signed certificates remain widely used.</t>
      <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
identity, instead expecting the relying party to authenticate the certificate
out-of-band, e.g. e.g., via a known fingerprint.</t>
      <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
an X.509 certificate.</t>
      <t>Computing signatures as placeholders has some drawbacks:</t>
      <ul spacing="normal">
        <li>
          <t>Post-quantum signature algorithms are large, so including a self-signature
significantly increases the size of the payload.</t>
        </li>
        <li>
          <t>If the subject is an end entity, rather than a CA, computing an X.509
signature risks cross-protocol attacks with the intended use of the key.</t>
        </li>
        <li>
          <t>It is ambiguous whether such a self-signature requires the CA bit in basic
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>
        </li>
        <li>
          <t>If the subject is an end entity, and the end entity's key is not a signing
key (e.g. (e.g., a KEM Key Encapsulation Mechanism (KEM) key), there is no valid signature algorithm to use with the key.</t>
        </li>
      </ul>
      <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,
without any specific issuer.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name> anchor="requirements-language">
      <name>Requirements Language</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 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">
      <name>Constructing Unsigned Certificates</name>
      <t>This section describes how a sender constructs an unsigned certificate.</t>
      <section anchor="signature">
        <name>Signature</name>
        <t>To construct an unsigned X.509 certificate, the sender MUST <bcp14>MUST</bcp14> set the
Certificate's signatureAlgorithm and TBSCertificate's signature fields each to
an AlgorithmIdentifier with algorithm id-alg-unsigned, defined below:</t>
        <artwork><![CDATA[
  id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}
]]></artwork>
        <t>The parameters for id-alg-unsigned MUST <bcp14>MUST</bcp14> be omitted. The Certificate's
signatureValue field MUST <bcp14>MUST</bcp14> be a BIT STRING of length zero.</t>
      </section>
      <section anchor="issuer">
        <name>Issuer</name>
        <t>An unsigned certificate takes the place of a self-signed certificate in
scenarios where the application only requires subject information. It has no
issuer, so some requirements in the profile defined in <xref target="RFC5280"/> cannot
meaningfully be applied. However, the application may have pre-existing
requirements derived from <xref target="X.509"/> and <xref target="RFC5280"/>, so senders MAY <bcp14>MAY</bcp14> construct
the certificate as if it were a self-signed certificate, if needed for
interoperability.</t>
        <t>In particular, the following fields describe a certificate's issuer:</t>
        <ul spacing="normal">
          <li>
            <t>issuer (<xref section="4.1.2.4" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
          <li>
            <t>issuerUniqueID (<xref section="4.1.2.8" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
        </ul>
        <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 issuers, so such a value may not be
interoperable with existing applications.</t>
        <t>If the subject is not empty, senders MAY <bcp14>MAY</bcp14> set the issuer to the subject, similar
to how they would construct a self-signed certificate.
This may be useful in applications that, for example,
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
self-issued.</t>
        <t>Senders
        <!--[rfced] For clarity, may we update the latter part of this sentence
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 consisting of a single
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>
        <artwork><![CDATA[
  id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 TBD1 TBD2} 25 1}
]]></artwork>
        <t>This placeholder name, in the string representation of <xref target="RFC4514"/>, is:</t>
        <artwork><![CDATA[
1.3.6.1.5.5.7.TBD1.TBD2=#0C00
  1.3.6.1.5.5.7.25.1=#0C00
]]></artwork>
        <t>Senders MUST <bcp14>MUST</bcp14> omit the issuerUniqueID field, as it is optional, not applicable,
and already forbidden by <xref section="4.1.2.8" sectionFormat="of" target="RFC5280"/>.</t>
      </section>
      <section anchor="extensions">
        <name>Extensions</name>
        <t>Some X.509 extensions also describe the certificate issuer and thus are not
meaningful for an unsigned certificate:</t>
        <ul spacing="normal">
          <li>
            <t>authority key identifier (<xref section="4.2.1.1" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
          <li>
            <t>issuer alternative name (<xref section="4.2.1.7" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
        </ul>
        <!--[rfced] To improve readability and avoid the repetition of "include" 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 an
   exception for self-signed certificates used when distributing a
   public key.
-->

<t>Senders SHOULD <bcp14>SHOULD</bcp14> omit the authority key identifier and issuer alternative name
extensions. <xref section="4.2.1.1" sectionFormat="of" target="RFC5280"/> requires certificates to include
the authority key identifier, but includes an exception for self-signed certificates
used when distributing a public key. This document updates <xref target="RFC5280"/> to also
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>
        <ul spacing="normal">
          <li>
            <t>key usage (<xref section="4.2.1.3" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
          <li>
            <t>basic constraints (<xref section="4.2.1.9" sectionFormat="of" target="RFC5280"/>)</t>
          </li>
        </ul>
        <t>Senders
        <!--[rfced] FYI - We've reformatted the following text into an unordered
list. Please review and let us know of any objections.

Original:
   Senders SHOULD fill in these values to reflect the subject.  That is:</t>
        <t>If is:

   If the subject is a CA, it SHOULD assert the keyCertSign key usage
   bit and SHOULD include a basic constraints extensions that sets the
   cA boolean to TRUE.</t>
        <t>If 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. That is:</t>
        <ul spacing="normal">
          <li>
            <t>If the subject is a CA, it <bcp14>SHOULD</bcp14> assert the keyCertSign key usage bit and
<bcp14>SHOULD</bcp14> include a basic constraints extension that sets the cA boolean to TRUE.</t>
          </li>
          <li>
            <t>If the subject is an end entity, it <bcp14>SHOULD NOT</bcp14> assert 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
not issue itself, so there is no need to accommodate a self-signature in either
extension.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="consuming-unsigned-certificates">
      <name>Consuming Unsigned Certificates</name>
      <t>X.509 signatures of type id-alg-unsigned are always invalid:</t>
      <ul spacing="normal">
        <li>
          <t>When processing X.509 certificates without verifying signatures, receivers MAY <bcp14>MAY</bcp14>
accept id-alg-unsigned.</t>
        </li>
        <li>
          <t>When verifying X.509 signatures, receivers MUST <bcp14>MUST</bcp14> reject id-alg-unsigned.</t>
        </li>
      </ul>
      <t>In particular, X.509 validators MUST NOT <bcp14>MUST NOT</bcp14> accept id-alg-unsigned in the place of
a signature in the certification path.</t>
      <t>It is expected that most unmodified X.509 applications will already be
compliant with this guidance. X.509 applications are thus RECOMMENDED <bcp14>RECOMMENDED</bcp14> to satisfy these
requirements by ignoring this document, document and instead treating id-alg-unsigned as
the same as an unrecognized signature algorithm. An unmodified X.509
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.
Conversely, in contexts where an X.509 application was ignoring the
self-signature, id-alg-unsigned will also be ignored, ignored but more efficiently.</t>
      <t>In other contexts, an application may require modifications, modifications or limit itself to
particular forms of unsigned certificate. certificates. For example, an application might
check self-signedness to classify locally-configured locally configured certificates as trust
anchors or untrusted intermediates. Such an application may need to modify its
configuration model or user interface before using an unsigned certificate as a
trust anchor.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>It is best practice to limit cryptographic keys to a single purpose each. If a
key is reused across contexts, applications risk cross-protocol attacks when the
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
self-signature,
self-signature and the end entity protocol. Unsigned certificates fix this key
reuse by removing the X.509 self-signature.</t>
      <t>If an application accepts id-alg-unsigned as part of a certification path, or
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-certificates"/>
prohibits this and recommends that applications treat id-alg-unsigned the same
as any other previously unrecognized signature algorithm. Non-compliant
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-rsa15"/>.</t>
      <!--[rfced] To improve readability, may we update "etc." to "for example"?

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 limited
use to convey trust. However, some applications might use it as an integrity
check to guard against accidental storage corruption, etc. An unsigned
certificate does not provide any integrity check. Applications checking
self-signature for integrity SHOULD <bcp14>SHOULD</bcp14> instead use some other mechanism, such as an
external hash that is verified out of band.</t> out-of-band.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="module-identifier">
        <name>Module Identifier</name>
        <t>IANA is requested to add has added the following entry in the "SMI Security for PKIX
Module Identifier" registry, defined by <xref target="RFC7299"/>:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Decimal</th>
              <th align="left">Description</th>
              <th align="left">References</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD</td> align="left">122</td>
              <td align="left">id-mod-algUnsigned-2025</td>
              <td align="left">[this-RFC]</td> align="left">RFC 9925</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="algorithm">
        <name>Algorithm</name>
        <t>IANA is requested to add has added the following entry to the
"SMI Security for PKIX Algorithms" registry <xref target="RFC7299"/>:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Decimal</th>
              <th align="left">Description</th>
              <th align="left">References</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">36</td>
              <td align="left">id-alg-unsigned</td>
              <td align="left">[this-RFC]</td> align="left">RFC 9925</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="relative-distinguished-name-attribute">
        <name>Relative Distinguished Name Attribute</name>
        <t>To allocate id-rdna-unsigned, this document introduces a new PKIX OID arc for
relative distinguished name attributes:</t>
        <t>IANA is requested to add has added the following entry to the "SMI Security for PKIX"
registry <xref target="RFC7299"/>:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Decimal</th>
              <th align="left">Description</th>
              <th align="left">References</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD1</td> align="left">25</td>
              <td align="left">Relative Distinguished Name Attribute</td>
              <td align="left">[this-RFC]</td> align="left">RFC 9925</td>
            </tr>
          </tbody>
        </table>
        <t>IANA is requested to create has created the "SMI Security for PKIX Relative Distinguished
Name Attribute" registry within the "Structure of Management Information (SMI)
Numbers (MIB Module Registrations)" registry group.</t>
        <t>The new registry's description is
"iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.TBD1)".</t> (1.3.6.1.5.5.7.25)".</t>
        <t>The new registry has three columns and is initialized with the following values:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Decimal</th>
              <th align="left">Description</th>
              <th align="left">References</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBD2</td> align="left">1</td>
              <td align="left">id-rdna-unsigned</td>
              <td align="left">[this-RFC]</td> align="left">RFC 9925</td>
            </tr>
          </tbody>
        </table>
        <t>Future updates to this table are to be made according to the Specification
Required policy as defined in <xref target="RFC8126"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-jose-deprecate-none-rsa15" to="JOSE"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="JWT" target="https://www.howmanydayssinceajwtalgnonevuln.com/">
          <front>
            <title>How Many Days Has It Been Since a JWT alg:none Vulnerability?</title>
            <author initials="J." surname="Sanderson" fullname="James 'zofrex' Sanderson">
              <organization/>
            </author>
            <date year="2024" month="October" day="09"/>
            <date/>
          </front>
        </reference>
        <reference anchor="X.509"> anchor="X.509" target="https://www.itu.int/rec/t-rec-x.509/en">
          <front>
            <title>Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="ISO/IEC 9594-8:2020" value=""/>
        </reference>
        <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 developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4158"/> name="ITU-T Recommendation" value="X.509"/>
          <seriesInfo name="DOI" value="10.17487/RFC4158"/> name="ISO/IEC" value="9594-8:2020"/>
        </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 anchor information. A trust anchor is an authoritative entity represented by a public 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 document are intended to satisfy the format-related requirements defined in Trust Anchor 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</title>
            <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way
        <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.4158.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5914.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4514.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7299.xml"/>
      </references>
    </references>
    <?line 396?>

<section anchor="asn1-module">
      <name>ASN.1 Module</name>
      <!--[rfced] We note that [RFC5912] is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 Representation 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 keys to entries in the directory. This document defines the string representation used only cited in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed ASN.1 module.
In order to give have a clean representation of commonly used distinguished names, while being able to represent any distinguished 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 1:1 matchup between the JWS algorithm "none" references section and the JWE algorithm "RSA1_5".  These algorithms have known security
   weaknesses.  It also updates text,
please review the text and let us know where a citation may be included.
We suggest adding a sentence before the Review Instructions for Designated
   Experts ASN.1 module to establish baseline security requirements that future
   algorithm registrations should meet.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-jose-deprecate-none-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 Group was chartered, an object identifier arc was allocated by IANA for use by that working group.  cite [RFC5912].

Perhaps:
   This document describes ASN.1 module uses the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7299"/>
          <seriesInfo name="DOI" value="10.17487/RFC7299"/>
        </reference>
      </references>
    </references>
    <?line 307?>

<section anchor="asn1-module">
      <name>ASN.1 Module</name>
      <artwork><![CDATA[ conventions established by [RFC5912].
-->

<sourcecode type="asn.1"><![CDATA[
SignatureAlgorithmNone
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-algUnsigned-2025(TBD)
    id-mod-algUnsigned-2025(122) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
  SIGNATURE-ALGORITHM
  FROM AlgorithmInformation-2009  -- in [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58) }
  ATTRIBUTE
  FROM PKIX-CommonTypes-2009 -- in [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) } ;

-- Unsigned Signature Algorithm

id-alg-unsigned OBJECT IDENTIFIER ::= { iso(1)
   identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) alg(6) 36 }

sa-unsigned SIGNATURE-ALGORITHM ::= {
   IDENTIFIER id-alg-unsigned
   PARAMS ARE absent
}

id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1)
   identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) rdna(TBD1) TBD2 rdna(25) 1 }

at-unsigned ATTRIBUTE ::= {
   TYPE UTF8String (SIZE (0))
   IDENTIFIED BY id-rdna-unsigned
}

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