<?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 MAY <bcp14>MAY</bcp14> alternatively use a short placeholder issuer consisting of a single
relative distinguished name, with name that has a single attribute of with a type of id-rdna-unsigned
and value of 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>
        <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 it permits 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 SHOULD <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 SHOULD <bcp14>SHOULD</bcp14> assert the keyCertSign key usage bit and
SHOULD
<bcp14>SHOULD</bcp14> include a basic constraints extensions extension that sets the cA boolean to TRUE.</t>
          </li>
          <li>
            <t>If the subject is an end entity, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> assert the keyCertSign key usage
bit, and it SHOULD <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>
      <t>The signature in a self-signed certificate is self-derived and thus of limited
use to convey trust. However, some applications might might, for example, use it as an integrity
check to guard against accidental storage corruption, etc. corruption. 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"/>
          <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 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"/> name="ITU-T Recommendation" value="X.509"/>
          <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 that 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 in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give 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 the JWS algorithm "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-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. This document describes 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"/> name="ISO/IEC" value="9594-8:2020"/>
        </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.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 307?> 322?>

<section anchor="asn1-module">
      <name>ASN.1 Module</name>
      <artwork><![CDATA[
      <t>This ASN.1 module uses the conventions established by <xref target="RFC5912"/>.</t>
      <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>
    </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=
H4sIAE1/j2kAA81b63LbRpb+30/RS/+wNEXComzZFncyWUqibDq6eEU6mWwq
P5pgk0QMAgwaEEUryrPMs8yTzXdON66kfJmtrVq5bJNAX06fy3durU6nI9Ig
DXVPtj5EJphHeir/7h0dHMtTnaTBLPBVqk1LqMkk0bc9QV/ncbLpSZNORbBK
ejJNMpMeHhwcHxyKaexHaonVpomapZ1Ap7NOqJYr07nDmh0VzjtRHGk8w6qp
MNlkGRgTxFG6WWHWcDA+F1G2nGise3x8eCSmGNiThweHLztYPlvRd9OTR4ev
D4QfR0ZHJjNMgxa3PflcrIKe/CWN/bY0m2WiZwYf4iSlT7+KUEXzntSRUIlW
PTkanIp1nHycJ3G26kkmVHzUGzyb9kRHGh3OOo4pfskOIVSWLuKkJ2RHSPwE
EUhonXnyREe/qWUQtfix5UTrTN0G08arOJmrKPikUhwdQ97E8TzU8uLi1L7W
SxWEYCLNnOjov+b83vPjpRBRnCwx71Zje/lEnifxUqYLLfujK68rl/E0w0i8
ujk/PTruHvaECKJZdc67n8Y93sUJ/m28lpcq2sgztTHyrTJymIJcHclREPla
KpohIboeiU7+mIWRTtQkCIN0871dSCVznfbkIk1Xpvfs2Xq99hbxeolFp1jT
0DLqt3WKNWiJW6xAZ3nGk62EZyo0mr8XvMWPZW/O4HeeHKloqhMTOzYWPH6H
/4x8+imeJfruaXUYxrE+147cGuYsiSOZan8RxWE838iOvF7RuTcm1UvwIUp1
Ai2LtM8jO3IMRp8FCb6zDbzPJmHgd6AyEjtKlaZJMMlSXdUWOUtAHKmZaT3K
rSDNvCBKn2HlZ2kH/3buiOhnUNWSR9fYFZYBa+geb7GKdQoWNP7QGfMDo5NA
G5J9PoDfyRsN1i91NHXKx9zJR4yunw0Hp7C9o+MXndc92N0BcXDYOfPYln+L
je5M9QoUgiRry4lR3SO7xzQwq1CBMe+uRwMhPM8TotPpSDUxaaL8VIjxIjAS
KJGBglRO9SyIIDglMc3XiziE2Bz+kN2pNEs0qV6cBOmC9Fylcqk2cqJlZjQA
KJKQT6rvUiPXC43BZAoEDNggkfHMfq9IA9tHcSr13QpChF2nsbwFp2YbGimK
TT3ZN3KlktSuEQBGglQ6/CHbYghyx1sG02kIWHhCGpPAAlldhOhH7ixVAu7v
/4NME7MfHmSiGQlluo4BS9BOiAzazlS//2HYk0GpqMDgOEvBK6DmbyDeqpxc
JTFInBEMqAjHM5lOPPljoNdBNM8XkoqYPE/UaiHXYKUoNlPEj6nG+RTvfH//
Pch70T16/fCAZ03eYQs9nWsIIF0TRDDTKvS4/YUYRsDdpS7E06aparUKaSky
pkjrqYEXwSwVErDky1SOTIafajWFEESNFA+c5rPZIwH1dNjmB9tbKD5gm8Xu
yPfEeZxABwD4Id6UC9OslUoX8laFgbUQuXd/P3IA8JK0oRTfPtgwB4kwfJDH
fhA7+LBJGKOEXNLG0tZggZtyj9+e9vc9xpQK1YLXMax09TWrjIEmdOJZZ8I6
gL/TWFvFTvTvWUBGEwkri6emNCXIxSpkMdxaICkVtvLZ3LCJ3dz4OlJJEBOz
WQxtp85MlbBU4fCYE89SKENCwACXTHZFWiZbFQ/aqsoP6lCYa64/IJSAlEYb
GcMoYXE035PXGJVIe3jy55m/IG21qgon94JUVd8FYFUaU1hwi3WqrMMkwPJj
/tyAcDjcCDRDjTaMLOBUfzoNiNcqDDdtq8zji5Hb9fWLFy9hvwBZIhSIGMYb
gjRDs6sbwdKm1rQ39T1xflbhDYTBogD+01gAkuMipHLa77AUgXRTu0i7sAkL
YbmRA0k29Jkwa0OLkK7RFLbcBgqKivqAc97ca8vbQGHDj1G8jiR0Yq6TVQKS
PMJsXT0TaxJUc7PCWuCNXKhbjRNghJ+xcsN4MpgVFCN6ChNYaP8jOD7ZCEuo
rxGJJG3W2zjCAsxFkmjFCxg6w1JrSG0TpfAdgZ/rtuUzQcIOfAW9p/FylTFj
KuQ2V1/gAcsUkep6ovyPBpHSX+T72KSd3zMVpdlylwuy6h6SCyedgDD8MJvS
XqrBIThE+sxkRSlOiaGIOg2xDmwwwSed+6eV2oSxIp37ixzaRwUYWsgtdKgt
E8XWAFcYsYIAvorz5gxxe1vak8B8NNJPYmM6cBaIjeOQQhU6szVT2tBqH8RE
+uvogjlamiwdy0kwz+KMVZdpsIbYOHcuJXvM076cBKTbcqJM4IMwcs4IBgKW
YUJ7UKYxwnQaRQiQGTUnhC+IoN0L+gieFNZB7NGx0gfF5L0MKQFbA4IU6auV
jVHZozIXMwrktDEq2TBTvo7fpKU0onzmgMpFEsqKOZqDJnq8Z81JyR/wZRCB
DpOFFrQvEWki7DdLuffD4HKfhu+z10pcXGLdzu7QJ2bJFPKysnk0nEriWRBa
LM/qeV0ThQPI0IZUgoCvwKWm5+eXHEaQS4f8LCTvctttQWRysIK0wgCmaJ0y
NniCILRiyRfIyjKInJGGeUgJmJGtyw+jcatt/5dX1/z5ZvDfH4Y3gzP6PHrb
v7goPgg3YvT2+sPFWfmpnHl6fXk5uDqzk/FU1h6J1mX/55YVeOv6/Xh4fdW/
aNlorMplAgBIY2JtBiipU+aMQBTlI/7HF8w5OX3/z390X7hw77DbPYa7sF9e
d1/BYzGjKyBov5JDEIgGtCJ/D/mHpMkBUicboZkF4TNpDGnvL8SZX3vyrxN/
1X3xN/eADlx7mPOs9pB5tv1ka7Jl4o5HO7YpuFl73uB0nd7+z7XvOd8rD//6
fUghSqf7+vu/CUnac8oQklnnV5QtqgULZxnGxW25ZAD7SHYJsSg/dFCEdRw8
bIcGpKxP5KjAdDGOy1m1SVvGZcNRtxOLxcCZUbxTIbQanPULWyedGJ+MHhkH
76xDmIdWsFzEO6CimDrkKAEDEosUJX4EU66+5PS2HVjALeswXsP3/fnnn0Cw
xjB5ffJucDqWw7PB1Xh4PhzcyF7vO3nflc8RDHflEf68wqfnLx94AbZghCDI
eFPysgQQzSWZF7CeeBmksBwbANfOWqZhP1IkYQ9czFPyZDiWo/HN8OoNeapQ
R3Mc9ZNOYiuuIeMMp1+7ZIoE/KPzThwR0BrqsdgQRijyOLiaYlbTDDbfwuvt
wEOPPOiCMy0XlHPswOFHLaZxmV+O3rmIOC2rZI0IKOB5xFIr8juzjIKwiaOJ
GPo2XmuOsJqUEs5ztAbQ6nDATH6rRgK0FdHZ1CaU9/es1tiSVLJKgz0AK7eR
MOLSKkTTd1BeOaPseU3Me5TTbRpFGZv18YLBNV4VpSabU1J4G/hwqO50sziE
+hIOOKvITb2euj41zvtwkGc/VhO7F17XO/ReNNK7YuiHKPg908Oz7Smvm1PY
AtwGVm9dnBCvbDJhIX8SQ2Vr7BVfoIaYMkFwoJerdON2MFYMNgzjqJtFTNvB
nVc4GLrIIZd5VSsMcXYrCuIiCW3VronZYVh+QvjByjwMDZYBZCPwnJCW05t1
nIELFdR8TAM8C9plfQeazU6wQiuXgNqMK3n6LmwiVE/4iDLWdIX1Un9BZ3Y0
E/sdwYQ9FFuCj4vcZpSo1qKYqRaidmKJ4xSdDhlagrfVw0GN+avN4cDnUYWV
KoR4Ii7L2qSTOAPa01oxzBHNG1jRWbjCp1ALrh9hAaq80cssMAvsS1VRWyxb
cMRmR1fqk9Y5UA7H8AeITqaRKjBaEI+sPvFuhK0dh7MfxuevR1gnmntb84gd
OWgp44zTVJ1LffhXeZfDI9ktvEtQS+P4oO0cNg1TVVYhHDrP8prWkS0UBCVB
Xe+59xLGdoQ/r7zDI6/73ZOD04MDu1shLHI85K0qml8gAtu4LZ6x3ZRmzsmB
Vd0JqSmXakKkgNONs2U4a2TF8guYYp3a4A75D3VKENuMyHHYgEMXj7E2sKCA
v+0IvlD+dJHZNLbuRGxmtdtnMmyW1StOf8pQo4aKhzhD9zEgrSq91dKtua+a
c2UhCBd3FqJ4lKCyErm1oSg55skv0F069VrlJs3Tfi0+R4WtOYFUIDAotonl
na9ZQWzq9Eg9qpKIkV2zzdoSw4obDpz8yXrul5ema4EClYGgFcJSYCOuvGD0
KPOC3SpAboIVr6JyiZ6FBL15QaCZSVP6b5WqzJ5ZlYo0f1v+z7d1h0sHtcLB
1qzjLT/cUBoEVKEDCiAtYxtLMj9ChXRirUotTuwsEHDVBfx0S9vSQ56VF9WM
8oxUASEPL/MZTn2w0vbRCvZaAIfDtbGq30fQEIcwVyJ7fPNh4H1N+aIkk9Kw
L5EKEkGsDVHKmTpg6RZ29zmiWa1TRzEtV9J83r8YDTwkbGHw8bOB4CMgxFVr
rvyk1rpdgZiDoGoVhaJI1n2fWl3xlKPQZpkKumDPhRUL8r08vcyWn8ktGw0q
w/UycqXNVEdxCWdNfdUg4toOq9RPZNkI8qkYRdtsF2ZkXkCxval6LbNd1FA5
kAD9OChgpbm9l29VLtKkvLYUublEWz1qrtSMve1CrksS57NZxXbSUqQ2LuMS
StZEUXdXeRuG9mWlLtt13AGMEehlESRLiJXn3rUwcU3mnntbxMJUIw0DBaB0
FTQsimhpinAR4d2OBbjKQ46yUrkgnTJ4b2y30Oh66gRXjiPFiUXYWsmIzMmV
7VPQxCC8pSyG3Ykhr6hcRQLSiedR8EnvLAp6klPcOh9EIRTLBAqlI84Aaq3O
ynp7o1Sv5J7yuvskmUq7awcclxGEU5XHJHdKbZgERscti2abtijdV9PTNUVR
JQe1qJtse4tlTsrGVuNoJhU0MtIQ7KFnICnQVHy3ChwzjD3akaTEI2+fWZ7m
ygBehgGhnwUcqrqUxsCNKcaA3W5T1nqNzT2D+SIV3CKp4mEEZCB5+SEQmyQW
xrbXAuJnwTxLmh0sZRpdOS788iM2PgRBSz0NLEEjThi3D5/jJh9+Q4cV+X5u
EPVZeWnDgQJWnZE9T/SMGJ4Z14TYid6k06KapDHYjvKm0alLoSzLc8OfaAxf
Jdz/YQ22cvCTzSqNuflrwyHmVpHorLJkRU0AKpFxI0EJV7FPtK1jczukqgpV
26fmwKMNE1ceF9Syz6ibg7cwOF0pu+zKWZt9wYqTFvWSfMWfVzoNrnMRuP4k
YyYoIN/S4ynW+BtObrt5IfMTeaV3q2nSLLiz6IWdBbOLgA0YF9/moaPzIrWt
bBGhoVTWF5gdUFfcrVA7wKMtuf7D3YOazTrwsJlW2cypA1vDx7XrFztsO9IV
JSZ0thUFRVyGzMD9+3s/d/8FvZ0qgx4eBFi4CCZB3qQnJif5rRon7br8CfK3
mJCDvWCwz0+K3PU2iDNDcv4i/F/FUafwbGJbh28rd7X4sgcS03hOLTwu3JCJ
1JoW9/fvfhpvlaNcXvT9l28BcbI6rjkXEuPjxVVjX+VFx8K3UFmXDF1PKRdi
JKx09SumxjXU2sEZUesVIrY9isHZqxJszRO2O1YFLD7PVILd54qcNGktp0Mq
lAZulCJ4P06SbGVruZWysmhGpxybQj1uA4ruo025mdU7zK7Sys+oBNswWy6b
FzOLpMEGEAwkdGyrMMu8qVhejFARZ7lIe0MqAC2sSoLZbCUUKVT6/4zCw/5V
fwuBnzyRl3ydUJZtBVg5DeWy0nTqtLgswmJYssnjudbocljiO53p/Q/Dv4ut
NVuwnjnluZtKV2LjqjavDo+PHx4QNv8hz7QfLHEk+kRKaxPp6s8f8kbPgBB0
bVH+If7o5D/lp+ZP7Q2myO7hoVsLBguHR0abI2Xn8ODwiHY5P+XrqTSM+VQ0
YL6KP7ZqKnbzp1zLlIz5FmZ8AxO2Dv/8pSwPX0OrHYe+yYuPZ7Xi4xUFsP28
1MgtM4QusTX4RgWw3QiUA3d/jpvYkV5bjlwPkWQnPrcFPlfxLOqblLl/tRwe
0dOW+HeYv/vn39DLLwiKxeBW/gopbImv4A7dSUkdfx5RyN07iPoOFV2lDKuA
gOJaGSD9Ev5nzsmSrF7A3cO2++KKr30buXc5PMlx58YuaQFpv7IF39h2vobU
JH/xNG8AWYkERrQCE3txMvem8dTjiDXSqZdfVfIK9DTe6mNw55F2yr1mXXi/
tWMvZl+6SDS5hzBbRsbVHaHFcLfIwj7l9+DqymeLT19SpG/RmW0QKxRvq+be
1ITzjMWT1w/ZJujmIaeM5V2HpSKP5sMR8m0nZzojd7fD3lx0tzqmchXDx23I
FW21MF93D19ymMA3Z+niFfkfe3ndSt2V+av32W2g7a723pLfIO+J1ABEWnWH
v/jF3Xj/1ePyPnaPvK4oevcFrCJoojrXPSQV7yHlLUqf0071Wv7e833g0nTv
5b7M1Qaj3dVqqz17R/ul+zX0jXRo79W+cx17B3b8I45kD65mXz4IcTY4H14N
6eLDSA4v318MT4djOe6/GVE7RJwM3gyvYLGX769vxiMqIg7fXPXHH24Gnf7F
m+ub4fjtJZ6e31xfVi4ClPbVod/NkBLchhAKJjFh/wsefDsXqnzYJvLgcO/o
NXFDyv54fDM8+TAe5KciFOqcUikvGm9W2tgT/f85EL225PExMPBB/icpeJli
FWpYDRW+8rKFO5PgDb/hWNUD0eTdZwIFNA+eH5poKkCxQ80sPbRWhcbGKejt
+/5N/3Ik+zcDuvoPksUDn/arun//t8clEvaA6IBI0KTSkpxC7cpTjn9+P6g0
POGphv8zkJD/fo0HZ/Lk5+0eKpYfXJ3ZViIQzqertSHdPudqobjv2V900tPv
WvzbL60HQj4VfWQQvr+/P4kn8gQJwgN1LfH9KkC28lYlK53wI3sn434UrxYB
oNhfLAM9f7A3BSSlkfZXAKghoJJwI5BOJUVPtBZ3ccej3Lgf6jv5Rm2iOMmX
szmNbUKFQcRZk48FBb10aWNjlZvMGCRqSGX1Jl9GFXeqIblVlnriX1Z0FnOC
NgAA

-->

</rfc>