<?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.21 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-05" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->
  <front>
    <title abbrev="PQ/T Hybrid Terminology">Terminology for Post-Quantum Traditional Hybrid Schemes</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-05"/>
    <author fullname="Florence Driscoll">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>florence.d@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Michael Parsons">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>michael.p1@ncsc.gov.uk</email>
      </address>
    </author>
    <author fullname="Britta Hale">
      <organization>Naval Postgraduate School</organization>
      <address>
        <email>britta.hale@nps.edu</email>
      </address>
    </author>
    <date year="2024" month="December" day="11"/>
    <area>SEC</area>
    <workgroup>PQUIP</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 120?>

<t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms.  This document defines terminology for such schemes.  It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/"/>.
      </t>
      <t>
      </t>
    </note>
  </front>
  <middle>
    <?line 125?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The mathematical problems of integer factorisation and discrete logarithms over finite fields or elliptic curves underpin most of the asymmetric algorithms used for key establishment and digital signatures on the internet.  These problems, and hence the algorithms based on them, will be vulnerable to attacks using Shor's Algorithm on a sufficiently large general-purpose quantum computer, known as a Cryptographically Relevant Quantum Computer (CRQC).  Current predictions vary on when, or if, such a device will exist.  However, it is necessary to anticipate and prepare to defend against such a development.  Data encrypted today (2024) with an algorithm vulnerable to a quantum computer can be stored for decryption by a future attacker with a CRQC.  Signing algorithms in products that are expected to be in use for many years, and that cannot be updated or replaced, are also at risk if a CRQC is developed during the operational lifetime of that product.</t>
      <t>Ongoing responses to the potential development of a CRQC include modifying established (standardised) protocols to use asymmetric algorithms that are designed to be secure against quantum computers as well as today's classical computers.  These algorithms are called post-quantum, while algorithms based on integer factorisation, finite-field discrete logarithms or elliptic-curve discrete logarithms are called traditional cryptographic algorithms. In this document "traditional algorithm" is also used to refer to this class of algorithms.</t>
      <t>At the time of publication, the term post-quantum is generally used to describe cryptographic algorithms that are designed to be secure against an adversary with access to a CRQC. Post-quantum algorithms can also be referred to as quantum-resistant or quantum-safe algorithms. There are merits to the different terms, for example some prefer to use the terms quantum-resistant or quantum-safe to explictly indicate that these algorithms are designed to be secure against quantum computers but others disagree, and prefer to use post-quantum, in case of compromises against such algorithms which could make the terms quantum-resistant or quantum-safe misleading. Similarly, some prefer to refer specifically to Shor's Algorithm or to the mathematical problem that is being used to prevent attack. Post-quantum cryptography is commonly used amongst the cryptography community, so will be used throughout this document. Similarly, the term "traditional algorithm" will be used throughout the document as, at the time of publication, it is widely used in the community, though other terms, including classical, pre-quantum or quantum-vulnerable, are preferred by some.</t>
      <t>There may be a requirement for protocols that use both algorithm types, for example during the transition from traditional to post-quantum algorithms or as a general solution, to mitigate risks. When the risk of deploying new algorithms is above the accepted threshold for their use case, a designer may combine a post-quantum algorithm with a traditional algorithm with the goal of adding protection against an attacker with a CRQC to the security properties provided by the traditional algorithm.  They may also implement a post-quantum algorithm alongside a traditional algorithm for ease of migration from an ecosystem where only traditional algorithms are implemented and used, to one that only uses post-quantum algorithms. Examples of solutions that could use both types of algorithm include, but are not limited to, <xref target="RFC9370"/>, <xref target="I-D.ietf-tls-hybrid-design"/>, <xref target="I-D.ietf-lamps-pq-composite-kem"/>, and <xref target="I-D.ietf-lamps-cert-binding-for-multi-auth"/>.</t>
      <t>Schemes that combine post-quantum and traditional algorithms for key establishment or digital signatures are often called hybrids. For example:</t>
      <ul spacing="normal">
        <li>
          <t>The National Institute of Standards and Technology (NIST) defines hybrid key establishment to be a "scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes" <xref target="NIST_PQC_FAQ"/>;</t>
        </li>
        <li>
          <t>The European Telecommunications Standards Institute (ETSI) defines hybrid key exchanges to be "constructions that combine a traditional key exchange ... with a post-quantum key exchange ... into a single key exchange" <xref target="ETSI_TS103774"/>.</t>
        </li>
      </ul>
      <t>The word "hybrid" is also used in cryptography to describe encryption schemes that combine asymmetric and symmetric algorithms <xref target="RFC9180"/>, so using it in the post-quantum context overloads it and risks misunderstandings.  However, this terminology is well-established amongst the post-quantum cryptography (PQC) community. Therefore, an attempt to move away from its use for PQC could lead to multiple definitions for the same concept, resulting in confusion and lack of clarity. 
At the time of publication, hybrid is generally used for schemes that combine post-quantum and traditional algorithms; it will be so used throughout this document, though some have alternative preferences such as double-algorithm or multi-algorithm.</t>
      <t>This document provides language for constructions that combine traditional and post-quantum algorithms. Specific solutions for enabling use of multiple asymmetric algorithms in cryptographic schemes may be more general than this, allowing the use of solely traditional or solely post-quantum algorithms.  However, where relevant, we focus on post-quantum traditional combinations as these are the motivation for the wider work in the IETF.  This document is intended as a reference terminology guide for other documents to add clarity and consistency across different protocols, standards, and organisations.  Additionally, this document aims to reduce misunderstanding about use of the word "hybrid" as well as defining a shared language for different types of post-quantum and traditional hybrid constructions.</t>
      <t>In this document, a "cryptographic algorithm" is defined, as in <xref target="NIST_SP_800-152"/>, to be a "well-defined computational procedure that takes variable inputs, often including a cryptographic key, and produces an output".  Examples include RSA, ECDH, ML-KEM (formerly known as Kyber) and ML-DSA (formerly known as Dilithium).   The expression "cryptographic scheme" is used to refer to a construction that uses a cryptographic algorithm or a group of cryptographic algorithms to achieve a particular cryptographic outcome, e.g., key agreement.  A cryptographic scheme may be made up of a number of functions. For example, a Key Encapsulation Mechanism (KEM) is a cryptographic scheme consisting of three functions: Key Generation, Encapsulation, and Decapsulation.  A cryptographic protocol incorporates one or more cryptographic schemes.  For example, TLS <xref target="RFC8446"/> is a cryptographic protocol that includes schemes for key agreement, record layer encryption, and server authentication.</t>
    </section>
    <section anchor="primitives">
      <name>Primitives</name>
      <t>This section introduces terminology related to cryptographic algorithms and to hybrid constructions for cryptographic schemes.</t>
      <dl>
        <dt><strong>Traditional Asymmetric Cryptographic Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms,  elliptic curve discrete logarithms, or related mathematical problems.
</t>
          <t>A related mathematical problem is one that can be solved by solving the integer factorisation, finite field discrete logarithm or elliptic curve discrete logarithm problem.</t>
          <t>Where there is little risk of confusion, traditional asymmetric cryptographic algorithms can also be referred to as traditional algorithms for brevity.  Traditional algorithms can also be called classical or conventional algorithms.</t>
        </dd>
        <dt><strong>Post-Quantum Asymmetric Algorithm</strong>:</dt>
        <dd>
          <t>An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers.
</t>
          <t>Where there is little risk of confusion, post-quantum asymmetric algorithms can also be referred to as post-quantum algorithms for brevity. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms.</t>
          <t>As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore it should not be assumed that just because an algorithm is designed to provide post-quantum security it will not be compromised. Should an attack be found against a post-quantum algorithm, it is commonly still referred to as a post-quantum algorithm as they were designed to protect against an adversary with access to a CRQC and the labels are referring to the designed or desired properties.</t>
        </dd>
      </dl>
      <t>There may be asymmetric cryptographic constructions that are neither post-quantum nor asymmetric traditional algorithms according to the definitions above. These are out of scope of this document.</t>
      <dl>
        <dt><strong>Component Asymmetric Algorithm</strong>:</dt>
        <dd>
          <t>Each cryptographic algorithm that forms part of a cryptographic scheme.
</t>
          <t>An asymmetric component algorithm operates on the input of the cryptographic operation and produces a cryptographic output that can be used by itself or jointly to complete the operation. Where there is little risk of confusion, component aysmmetric algorithms can also be referred to as component algorithms for brevity, as is done in the following definitions.</t>
        </dd>
        <dt><strong>Single-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme with one component algorithm.
</t>
          <t>A single-algorithm scheme could use either a traditional algorithm or a post-quantum algorithm.</t>
        </dd>
        <dt><strong>Multi-Algorithm Scheme</strong>:</dt>
        <dd>
          <t>A cryptographic scheme that incorporates more than one component algorithm, where the component algorithms have the same cryptographic purpose as each other and as the multi-algorithm scheme.
</t>
          <t>For example, a multi-algorithm signature scheme may include multiple signature algorithms or a multi-algorithm Public Key Encryption (PKE) scheme may include multiple PKE algorithms. Component algorithms could be all traditional, all post-quantum, or a mixture of the two.</t>
        </dd>
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>Components of a PQ/T hybrid scheme operate on the same input message and their output is used together to complete the cryptographic operation either serially or in parallel. PQ/T hybrid scheme design is aimed at requiring successful breaking of all component algorithms to break the PQ/T hybrid scheme's security properties.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Key Encapsulation Mechanism (KEM)</strong>:</dt>
        <dd>
          <t>A multi-algorithm KEM made up of two or more component algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.  The component algorithms could be KEMs, or other key establishment algorithms.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Public Key Encryption (PKE)</strong>:</dt>
        <dd>
          <t>A multi-algorithm PKE scheme made up of two or more component algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.  The component algorithms could be PKE algorithms, or other key establishment algorithms.
</t>
          <t>The standard security property for a PKE scheme is indistinguishability under chosen-plaintext attack, (IND-CPA). IND-CPA security is not sufficient for secure communication in the presence of an active attacker.  Therefore, in general, PKE schemes are not appropriate for use on the internet, and KEMs, which provide indistiguishability under chosen-ciphertext attacks (IND-CCA security), are required.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Digital Signature</strong>:</dt>
        <dd>
          <t>A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>Note that there are many possible ways of constructing a PQ/T hybrid digital signatures. Examples include parallel signatures, composite signatures or nested signatures.</t>
        </dd>
      </dl>
      <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t>
      <dl>
        <dt><strong>Post-Quantum Traditional (PQ/T) Hybrid Composite Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm and the resulting composite scheme is exposed as a singular interface of the same type as the component algorithms.
</t>
          <t>A PQ/T Hybrid Composite can be referred to as a PQ/T Composite. Examples of PQ/T Hybrid Composites include a single KEM algorithm comprised of a PQ KEM component and a traditional KEM component, for which the result presents as a KEM output.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component algorithms and combines them to form a PQ/T hybrid scheme.</t>
        </dd>
        <dt><strong>PQ/PQ Hybrid Scheme</strong>:</dt>
        <dd>
          <t>A multi-algorithm scheme where all components are post-quantum algorithms.
</t>
          <t>The definitions for types of PQ/T hybrid schemes can be adapted to define types of PQ/PQ hybrid schemes, which are multi-algorithm schemes where all component algorithms are Post-Quantum algorithms. These are designed to mitigate risks when the two post-quantum algorithms are based on different mathematical problems. Some prefer to refer to these as PQ/PQ multi-algorithm schemes, and reserve the term hybrid for PQ/T hybrids.</t>
        </dd>
      </dl>
      <t>In cases where there is little chance of confusion between other types of hybrid cryptography e.g., as defined in <xref target="RFC4949"/>, and where the component algorithms of a multi-algorithm scheme could be either post-quantum or traditional, it may be appropriate to use the phrase "hybrid scheme" without PQ/T or PQ/PQ preceding it.</t>
      <dl>
        <dt><strong>Component Scheme</strong>:</dt>
        <dd>
          <t>Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.</t>
        </dd>
      </dl>
    </section>
    <section anchor="cryptographic-elements">
      <name>Cryptographic Elements</name>
      <t>This section introduces terminology related to cryptographic elements and their inclusion in hybrid schemes.</t>
      <dl>
        <dt><strong>Cryptographic Element</strong>:</dt>
        <dd>
          <t>Any data type (private or public) that contains an input or output value for a cryptographic algorithm or for a function making up a cryptographic algorithm.
</t>
          <t>Types of cryptographic elements include public keys, private keys, plaintexts, ciphertexts, shared secrets, and signature values.</t>
        </dd>
        <dt><strong>Component Cryptographic Element</strong>:</dt>
        <dd>
          <t>A cryptographic element of a component algorithm in a multi-algorithm scheme.
</t>
          <t>For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client's keyshare contains two component public keys, one for a post-quantum algorithm and one for a traditional algorithm.</t>
        </dd>
        <dt><strong>Composite Cryptographic Element</strong>:</dt>
        <dd>
          <t>A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi-algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements.
</t>
          <t>For example, a composite cryptographic public key is made up of two component public keys.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Composite Cryptographic Element</strong>:</dt>
        <dd>
          <t>A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi-algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements, where at least one component cryptographic element is post-quantum and at least one is traditional.</t>
        </dd>
        <dt><strong>Cryptographic Element Combiner</strong>:</dt>
        <dd>
          <t>A method that takes two or more component cryptographic elements of the same type and combines them to form a composite cryptographic element.
</t>
          <t>A cryptographic element combiner could be concatenation, such as where two component public keys are concatenated to form a composite public key as in <xref target="I-D.ietf-tls-hybrid-design"/>, or something more involved such as the dualPRF defined in <xref target="BINDEL"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="protocols">
      <name>Protocols</name>
      <t>This section introduces terminology related to the use of post-quantum and traditional algorithms together in protocols.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Protocol</strong>:</dt>
        <dd>
          <t>A protocol that uses two or more component algorithms providing the same cryptographic functionality, where at least one is a post-quantum algorithm and at least one is a traditional algorithm.
</t>
          <t>For example, a PQ/T hybrid protocol providing confidentiality could use a PQ/T hybrid KEM such as in <xref target="I-D.ietf-tls-hybrid-design"/>, or it could combine the output of a post-quantum KEM and a traditional KEM at the protocol level to generate a single shared secret, such as in <xref target="RFC9370"/>.  Similarly, a PQ/T hybrid protocol providing authentication could use a PQ/T hybrid digital signature scheme, or it could include both post-quantum and traditional single-algorithm digital signature schemes.</t>
          <t>A protocol that can negotiate the use of either a traditional algorithm or a post-quantum algorithm, but not of both types of algorithm, is not a PQ/T hybrid protocol. 
Protocols that use two or more component algorithms but with different cryptographic functionality, for example a post-quantum KEM and a pre-shared key (PSK) are also not PQ/T hybrid protocols.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Key Establishment</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite scheme to achieve key establishment, in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with composite key establishment could include a single PQ/T hybrid KEM, such as in <xref target="I-D.ietf-tls-hybrid-design"/>.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Data Authentication</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite scheme to achieve data authentication, in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with composite data authentication could include data authentication through use of a PQ/T composite hybrid digital signature, exposed as a single interface for PQ signature and traditional signature components. </t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Composite Entity Authentication</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates a PQ/T hybrid composite scheme to achieve entity authentication, in such a way that the protocol fields and message flow are the same as those in a version of the protocol that uses a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with composite entity authentication could include entity authentication through use of PQ/T Composite Hybrid certificates.</t>
        </dd>
      </dl>
      <t>In a PQ/T hybrid protocol with a composite construction, changes are primarily made to the formats of the cryptographic elements, while the protocol fields and message flow remain largely unchanged.  In implementations, most changes are likely to be made to the cryptographic libraries, with minimal changes to the protocol libraries.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Protocol with Non-Composite Key Establishment</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve key establishment, where at least one uses a post-quantum algorithm and at least one uses a traditional algorithm, in such a way that the formats of the component cryptographic elements are the same as when they are used a part of a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with non-composite key establishment could include a traditional key exchange scheme and a post-quantum KEM. A construction like this for IKEv2 is enabled by <xref target="RFC9370"/>.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Protocol with Non-Composite Authentication</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that incorporates multiple single-algorithm schemes to achieve authentication, where at least one uses a post-quantum algorithm and at least one uses a traditional algorithm, in such a way that the formats of the component cryptographic elements are the same as when they are used a part of a single-algorithm scheme.
</t>
          <t>For example, a PQ/T hybrid protocol with non-composite authentication could use a PQ/T parallel PKI with one traditional certificate chain and one post-quantum certificate chain.</t>
        </dd>
      </dl>
      <t>In a PQ/T hybrid protocol with a non-composite construction, changes are primarily made to the protocol fields, the message flow, or both, while changes to cryptographic elements are minimised.  In implementations, most changes are likely to be made to the protocol libraries, with minimal changes to the cryptographic libraries.</t>
      <t>It is possible for a PQ/T hybrid protocol to be designed with both composite and non-composite constructions.  For example, a protocol that offers both confidentiality and authentication could have composite key agreement and non-composite authentication.  Similarly, it is possible for a PQ/T hybrid protocol to achieve certain cryptographic outcomes in a non-hybrid manner.  For example <xref target="I-D.ietf-tls-hybrid-design"/> describes a PQ/T hybrid protocol with composite key agreement, but with single-algorithm authentication.</t>
      <t>PQ/T hybrid protocols may not specify non-composite aspects, but can choose to do so for clarity, in particular if including both composite and non-composite aspects.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Composite Protocol</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that only uses composite constructions can be referred to as a PQ/T Hybrid Composite Protocol.
</t>
          <t>For example, a protocol that only provides entity authentication, and achieves this using PQ/T hybrid composite entity authentication. Similarly, a protocol that offers both key establishment and data authentication, and achieves this using both PQ/T hybrid composite key establishment and PQ/T hybrid composite data authentication.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Non-Composite Protocol</strong>:</dt>
        <dd>
          <t>A PQ/T hybrid protocol that does not use only composite constructions can be referred to as a PQ/T Hybrid Non-Composite Protocol.
</t>
          <t>For example, a PQ/T hybrid protocol that offers both confidentiality and authentication and uses composite key agreement and non-composite authentication would be referred to as a PQ/T hybrid non-composite protocol.</t>
        </dd>
      </dl>
    </section>
    <section anchor="properties">
      <name>Properties</name>
      <t>This section describes some properties that may be desired from or achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol.  Properties of PQ/T hybrid schemes are still an active area of research and development, e.g., <xref target="BINDELHALE"/>. This section does not attempt to be comprehensive, but rather covers a basic set of properties.</t>
      <t>It is not possible for one PQ/T hybrid scheme or PQ/T hybrid protocol to achieve all of the properties in this section. To understand what properties are required a designer or implementer will think about why they are using a PQ/T hybrid scheme. For example, a scheme that is designed for implementation security will likely require PQ/T hybrid confidentiality or PQ/T hybrid authentication, while a scheme for interoperability will require PQ/T hybrid interoperability.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Confidentiality</strong>:</dt>
        <dd>
          <t>The property that confidentiality is achieved by a PQ/T hybrid scheme or PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Authentication</strong>:</dt>
        <dd>
          <t>The property that authentication is achieved by a PQ/T hybrid scheme or a PQ/T hybrid protocol as long as at least one component algorithm that aims to provide this property remains secure.</t>
        </dd>
      </dl>
      <t>The security properties of a PQ/T hybrid scheme or protocol depend on the security of its component algorithms, the choice of PQ/T hybrid combiner, and the capability of an attacker. Changes to the security of a component algorithm can impact the security properties of a PQ/T hybrid scheme providing hybrid confidentiality or hybrid authentication.  For example, if the post-quantum component algorithm of a PQ/T hybrid scheme is broken, the scheme will remain secure against an attacker with a classical computer, but will be vulnerable to an attacker with a CRQC.</t>
      <t>PQ/T hybrid protocols that offer both confidentiality and authentication do not necessarily offer both hybrid confidentiality and hybrid authentication.  For example, <xref target="I-D.ietf-tls-hybrid-design"/> provides hybrid confidentiality but does not address hybrid authentication.  Therefore, if the design in <xref target="I-D.ietf-tls-hybrid-design"/> is used with single-algorithm X.509 certificates as defined in <xref target="RFC5280"/> only authentication with a single algorithm is achieved.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Interoperability</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties share support for at least one component algorithm.
</t>
          <t>For example, a PQ/T hybrid digital signature might achieve hybrid interoperability if the signature can be verified by either verifying the traditional or the post-quantum component, such as the approach defined in section 7.2.2 of <xref target="ITU-T-X509-2019"/>.  In this example a verifier that has migrated to support post-quantum algorithms is required to verify only the post-quantum signature, while a verifier that has not migrated will verify only the traditional signature.</t>
        </dd>
      </dl>
      <t>In the case of a protocol that aims to achieve both authentication and confidentiality, PQ/T hybrid interoperability requires that at least one component authentication algorithm and at least one component algorithm for confidentiality is supported by both parties.</t>
      <t>It is not possible for a PQ/T hybrid scheme to achieve both PQ/T hybrid interoperability and PQ/T hybrid confidentiality without additional functionality at a protocol level.  For PQ/T hybrid interoperability a scheme needs to work whenever one component algorithm is supported by both parties, while to achieve PQ/T hybrid confidentiality all component algorithms need to be used.  However, both properties can be achieved in a PQ/T hybrid protocol by building in downgrade protection external to the cryptographic schemes.  For example, in <xref target="I-D.ietf-tls-hybrid-design"/>, the client uses the TLS supported groups extension to advertise support for a PQ/T hybrid scheme and the server can select this group if it supports the scheme.  This is protected using TLS's existing downgrade protection, so achieves PQ/T hybrid confidentiality, but the connection can still be made if either the client or server does not support the PQ/T hybrid scheme, so PQ/T hybrid interoperability is achieved.</t>
      <t>The same is true for PQ/T hybrid interoperability and PQ/T hybrid authentication.  It is not possible to achieve both with a PQ/T hybrid scheme alone, but it is possible with a PQ/T hybrid protocol that has appropriate downgrade protection.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Backwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully provided that both parties support the traditional component algorithm, while also using both algorithms if both are supported by both parties.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Forwards Compatibility</strong>:</dt>
        <dd>
          <t>The property that a PQ/T hybrid scheme or PQ/T hybrid protocol can be completed successfully using a post-quantum component algorithm provided that both parties support it, while also having the option to use both post-quantum and traditional algorithms if both are supported by both parties.
</t>
          <t>Note that PQ/T hybrid forwards compatability is a protocol or scheme property only.</t>
        </dd>
      </dl>
    </section>
    <section anchor="certificates">
      <name>Certificates</name>
      <t>This section introduces terminology related to the use of certificates in hybrid schemes.</t>
      <dl>
        <dt><strong>PQ/T Hybrid Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains public keys for two or more component algorithms where at least one is a traditional algorithm and at least one is a post-quantum algorithm.
</t>
          <t>A PQ/T hybrid certificate could be used to facilitate a PQ/T hybrid authentication protocol.  However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual component algorithms.</t>
          <t>The component public keys in a PQ/T hybrid certificate could be included as a composite public key or as individual component public keys.</t>
          <t>The use of a PQ/T hybrid certificate does not necessarily achieve hybrid authentication of the identity of the sender; this is determined by properties of the chain of trust. For example, an end-entity certificate that contains a composite public key, but which is signed using a single-algorithm digital signature scheme could be used to provide hybrid authentication of the source of a message, but would not achieve hybrid authentication of the identity of the sender.</t>
        </dd>
        <dt><strong>Post-Quantum Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains a single public key for a post-quantum digital signature algorithm.</t>
        </dd>
        <dt><strong>Traditional Certificate</strong>:</dt>
        <dd>
          <t>A digital certificate that contains a single public key for a traditional digital signature algorithm.</t>
        </dd>
      </dl>
      <t>X.509 certificates as defined in <xref target="RFC5280"/> could be either traditional or post-quantum certificates depending on the algorithm in the Subject Public Key Info.  For example, a certificate containing a ML-DSA public key, as will be defined in <xref target="I-D.ietf-lamps-dilithium-certificates"/>, would be a post-quantum certificate.</t>
      <dl>
        <dt><strong>Post-Quantum Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificates include a public key for a post-quantum algorithm and are signed using a post-quantum digital signature scheme.</t>
        </dd>
        <dt><strong>Traditional Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificates include a public key for a traditional algorithm and are signed using a traditional digital signature scheme.</t>
        </dd>
        <dt><strong>PQ/T Hybrid Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain where all certificates are PQ/T hybrid certificates and each certificate is signed with two or more component algorithms with at least one being a traditional algorithm and at least one being a post-quantum algorithm.</t>
        </dd>
      </dl>
      <t>A PQ/T hybrid certificate chain is one way of achieving hybrid authentication of the identity of a sender in a protocol, but is not the only way. An alternative is to use a PQ/T parallel PKI as defined below.</t>
      <dl>
        <dt><strong>PQ/T Mixed Certificate Chain</strong>:</dt>
        <dd>
          <t>A certificate chain containing at least two of the three certificate types defined in this draft (PQ/T hybrid certificates, post-quantum certificates and traditional certificates)
</t>
          <t>For example, a traditional end-entity certificate could be signed by a post-quantum intermediate certificate, which in turn could be signed by a post-quantum root certificate. This may be desirable due to the lifetimes of the certificates, the relative difficulty of rotating keys, or for efficiency reasons. The security properties of a certificate chain that mixes post-quantum and traditional algorithms would need to be analysed on a case-by-case basis.</t>
        </dd>
        <dt><strong>PQ/T Parallel PKI</strong>:</dt>
        <dd>
          <t>Two certificate chains, one a post-quantum certificate chain and one a traditional certificate chain, that are used together in a protocol.
</t>
          <t>A PQ/T parallel PKI might be used achieve hybrid authentication or hybrid interoperability depending on the protocol implementation.</t>
        </dd>
        <dt><strong>Multi-Certificate Authentication</strong>:</dt>
        <dd>
          <t>Authentication that uses two or more end-entity certificates.
</t>
          <t>For example, multi-certificate authentication may be achieved using a PQ/T parallel PKI.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document defines security-relevant terminology to be used in documents specifying PQ/T hybrid protocols and schemes.  However, the document itself does not have a security impact on Internet protocols.  The security considerations for each PQ/T hybrid protocol are specific to that protocol and should be discussed in the relevant specification documents. More general guidance about the security considerations, timelines, and benefits and drawbacks of use of PQ/T hybrids is also out of scope of this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="BINDEL" target="https://doi.org/10.1007/978-3-030-25510-7_12">
        <front>
          <title>Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="J." surname="Brendel" fullname="Jacqueline Brendel">
            <organization/>
          </author>
          <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
            <organization/>
          </author>
          <author initials="B." surname="Goncalves" fullname="Brian Goncalves">
            <organization/>
          </author>
          <author initials="D." surname="Stebila" fullname="Douglas Stebila">
            <organization/>
          </author>
          <date year="2019" month="July"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-3-030-25510-7_12"/>
        <refcontent>Post-Quantum Cryptography pp.206-226</refcontent>
      </reference>
      <reference anchor="BINDELHALE" target="https://eprint.iacr.org/2023/423.pdf">
        <front>
          <title>A Note on Hybrid Signature Schemes</title>
          <author initials="N." surname="Bindel" fullname="Nina Bindel">
            <organization/>
          </author>
          <author initials="B." surname="Hale" fullname="Britta Hale">
            <organization/>
          </author>
          <date year="2023" month="July" day="23"/>
        </front>
        <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
      </reference>
      <reference anchor="ETSI_TS103774" target="https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf">
        <front>
          <title>CYBER; Quantum-safe Hybrid Key Exchanges</title>
          <author>
            <organization>ETSI TS 103 744 V1.1.1</organization>
          </author>
          <date year="2020" month="December"/>
        </front>
      </reference>
      <reference anchor="ITU-T-X509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
        <front>
          <title>ITU-T X.509 The Directory - Public-key and attribute certificate frameworks</title>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date year="2019" month="January"/>
        </front>
      </reference>
      <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
        <front>
          <title>Post-Quantum Cryptography FAQs</title>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2022" month="July" day="05"/>
        </front>
      </reference>
      <reference anchor="NIST_SP_800-152" target="https://doi.org/10.6028/NIST.SP.800-152">
        <front>
          <title>NIST SP 800-152 A Profile for U. S. Federal Cryptographic Key Management Systems</title>
          <author initials="E. B." surname="Barker" fullname="Elaine B. Barker">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="M." surname="Smid" fullname="Miles Smid">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author initials="D." surname="Branstad" fullname="Dannis Branstad">
            <organization>Information Technology Laboratory</organization>
          </author>
          <author>
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date year="2015" month="October"/>
        </front>
      </reference>
      <reference anchor="I-D.ietf-lamps-dilithium-certificates">
        <front>
          <title>Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA</title>
          <author fullname="Jake Massimo" initials="J." surname="Massimo">
            <organization>AWS</organization>
          </author>
          <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
            <organization>AWS</organization>
          </author>
          <author fullname="Sean Turner" initials="S." surname="Turner">
            <organization>sn3rd</organization>
          </author>
          <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
            <organization>Cloudflare</organization>
          </author>
          <date day="4" month="November" year="2024"/>
          <abstract>
            <t>   Digital signatures are used within X.509 certificates, Certificate
   Revocation Lists (CRLs), and to sign messages.  This document
   describes the conventions for using FIPS 204, the Module-Lattice-
   Based Digital Signature Algorithm (ML-DSA) in Internet X.509
   certificates and certificate revocation lists.  The conventions for
   the associated signatures, subject public keys, and private key are
   also described.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-dilithium-certificates-05"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-cert-binding-for-multi-auth">
        <front>
          <title>Related Certificates for Use in Multiple Authentications within a Protocol</title>
          <author fullname="Alison Becker" initials="A." surname="Becker">
            <organization>National Security Agency</organization>
          </author>
          <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
            <organization>National Security Agency</organization>
          </author>
          <author fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins">
            <organization>National Security Agency</organization>
          </author>
          <date day="10" month="December" year="2024"/>
          <abstract>
            <t>   This document defines a new CSR attribute, relatedCertRequest, and a
   new X.509 certificate extension, RelatedCertificate.  The use of the
   relatedCertRequest attribute in a CSR and the inclusion of the
   RelatedCertificate extension in the resulting certificate together
   provide additional assurance that two certificates each belong to the
   same end entity.  This mechanism is particularly useful in the
   context of non-composite hybrid authentication, which enables users
   to employ the same certificates in hybrid authentication as in
   authentication done with only traditional or post-quantum algorithms.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cert-binding-for-multi-auth-06"/>
      </reference>
      <reference anchor="I-D.ietf-tls-hybrid-design">
        <front>
          <title>Hybrid key exchange in TLS 1.3</title>
          <author fullname="Douglas Stebila" initials="D." surname="Stebila">
            <organization>University of Waterloo</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Shay Gueron" initials="S." surname="Gueron">
            <organization>University of Haifa</organization>
          </author>
          <date day="7" month="October" year="2024"/>
          <abstract>
            <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-11"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-pq-composite-kem">
        <front>
          <title>Composite ML-KEM for use in X.509 Public Key Infrastructure and CMS</title>
          <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="John Gray" initials="J." surname="Gray">
            <organization>Entrust Limited</organization>
          </author>
          <author fullname="Massimiliano Pala" initials="M." surname="Pala">
            <organization>OpenCA Labs</organization>
          </author>
          <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
            <organization>Bundesdruckerei GmbH</organization>
          </author>
          <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
            <organization>Cisco Systems</organization>
          </author>
          <date day="21" month="October" year="2024"/>
          <abstract>
            <t>   This document defines combinations of ML-KEM [FIPS.203] in hybrid
   with traditional algorithms RSA-OAEP, ECDH, X25519, and X448.  These
   combinations are tailored to meet security best practices and
   regulatory requirements.  Composite ML-KEM is applicable in any
   application that uses X.509, PKIX, and CMS data structures and
   protocols that accept ML-KEM, but where the operator wants extra
   protection against breaks or catastrophic bugs in ML-KEM.  For use
   within CMS, this document is intended to be coupled with the CMS
   KEMRecipientInfo mechanism in [RFC9629].

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-05"/>
      </reference>
      <reference anchor="RFC4949">
        <front>
          <title>Internet Security Glossary, Version 2</title>
          <author fullname="R. Shirey" initials="R." surname="Shirey"/>
          <date month="August" year="2007"/>
          <abstract>
            <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="FYI" value="36"/>
        <seriesInfo name="RFC" value="4949"/>
        <seriesInfo name="DOI" value="10.17487/RFC4949"/>
      </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="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="RFC9180">
        <front>
          <title>Hybrid Public Key Encryption</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/>
          <author fullname="B. Lipp" initials="B." surname="Lipp"/>
          <author fullname="C. Wood" initials="C." surname="Wood"/>
          <date month="February" year="2022"/>
          <abstract>
            <t>This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.</t>
            <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9180"/>
        <seriesInfo name="DOI" value="10.17487/RFC9180"/>
      </reference>
      <reference anchor="RFC9370">
        <front>
          <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
          <author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>
          <author fullname="M. Tomlinson" initials="M." surname="Tomlinson"/>
          <author fullname="G. Bartlett" initials="G." surname="Bartlett"/>
          <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
          <author fullname="D. Van Geest" initials="D." surname="Van Geest"/>
          <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
          <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
          <date month="May" year="2023"/>
          <abstract>
            <t>This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.</t>
            <t>This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.</t>
            <t>This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9370"/>
        <seriesInfo name="DOI" value="10.17487/RFC9370"/>
      </reference>
    </references>
    <?line 386?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is the product of numerous fruitful discussions in the IETF PQUIP group.  Thank you in particular to Mike Ounsworth, John Gray, Tim Hollebeek, Wang Guilin, Rebecca Guthrie, Stephen Farrell, Paul Hoffman and Sofía Celi for their contributions.  This document is inspired by many others from the IETF and elsewhere.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1d63LcNpb+7yq/A0v7Y+xUd0tWnDhWaqtGkeRE49ijWMpm
9pcLTaK7MWKTbYKU3Dvld9kX2JfYfbE9FwAESJAtyZ6Z3amJk1jqBnE5OJfv
XABOp9PHj2pV5/Io2buS1VoVZV4ut8mirJKLUtfTXxpR1M06uapEpmpVFiJP
ftrOK5Ull+lKrqXee/xIzOeVvIEuLn7Zv7Jfe91Bk1TUcllW26NEFYvy8aPH
j7IyLcQaBs4qsainStaL6eZDozbw/3q6ok6mddvJ9OCbx490M18rrWEe9XYD
z56fXb16/Kho1nNZHUGfMAr8lZaFloVu9FFSV418/Ajm9jVMs5LiKLk8O3n8
6LasrpdV2WyOkotffj2/ePzoWm7hwwy6LGDQQtbTU5wXPCuLBjtNkvCBJOEp
/AZdqWKZ/Ijf4sdrofKjZFXXG320v4+/iSpdqRs5wzXOymq5jx/sz6vyVsv9
zYd0Hx/Dz+79GP4RTb0qcfXJFPtJkkWT50zaV3lZySKVyWmldFrmOTeAvkSh
/kPgfh4lv75O3gqztSdbIGRyKdOmUvU2OZFFXUl+SPK6FqbLWfb7ItXpbFne
zJrr2OBvVLoSMk8uRKVhQz5/6DV3ONs82zX0D9BFLZKfRC5jw74VNzAg8vcS
2LoBpkFmLss8GG5OncxW0Mnvi42eyaxBciP/Vmvo6Ya54ofzt6dnPx/xo7Wo
lrJutzErFe3cs4PZs4ODF/svX3w3/Xp68PXB9PCbb54dTF+8f3ZonmQpNMLz
Wm6TsyIVG93kNOnkjYTFF0qvdSKKLDmGTQcKKZQr0/wjNliaBbdMQf9M7Q8J
yB+IxdtZ8oMqMpm3nzPl3qpCdL7qPvsHeBZYIPLwH0T6oZG5KmS3RbePN7Pk
FXDkCtp2O3kDXN77svv8D7PkxxLok99I3e0ANl8U/a+7XZzOkstazkHMuh2c
ls0yFzr8upILUCs10Pwo1Iwn1XZTl8BIm9U22WxmhwffTg8Pv+WntKyU1Mgy
bitO/3h+lOzmB1JlyeHBs5fTgxfId5bTfjr++WyA2+SmUkU9UyKtiOsODw6/
3n9++PVsky0CLjtO3pbA9MBWVperZSHqppJWq0e4yBEwzkED/BM+BfvWCqW3
YaG0+rRm8pJRkhe4vOSY1eIEFMsGNIZdZEi2Q6Dqiyl+ip+fXV2ev7+6fHbw
9YsXzweId3t7O5O1ZnmF6cMQ1T5+8L7W+/jkwcF7/OvlS/rt+fP9g2cz+vf9
twf7tX7Pn94cPMM/mx7NT/79h7N33yeGbaZaLGQg7UZ8Y5QHKqIGO6J1JFeX
wD5fJzBW8m/PZvCns/KDKfPQ+dWv06vpn745eDlFNhpZtqqbGVB2v5Lp/tX0
3dnJ9E8z+xgw5XmwDuo2oQbJ1QpMi4LHajDtMMmLZp6rdAq2lJSUqOtKzRvg
tFRWtVqQtkoWFew6GuDRpdIwfVGgxb49v7x6f/HLyftXx78MLCvVVToDdVmj
ldi/qMo/wyT1/gYl94PZgtST3P2F+KCDdQ4LOYw6OnVn0s4LDZ3h+ssFaBMg
iagy1t9XoM4N1nqCy3na2cRDZF9EPLza5PIi+e4Advabw92W5tuDw+/28anZ
5cXMPBUsrdMjqAMg0ELlknDfr6AYQT3LTFZoltuVq5Q49Y0oxBJ0BIji5VbX
cj1AjK5aPcsFWQZQHKK6llX7PW+4tauglTzq/CzmZSWQvwY7fgMzB229VtkX
6/JUFMA8oJkEbKH4Ev1+Kc549s302QFrtfPpKWHDaS7WGz3NVK7qlULGbqVN
H0Va4vfTOShpwK1TWMp03eS1muIGhs3rXFsknoEZWxax3jYfpmm5BslStQTR
X1Obd69Onr98/tL+/M3hdwf25++eP//W/vzyWfv5S1CxRwxpp9NpIua6rkRa
J/zRH4F1hN6AFCPJAPwAtIfNIZ8kqcvEl+xE5OBrADEALKkiSQMW3lRlXQIW
hq809ZPJG5mXG2Jo6JrXm2i2g9BC1NBJWlYb3FyZzMt61RkNdq32/COht+u1
BNWXehOZJaAtYURwexoaKpMLEAcYoON26SZd2dHhofMa56nQGmaA9GClc5k0
Gn4EhCLQVEqG+DCLSbIqNxJh8HaCLdEHApOO7hBoQmjFajkFzwIhNsCEUsOM
1IL6qFvSTBJteXJCjzB+1sS+MCu7RyByGRrtx4/+Bf2mqsyaFJs8foSWASQE
ViEQpObY9zwHXYEkxtUswXQvBBoO0y2NkwHuqyRQGcghzA6WN9hUFQpth5I5
yAmQSea52kDXCfgLgPKSBshTbWC317A1lkWiO8HUQ1KjnZKwUjBaekWbwnNY
qhpmrC0m0giUsDtlXEPaS6mlWxQTaUX7QOO2g80FjsYdrCfJrcpz3MGbJi9A
v8LTuFFgKEV6jTNDT/IS1OjvdHJsO8GnBfDFAkRawSzzbZKj9k+WEvvIp5sG
mBOmYxkSxRF0SzVJrovytmBOCRS5ABZJ3slc3sATibNy5rnkycm7X06ewjJP
mspwhswUba1ObgTYepjSLax3gluhFhPmWoGypIAGtEr5Ec1vkvxU3oKEwWQU
sXIhU6k19oELRxdGbVCukIIwzAa8dPwGxEMihFiC0YANbfu3sgo9nwqAjUB0
XBnJRiZAaYL1fP4UpgBiCn6A24ouyXvUSlJoDlujgScNg2SS+kbunIO8gIdJ
GJm3C57gQRKkFkwHQTTuX6h9NiwVRpPg6uRHVGNOmKENcCSNtxbFNtlKcJiZ
o+gRmFZR1iT2m4zcPWgJhMpFKkHksUeRa2SiBGTpGrbDTAmpbQgGD2XgV8Pk
kD3h98paolwtZK3WkkVG1Ha+M1a6yxIfAhnYYExF45Sxh02J6FzB8x3taUcu
0rzJQAWUoF222IWTM5jKE6tdFMjGU08jQ+9IirjYOvqxKXL00xgykI5Tutuq
kf1vQV3g38QiIFugArUmveSaOaH2hsTRUFZgLF/jgxivEC3FxDyq2yZGf01J
f8W1XKvSpqTSoq28CfkWJ7RwvtE5R8Xjm529wFLZlnvIK8RFpByBsGRYeLuV
oRftb9s3MshxzabYMNCG8L9ZMn0Bxi00ltCZUVuggexgsKMpeApycCF33XwU
+AyUDekXls4U1Q1LPMvpxQBSSElbaOqWVl/xKMA21mMAOVDIuzVu1wffk/Np
DmyEU4L/1uD+105oWkOLZAERR5GXHwFEAS/pco32xFIdxcAS8C7jo7X/uAHi
o3VAZEeuFlGtjnH1fWUIvLgEgA/+CHwplpWUE6uyvSmHUoLYC+QCOQN7qsq1
Qh0S6vR2XiBU8EFaNiAia3F9PwJA17kUiGjBfVFrjJ4iCuqQlX9AGEn4GHkQ
Pu0b3MruWQzDGEwIRJGo2SwTwyg3hCHIOnT4zPc18VGgx7osrAgI+HmpWZaC
ltisAc1BK3HggUdcVWWzXJVNHUp4sHwng0NiP9ylbHWGQHM0Iuls2G9VJu2C
FAMmb/rgG0LXzEOW/9lKIA2dPp4gGR3VvE1urTebvI0TUbDMuMsz42iRb8Qi
uAY4AGtDlPyhURX7rCh0nsXBrUTOJVjfggWM7Xck1DOgnuuxAK4OdPGILwKd
ERQzChCmnTdGV5bAwLVaotCiEQct8hvAKxqMjDqQPAOTX5ItLeRtADKgzzmg
ZIaeoO8YDa1AWFZlzkgGvlIVLRQlckJQijRARVSCjZqjcy4G5m6RTpSL+Esc
fFnC52glMtpVJLNMGdx7CjqCnqy4aRv+h0c36MWCuoAfb1TGG22I358DW+8t
LYaUuMI9Y+4dWpPIUeqg68GF0fYbDbZWSwZNvOWwEJmWmgIgCIUrDKeiOol1
xDrXTQklHlQnSgptfVkYVW01gh5ioVlyxtxIxtjyj2Fj1pyOmYmFA5ttYdmE
1DlOCYFlDuqC0egk+ctfjCP+6RP+MhwI6HwfjwRgI1xor+FIAOLTJwIWl777
bblz3OtuiR337RDP9107pEK5ADRrcRUvEyj9qpV9Ckt8ReHOB4VwnLNvggv9
ybEZFskee/7OxAizeOY8xOi3Ja5kXZJjD8Qu4HEPH6G50hITHx0wBWNOwzFN
kGEP9sePqH769L1d7FmDYigwypVLo8xZ6WtvyS0lnmCAOr5aG942K93DoERd
NWnAv1YJ+fvqP53MZjOrNgJm6DUCGI6ID/1pUN3+17jcIB9gOA7XixngZI+n
3YHEYRxpG6BW44LiDukY3/r+DLBH1LthyXv2HUkeDYoaFC1rYTwuH01gduRj
TaGRvBSwB4pjF2Q7EAtROITcLOhG+144gQU/6KTYPZr6HpoPSDaDOOYJcMzT
1sgb5AvSR9gQFb1cb4i312iexC0oZ1KeCIqtzwt9GM2F+I0aozIgiyvJbSIO
MUYs0WJNES20chN0TLExUqrATxeNtqEkcI/JbJpoFwatxrwVw6t994Ricp+h
jb7HvbEwyzlYA+DN4STCrSuBVMsx6ET5ZgN6MMykDXrGR2EZcip88GrUqTOO
zN++G2iMqgYyFctGLHkvRoQyWFyRDRuoSwOuPetEZrRA5mK4TObUbnLc2e+F
be0WGExH+s/iKJgou7nAdnle3lqYZoaCiciOZcY95U8H19FKDFv3ykTL4Hck
VtpQWDB4PHDJW7VNEQjjhbGGhunDfho0YRgb4XOFGujaijwWt/TCxn4wuBMB
9oV62SCuwb4Zcdvn2RPOvCAwBoT9APGDg8LJcWZXz66HP22h1podsKxJZU9D
IYBtarthdU8VeyEcVgr4SKJXAh2AgIU9J9vin1FBNXIfcD7JSzdygph5byA+
scehNrR6GJEj9mWj6qXZULE7M08a1zxh3GwLLIDgKVCpsu47eMIUdFUUulQF
NIUNYMzSelCib+6tg47xPEQ6gB+aGp7eg71yMNJG6t5dHk+Ss5PTnybJm5+n
r8/eJE8wyQX2ZdtGkV9jjc5T6hYanV4exxqd2jwUBpAJRsiPoLioaqtLQZZq
Il8v8CSCTXGemu4tNVB9gsu0SPMPBpOg83Sl5A05PALcjLQBceg8AMSCjQFT
JmfL2YQwBMU9TPD5OKqgnH4SGcZrOSTK9Wn486IpDIv58BJZa6TiJ3kC2/HU
oMHYmEZ+kQ1IemCS7UhH1PWPpCrZ1AXDMJOcSu+jyOKsEvAzYZr8FodFY9oa
egqWefXzJQMdzAF++hRbkhvJJt6QO7VT/xbau51ADJCirsjFVlYeFOOFaVlh
+ki05VK4QM5YXVTo+SiqESIlq42zqkwqq5OdAwsgTNh+kLVIvZRRrcIWNkom
ci++8mssj1urGGbgXZDqq6/AKzlKjgvfgg4Jxt3C08lgeHqSdBJu8UaUmGAi
RZN/M05cH4+2Qq5wHrHNyZTg0ZhQT35j7fvDFtPPHsYamcmYGf9GEKCm/8P0
QMHVeRuZccBzMpQHHuSXkaDziHOL5baEaYO63IFujV/bpjwY6GGssvucYcSg
9MXjxIfxnnVlOznsbuQ+SIGOJnFiyZt7blMICaIIdGRnhuJ7wdbcJc1gtuZe
6QUjQtr4wXmQ/dlSMFbk4GlpmPUaacuRWKGNRBlCg1lThAy9WKsXhTVmbFE2
XhJ2ECs7vw9H1yvy5kzOEnoE+GRSmX9uNH6YCsry+clZwk9tSsK4J+GILjho
HSozRJtbyGYYy8fRXZyxv4qheKCNY7vQPFhUGKSz98PRRCL0Fri0k14xUdB7
5KhM7hfUkZjLnGNUPA3SfCabZIegPLVWOMU2aso1GmEYfEhUI14fxQYNgwTr
LSiG7ToainamaJKDybaePMWqZzbZiuG3hlLHOoXJM4Dx0xmskk5sqGtMH50J
zB+NqSFEq5ogHyOzmDlm0iVd7eYm4MFNyqP79SGbxtWedMCkTbl3MHkfc24o
JtCaPsLFc2R6LfMF7vafS0VFIIhDSgRWtQzT+rO7K0JvWVt9Py0YoUigAtkR
wp0spHVpF6X1zz2OMFt8SbG6aZuF4xiwtTVx6EvygwNEZuPQBkcBvRCJw802
YG5YfSgPQH5FXO7N5N9QxOV+c++WlmlG0hTNGFiSDUaY5Fqf/hQyauNkIbQ2
ZUKwLRIlhSMDVKjLRqITNnLyYASi47H0Wrsacs8VcoUgNtzTtuokxnr9cTGx
dYxsgPXJxeuzp6MjQIPAOJ3E6MRbj1oRVLy36RRB6qSxeXbqI83aFh/elqwn
OmjJx2NP8DjU0/C4lOOIOK3N9gJf5FJgHVucDdhxGjJEVHntdUCN41kz3tiT
No9AWpGOcQV1kFbVWU1H3MXqbo3VXEtpbZaqrBJrffql5KxvR18NaUgjjHh2
gsKwWGJWoNJGtJTPYtNjY0grVYg2sBaKcr6oanRD9nXR5KiaxLXxkwk6xXgD
8Sm2o0n2B/udjqUpLXT2TsDtdOkHmQHDL14EIZrzCSsnelzzpTiEIzjRUZ0M
wXTZ+WONEimr7HkYHplG5HyQQCjjTgf8v6FTqJnuQzHu3cZfe/zHlcPCJws5
XBlHhRroVcwxLLflOtkkXYEhKKYbLMmnTBKD5Uny5Pzt6fTk4vjpLDE/ebBb
E+JuC1E5N8J+XJAddEkr8GgoNI3iBkAipSyGLQBgmtmEETxi4vkTbx3apanF
BhcLKqHmQC/FisO6XA75MDdyMZH1IwwphimRqg1MxSOFNqQ4aQnwdGKQOBWT
ZBFWPjX5ZXecapCBe5noO7Nz/8m/DYMzG9K5MVtWZqvcsGoVRtAKA9TkejLI
NF4FRad9PdpPw8/6AWmr771WBq5ieUFQnV2Br6IxnOR1iJN9/MgflfnC/wTY
jFlmfHKmxDa34IeW17cL0ejJMB44cUv5v4gMnAvaZlg92jsVIz8iojSZKITZ
FEcneVyI1KElgguYj7FIM6YnHVz3JaqlknGHeu44tXbNwgKZaE8ti7n6ALS3
7dIpnqAoYMpoiL73poxkDMgWfM9VY6x/WgoaXVhrnjU+wTjJwchwrph0rVqe
AARVZn5CaKet48Qe9UM0XyPF0P+NArxWmcFyH4JYfTDFEjMULWrtWS+/bzN2
EeGy+y8yYYr9TcIteAomHz5mDQHpqegCdGwF3dKtQKY7kS8TxfBDPmEtH52U
sF7DYPAQ+3Bh+jaLGY+jJ5exulYOtrCHx8QYWDJrPWTI6qYts7Wk46oMtwMu
HYoxRN06oEFoAXFtKoPgAuxWfSth5abm026TzY34lSScYhMuicoJVHOIzJaR
7XB9SVgHmNRBsFhMCznP9wBV7UJmHubwirI3qwrDqXsBq+1RLAJjWUQ7piFs
AWxSKjMu5ukFswIRi4Sv/EjBmuQeoEHcQQv2zKXRTKorzCGdcRni56a9pOnG
c/1Is2qDAKPWMToTl0/Y4jlHwabiCRD+hnzOypTqPLUlKUVNgW1R2JCbczpv
RN5Ig4ZHssTcwOZIkbRUmrIZfsqqLcvFA6Rw6IWdGgD2GkuaeSHmNwu6Ec84
2InlFVzOANtRydrIaIvyaGW6x0Gj9IzP0oQ+Y+ChGBShWSQGREI6XiNK0pqj
swBuM65/JfhEIu8gKsR2IgHREJ8sRgJvXILiGg2DVkMtAhEPoVYkTGdDTe3U
B9ihh3+s5zJCaXOYzoLsKAKLz/SLALL4SoaCgENTarcSZ9VxaqI7HnGn/rlv
n71vk3G/YXA+vZqprt/gyduYZn84lL3rzozh3B2Edx5HnAym16pFD1h3CpxU
mEIDW4JpgMkQZydG5ZlH2ZT2ZuhJjC0gG1etVMOI1EQWI+Kp4obrJOzEKPXW
iPzi3asQWfFVMqbyGSthTI3fvRGBV2Z51+p8Fw/mw7E8cCwuaL5znBOWBlEp
2E4viANAtmAkkhSxGEDklLL6qwdQOvozhtm8SSOYVhkftcWYVZuxCh9Fd9Ju
+t1YR9nzIq7AdyUtiCJ8EKyYHOSo22uUnZt7jueBkTM4mFd7XnaAbybhfN2x
EzpH7c6v7SRQWNg1SJ+hcFtICgvedl/x0MsoDg3QRjVC7kVvtpDLsmbfopWi
h2ci+VQPhkqhm4ETQBMbxI0TFmMRSasN2tNxO+UMh6ZcbOu5jsqZf7BukNfw
KKBhGlSLTy4uXz9tz7vjMmKL0LGIil0TT7IFFpR18CPvTttEGa+PKUJC9mJk
XqlpL8hPANpcbIBHIxxycMOZ6y6QGjbNtsjLW1dGTvqM9HxpsQkWltijQn5X
fvnsQD78HhqKqNgutp+/CAXKqYCOzuoogZGLZxJjq+62q3QxxHGgGv56+0oe
a6iH/nF2NrK4zt7GWpjjLVanmaHaXoe08qSPg3PpoWCOTPmpj55ett+0wcjZ
f//n3TnnDBYBdvZvxTuSh/tH5Z7o8jr8E2/T4aAwyG830b/nygYpxyYWOARe
0dsksYcT+WS5WotK5Vt2Ww3I5Ru/nP8x7G3hxSB32iwuz+SrfPCwWcGTyPDS
p6I9LMzHayZ8r5E/z1xdS64Cs+cNzFTDueVqXgm8hXLCRAAUD+vLE+88Zgjg
bPud+vZtWUy/oCX1SoSibKh3GNMIdDd8fVfwbppHkdegUHYZY5cD25VRmxzY
0jd8HYRXofiFZLKAvbqPvR48gWt0mAFoHdw2Q1/aP7SDPMr1nKi6z1+f3RxS
tAMPA3JZI1h9g/3vYuJDlvs8LX0vfutq6H8y252ZbZeL5hL9F6/P23rO4Cyl
d3sosKEqXOw3PJvcbcaOwE6jEE73voaho+c55O0revIx0R+z1sHTvCPbRnqa
a9o/0x70Vfu4KRiwH2xhbXSQiz1M2VFU4GgeLitKA5JX6nFGkY0Qv3d6THSk
uURPU9tOw0AJiVuM8ahANtSE7ixZZEKdg2NBcELdhxZWkSCTit7pZnPWUDNW
wymYLtaiKKhSyqPETk/J3UzQhaJj/pt3os458z19EDlHF3XBKYFKxWJ0Gnzb
pSpd5Kl5JAyF4O3rmu/9K/GQ/IJPo1QUK+DiT3tIUy28U687GcqMNDMXAw3l
F7xYY7LLiLSXtAzw7XipyuDYs3iGJTK4O7w/4D4Q8zO/aba+fKoq7pVEO5mF
UbhhwRu4QzPmEw9Ni/qJzy3ee7xtZMwInggRxH32PSslx8648jDfftb+x+dx
D0v7EBVobh3SD1aAya1NhcQXZyYZdtFGF1kIKd9gyqY7CYdWcZmL29wtUKYE
YmuNCl3RiXeJoNZlpsr4ks57FEck3kyG6o7QtPJJMK+CtZIC22MFDb6Ug3m+
vQnTnhkHRd1e2o/4NglXaznKuynFnmeTQHVN19yjjqwERYVTvPAFiT0XGqtD
JOG2ThE6m2jsNjBNCJfuTpoA++a5Fzaw5FLmfgSzGFhambR3OgDU4btEbXO/
cjbxbh/D+Lu7F6vic32Y0ro2V0LcrrY+YO0Xk9pDKh2Z6dyj5HDIwh+QedoV
ONPgBkaZuXZ0TShhHdr1fQS6JNROhUbGRdJJB1OEfMtHDPtjdVtG0+PBdIz/
c9Vu09bVywTTxhzVAyUGRR1vTSOR31WKyicJzcUfthKbeMbNzx5R5SLyyBqj
Ll5/iR0tdccVDmjWv/4arwauuhs8fdNeWYjXAMoicwdxbC94rXYdP5RnqnBW
pUplV8vZHLe9bxjrbDeWOU3VvivXPwn9BH/seD0RGkIQNrzFvb7nktsU37Dw
ReWu6zUoo7nC+7MihzkHJoL3fFbltTQ32rpzhyS3FMGL3EHbueKwf2Ldguzo
beDxOxJH0HaLBe4MBTJOoNnbuNGr9ToYoDndcn4Xoo8noFsAOzAO0qY1jlmG
t8cMDuyfIeG9tqfBdiXC3RG1uLPD7zjxg8yxClV8tQF0RYCwC5Z480waI6zR
N+opovLOO5rfYtOI1ruP5jag1J7Ay7xjca1LYepyOAEuWEK5ZE83m01Z8ZGf
XVpxN4rtp8vXarmqHeQYMIJ2g700D68KYBHsEWt7k0Gnj7beja3+5V/DGmES
FM9QATCW5Xq7btHbi9nh7BDVBjBZ+KodqmKw90e1WW4zyYppvBLa3CnKINoS
ePBFFrrFT9Ccl2fuHO2uxkuoWRDSHxxly02ANFG3z2hmzQXVanutBJeLBH6J
tYh2P/l23b4z0hH8ySgEsuu3dxQMcGFnlOEIbMwKmFvwunjJbA4zmC8dY4g7
Kp5doowuuO/shjOzFefC3bwW1lkkpCTC2hyjqsfHtbMtpMxoI+leOowe45V4
Y4ePBinlcmMtAcaWNngcA6fkvQbFv6iPh2uxhT0yYqGgGowE41wblWfmJsms
vC3w1YDSv8JYfqSLGPN4mHTgxqt7lUibmjb4HS/KailJN5ppmkBBSVy6w+8G
V6k7mjnGchbZmbuwkCoa73M1d0/yfWkYVqttX9qDOvYGQoa0Nb+5gh0xmOXv
NL/ng650iFCN7jJ1QZ+RDWdAxEmNojAkp6nWBiRRSFu5CimPbHQKldbmQIMl
Sh09wk2zGpWArom+cofeNb1TtHtIZrfs9nBLRGt0lYMBELE9BQ/FxAY6YejI
M6FuRt3vH2yJbVsElvwAgPSW7vvFsBUswqGTvys48fa5c/1m7O4MfmuHu143
vPRdI3fxRy3gGVD5IW1A5P9OpLERkZ3uzR1oqOqARCvhLlor+Uy+OQJ1hzdg
PYSk/uFinxILS9yUiOtLaEsld0lvS2qEMfb4k4fhP6fEOfAFhk44BSGa9gGX
nrbY109Xhuea/NpxOhf50HsNho/23rXCOTyUa1W3n2i1AWF7f+dCpLhBXPk7
rAD9IKwz4Hd6oFXyFgr06329GX4PW40p5vAtlLozcQ7OZQpkpImrD//garzM
vwcvonQyNRamxC1a/8/viYhOp3tghucT1tlFRvdI1vr7HWerQ24T8WUTzUEe
BhEY4/2eoQMFVllsWKjDwA6HnTBEgr9UDb4OLHQKAVUV2dSMMCwQcTqZGAqd
70WJ5gCv1Yh3LtHus7CN440SRpdNZW62sOl+MyF3/d1nEDh2l8DDlImLP3gM
FjlXN3KtROR60i89FV9R7ZrJvcIy3YO/nTjAUP2INmFWuiqIXd3glCR+cNnM
8aWy/v01+GLQftVCqAaIFsyi5g5ln6OxRsfg3WBFd3vZZ4L+hEvRdVFB23AH
d2GgV7X1VP3yG+/EfGgRbfnYOK91TFElu7K7gzODKwsG2PKvsIYRa9pfwjhH
dy9diAGGh65AdLNWwZcwW7r8ze+uVZ78Jp+dcINcDB9B8Juw7gw4bPMRzDGC
OGjx5pJgrI5DFUya1ssW7Na1wmhaNtsWXBiXio0lQV8MhsEoM7oP0nsXg9Id
6BHUsXkaaS7z8tbf6jfqo7zfTvtaw9KRdslcRkc3fgd6l07+eBqE79SsxKLm
a2hizDEZUYddhO9/+ZSBSFft+c0HrLzTzob9KFcXTILc6rXMVAe/2Xs9cGlN
Vdyhp6qEHfV1IIc1/JICSsBkjSucs+/GbMFMQK2aDvnmzA547gkrlJi5gJsE
xUTMWXa+cUCai7NS9C+EphK30VRgnxO4DAIYKHJEd8ADM3ikDZsJaLA1F40I
CuFO59sphXKxriDwYy48prb+LJ5z7U7MHNgfNjmdwk0xXuA5Sdw1tOEdgoGw
GgRsvZNAADmf4N6VPI7EqsEoTg8GtDfhB0UEwTWgvmjHa5S7hx1i51njMmNh
fyhtfCLdJ2NnifZCExsKDSopfMIZj/nSsuQJvlsgM1cz6u5rZOybniwHT+1b
UgJn2ntpNQVX7atITHFgtzStzWvSDRgusOq9wsh7OaG5F9d5OPzSHO/WOs4/
Aw3OzTVx/knBUP7SYLHm9W/pKh6YIaNvX3ZDGkPU3rc49ZXVSnjBfKO9NyM6
Orl3UZqsrKHNLHnjv+EGX+dCF+xwUUw9POkJvd4ox13hnP4culgoc0sLWIDb
Od1uB/rFP1vDi9PunVfjdzLbOq7z47fHOziEM03cUnivV8HXh+NMuKPjFF8f
kstsaS6m+csRvzRDZv+6t4AZyb1P3Z7N69v5LmWaLTwC0tvAxlWNqvG+T0N3
2k3vrTqw5l/PLzjyTTwgiutkWzadUlPY1Dd4gOGPTaFvyworuP9Qrorkx0oA
VL9Sa2BJkJu5lNeT5DcBbPxjA2oDtNc7+DBNBfwOtlmBgF7WcoO1969EBVuP
VxwKmN5P5WKxFqwVL8vF//yXAFiQK++NjWj5KzVvbEF05GVAeqPMazDpIj7z
llZ+L6VdL8E+oCJBxtmj/wWjXQWT+IsAAA==

-->

</rfc>
