<?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.19 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-pqt-hybrid-terminology-04" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.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-04"/>
    <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="September" day="10"/>
    <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-restistant 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-restistant 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 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>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>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 so will be 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, but 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>
          <t>PQ/T hybrid KEMs, PQ/T hybrid PKE, and PQ/T hybrid digital signatures are all examples of PQ/T hybrid schemes.</t>
        </dd>
        <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 chose 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 certificate 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="22" month="July" 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 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-04"/>
      </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="29" month="April" 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-05"/>
      </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="5" month="April" 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-10"/>
      </reference>
      <reference anchor="I-D.ietf-lamps-pq-composite-kem">
        <front>
          <title>Composite ML-KEM for Use in the Internet 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="8" month="July" year="2024"/>
          <abstract>
            <t>   This document introduces a set of Key Encapsulation Mechanism (KEM)
   schemes that use pairs of cryptographic elements such as public keys
   and cipher texts to combine their security properties.  These schemes
   effectively mitigate risks associated with the adoption of post-
   quantum cryptography and are fully compatible with existing X.509,
   PKIX, and CMS data structures and protocols.  This document defines
   eleven specific pairwise combinations, namely ML-KEM Composite
   Schemes, that blend ML-KEM with traditional algorithms such as RSA-
   OAEP, ECDH, X25519, and X448.  For use within CMS, this document is
   intended to be coupled with the CMS KEMRecipientInfo mechanism in
   [I-D.housley-lamps-cms-kemri].  These combinations are tailored to
   meet security best practices and regulatory requirements.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-kem-04"/>
      </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/3q6ok6mddvJ9OD540e6ma+V1jCPeruB
Z8/Prl49flQ067msjqBPGAX+SstCy0I3+iipq0Y+fgRz+xqmWUlxlFyenTx+
dFtW18uqbDZHycUvv55fPH50LbfwYQZdFjBoIevpKc4LnpVFg50mSfhAkvAU
foOuVLFMfsRv8eO1UPlRsqrrjT7a38ffRJWu1I2c4RpnZbXcxw/251V5q+X+
5kO6j4/hZ/d+DP+Ipl6VuPpkiv0kyaLJcybtq7ysZJHK5LRSOi3znBtAX6JQ
/yFwP4+SX18nb4XZ2pMtEDK5lGlTqXqbnMiiriQ/JHldC9PlLPt9kep0tixv
Zs11bPA3Kl0JmScXotKwIZ8/9Jo7nG2e7Rr6B+iiFslPIpexYd+KGxgQ+XsJ
bN0A0yAzl2UeDDenTmYr6OT3xUbPZNYguZF/qzX0dMNc8cP529Ozn4/40VpU
S1m325iVinbu2cHs2cHBi/2XL76bfj09+PpgevjNN88Opi/ePzs0T7IUGuF5
LbfJWZGKjW5ymnTyRsLiC6XXOhFFlhzDpgOFFMqVaf4RGyzNglumoH+m9ocE
5A/E4u0s+UEVmczbz5lyb1UhOl91n/0DPAssEHn4DyL90MhcFbLbotvHm1ny
CjhyBW27nbwBLu992X3+h1nyYwn0yW+k7nYAmy+K/tfdLk5nyWUt5yBm3Q5O
y2aZCx1+XckFqJUaaH4UasaTarupS2CkzWqbbDazw4Nvp4eH3/JTWlZKamQZ
txWnfzw/SnbzA6my5PDg2cvpwQvkO8tpPx3/fDbAbXJTqaKeKZFWxHWHB4df
7z8//Hq2yRYBlx0nb0tgemArq8vVshB1U0mr1SNc5AgY56AB/gmfgn1rhdLb
sFBafVozeckoyQtcXnLManECimUDGsMuMiTbIVD1xRQ/xc/Pri7P319dPjv4
+sWL5wPEu729nclas7zC9GGIah8/eF/rfXzy4OA9/vXyJf32/Pn+wbMZ/fv+
24P9Wr/nT28OnuGfTY/mJ//+w9m77xPDNlMtFjKQdiO+McoDFVGDHdE6kqtL
YJ+vExgr+bdnM/jTWfnBlHno/OrX6dX0T98cvJwiG40sW9XNDCi7X8l0/2r6
7uxk+qeZfQyY8jxYB3WbUIPkagWmRcFjNZh2mORFM89VOgVbSkpK1HWl5g1w
WiqrWi1IWyWLCnYdDfDoUmmYvijQYt+eX169v/jl5P2r418GlpXqKp2BuqzR
SuxfVOWfYZJ6f4OS+8FsQepJ7v5CfNDBOoeFHEYdnbozaeeFhs5w/eUCtAmQ
RFQZ6+8rUOcGaz3B5TztbOIhsu/BN3a1yeVF8t0B7Ow3h7stzbcHh9/t41Oz
y4uZeSpYWqdHUAdAoIXKJeG+X0ExgnqWmazQLLcrVylx6htRiCXoCBDFy62u
5XqAGF21epYLsgygOER1Lav2e95wa1dBK3nU+VnMy0ogfw12/AZmDtp6rbIv
1uWpKIB5QDMJ2ELxJfr9Upzx7JvpswPWaufTU8KG01ysN3qaqVzVK4WM3Uqb
Poq0xO+nc1DSgFunsJTpuslrNcUNDJvXubZIPAMztixivW0+TNNyDZKlagmi
v6Y2716dPH/5/KX9+ZvD7w7sz989f/6t/fnls/bzl6BijxjSTqfTRMx1XYm0
TvijPwLrCL0BKUaSAfgBaA+bQz5JUpeJL9mJyMHXAGIAWFJFkgYsvKnKugQs
DF9p6ieTNzIvN8TQ0DWvN9FsB6GFqKGTtKw2uLkymZf1qjMa7Frt+UdCb9dr
Caov9SYyS0Bbwojg9jQ0VCYXIA4wQMft0k26sqPDQ+c1zlOhNcwA6cFK5zJp
NPwICEWgqZQM8WEWk2RVbiTC4O0EW6IPBCYd3SHQhNCK1XIKngVCbIAJpYYZ
qQX1UbekmSTa8uSEHmH8rIl9YVZ2j0DkMjTajx/9C/pNVZk1KTZ5/AgtA0gI
rEIgSM2x73kOugJJjKtZguleCDQcplsaJwPcV0mgMpBDmB0sb7CpKhTaDiVz
kBMgk8xztYGuE/AXAOUlDZCn2sBur2FrLItEd4Kph6RGOyVhpWC09Io2heew
VDXMWFtMpBEoYXfKuIa0l1JLtygm0or2gcZtB5sLHI07WE+SW5XnuIM3TV6A
foWncaPAUIr0GmeGnuQlqNHf6eTYdoJPC+CLBYi0glnm2yRH7Z8sJfaRTzcN
MCdMxzIkiiPolmqSXBflbcGcEihyASySvJO5vIEnEmflzHPJk5N3v5w8hWWe
NJXhDJkp2lqd3Aiw9TClW1jvBLdCLSbMtQJlSQENaJXyI5rfJPmpvAUJg8ko
YuVCplJr7AMXji6M2qBcIQVhmA146fgNiIdECLEEowEb2vZvZRV6PhUAG4Ho
uDKSjUyA0gTr+fwpTAHEFPwAtxVdkveolaTQHLZGA08aBskk9Y3cOQd5AQ+T
MDJvFzzBgyRILZgOgmjcv1D7bFgqjCbB1cmPqMacMEMb4Egaby2KbbKV4DAz
R9EjMK2irEnsNxm5e9ASCJWLVILIY48i18hECcjSNWyHmRJS2xAMHsrAr4bJ
IXvC75W1RLlayFqtJYuMqO18Z6x0lyU+BDKwwZiKxiljD5sS0bmC5zva045c
pHmTgQooQbtssQsnZzCVJ1a7KJCNp55Ght6RFHGxdfRjU+TopzFkIB2ndLdV
I/vfgrrAv4lFQLZABWpNesk1c0LtDYmjoazAWL7GBzFeIVqKiXlUt02M/pqS
/opruValTUmlRVt5E/ItTmjhfKNzjorHNzt7gaWyLfeQV4iLSDkCYcmw8HYr
Qy/a37ZvZJDjmk2xYaAN4X+zZPoCjFtoLKEzo7ZAA9nBYEdT8BTk4ELuuvko
8BkoG9IvLJ0pqhuWeJbTiwGkkJK20NQtrb7iUYBtrMcAcqCQd2vcrg++J+fT
HNgIpwT/rcH9r53QtIYWyQIijiIvPwKIAl7S5RrtiaU6ioElYDB+PTABNPcf
N0B9NA8I7cjXIrLVMba+rxCBG5cA8sEfgTHFspJyYnW2N+dQTBB8gWAga2BP
VblWqERCpd7OC6QKPkjLBmRkLa7vSQHoO5cCMS04MGqN8VPEQR3C8g8IJAkh
IxfCp32TW9ldi6EYgwqBKhJ1m2VjGOWGUATZhw6n+d4mPgoEWZeFFQIBPy81
S1PQEps1oDtoJQ4+8IirqmyWq7KpQxkPlu+kcEjwh7uUrdZABDEo6riaW5VJ
uxbFaMmbOTiG0Cvzj2V+NhFIPqeMJ0hBRzBvf1vTzfZu4+QTzDJu8Mx4WeQY
sfytAQvAshAif2hUxQ4rSpxnbnAXkWsJ07dIAQP7HfH0rKfndyyAowNFPOKI
QGeEw4z2g2nnjVGUJfBurZYosGjBQYX8BtiKBiOLDuTOwN6XZEgLeRsgDOhz
DhCZcScoO4ZCKxCUVZkzjIGvVEULRWmcEI4i6a+ISrBRc/TMxcDcLcyJMhB/
iYMvS/gcTURGu4pklikje087R6CTlTRtY//w6AZdWFAV8OONynijDfH7c2DT
vaXFkAZXuGfMuENrEjkKHHQ9uDDafqO91mrJiIm3HBYi01JT9ANxcIWxVNQk
sY5Y37opobCD2kRJoa0vC6OmrTLQQyw0S86YG8kSW/4xbMxa0zEzsXBgsC0m
m5AqxykhqsxBUzAUnSR/+Yvxwj99wl+GowCd7+NhAGyEC+01HIk+fPpEqOLS
970td4673C2x444dgvm+X4dUKBcAZS2o4mUCpV+1sk8xia84aGaddhMk6I/D
1lQke+zBO0MhzDqYiRBr35Y4qXVJDjrQrYDHPZyDRkdLTGB0QBGMOQ3HNMGC
PSC1Hxn99Ol7nDfFjGPztgFnM+c9DBPUVZMGTGU1g09s/+lkNptZWQ52qNcI
gDFiMPRwQZ/6X+PEgwi9YQOMIWBONtnjaXdAahjZ2QY40jiFSGsdYybfwwBW
ivobLA7PviNxoEFRraETWxgfyLfumK/4WFOwIi9FprEhdk0KHbEJBSjI8YFu
tO8Xk/H2w0CKHZap7zP5AGEziCuewN4/bS2vwaIgEgTWUPvK9Ya4dI02Q9yC
xiSNhjDVeqHQh1EniKeoMUoomUFJjgxxiLEsiRZrijGh6Zmgq4iNkVIFfrpo
tA3ugMNKtszEnzCMNOY/GF7tOwwUJfscFXFXIOWAC2HIlUCK5RgCouyvQSEY
9NEGyuKjsAQ5FT6QNPrNWSvmbd8pM1ZOA4mKZSOWvA8jAhksrMiGLcalAbqe
uSC7ViBjMXQl+2Y3OO5694KolvwGZJEWs8AGJspOJ7Bcnpe3FjeZoWAismMq
cT/508F1tNLC5rYysSv4HYmVNhSkCx4PHORW+VI8wLhErGdh+rCfxrwbpkY8
W6H2ubbijqUmvSCuH5rtxGN9gV42CDSwb4bA9nn2SzMvJIvhWT9c++AQbXKc
2dWzG+BPW6i1Zmcoa1LZ006IKJvabljdU8NeQIUVAj6S6JVARB6wsOfyWkAy
KqRG5gPOJ3npxjEQxO4NRAv2OPCFFg/jY8S+bBq9pBcqdWesSduaJ4zPa+Nj
QPAUqFRZXxrcUgqBKgokqgKawgYwiGhdGtE32tZbxugaQg9AAU0NT+/BXjlc
Z+Nm7y6PJ8nZyelPk+TNz9PXZ2+SJ5hyAtuybWO6r7Fi5il1C41OL49jjU5t
VgjDuZSwlR9BcVENVZeCLNVEvl4YSASb4lwn3VtqoPoEF02R1h8M7UDn6UrJ
G/JABOD+tAFx6DwAxIKNATMmZ8vZhPADBSFMKPg4qqCcfhIZRk85QMnVYvjz
oikMi/l4D1lrpP4meQLb8dRgutiYRn6RDUh6YJLtSEfU9Y+kKtnMBcMwk5xK
76PI4qwS8PNSmhwJhyhj2hp6CpZ59fMlgxzMyH36FFuSG8mmwZA7tVP/Fmu7
nUD7n6KuyMVWVh4M44VpWWEyR7TFS7hAzh9dVOiKKKrYISWrjfeoTGKpkysD
CyBMEH2QtUi9lFGtwhY2SibC+1/5FY/HrVUM8+EuYPTVV+AmHCXHhW9BhwTj
bsHiZDBYPEk66a94I0oTMJGiqbgZp5GPR1shVzgX1WZISvBLTOwlv7H2/WGL
6efyYo3MZMyMfyMIUNP/YXqg4Oq8DZW0oHMgKTvILiMR4BFnE2tfCc4GRbID
3Ro/s80/MM7DsGH3OcOHQR2Kx4gPYz3rj3YSyt0wepCPHM2oxDIp99ulEBBE
8efIxgyF24KduUvI3+zMvUL9RoC08YDzIBOzpYynyMHH0jDrNZKWA6NCG3ky
dAajpggXeqFPLyhqjNiibLyE6CBSdh4fjq5X5MeZ/CH0CODJpBX/3Gj8MBWU
cfMTpYSe2uyAcU7CEV2sDgYhX8oM0Yb5sxlG1XF0F/brr2IoPPe9SRa7IDnY
Uxiks/fDwT0i9BaYtJPpMEHJe+SLTB4WlJGYy5xDRjwN0nsms2OHoJyxVjjF
NohpgxleUHpIUCMuH0XqDH8Eyy0oouw6Goo9pmiPg7m2LjxFjjkg2HpECP3R
T0th/oxg/NwCK6UTG7Ea00hnArM5Y4oI4aomzMfQLGaPudok6eo3NwEPb1Ja
2y/X2DSuFKSDJm0GvAPK+6BzQ7RpbR8B4znyvZb5Ajf8z6WimgwEIiUiq1qG
WfbZXVXhxF/WVt9PEUYoEmhB9oRwJwtpfdpFaR10jyvMFl9SoG7apsQ4Kmut
TRz7kgjhAJHZOLjBIUAvRuKAsw1hG3YfisyTYxEXfTP5NxRyud/cu5VemqE0
hTMGlmSjESbd1ac/xYzaIFmIrU3VDmyLREnh0ADVzbKd6MSNnDwYgei4LL3W
rqTb84VcXYaN97StOqmqXn9c22s9IxtdfXLx+uzp6AjQILBPJzE68dajZgQt
7206hZA6SWWenfpIs7a1gLcl64kOXvIR2RM8nfQ0PL3kOCJOa7O9wBe5FFhW
FmcD9pyGbBEVQnsdUON4Hos39qRNB5BWpFNVQVmiVXVW0xF3sbpbY3HVUlqz
pSqrxFqnfik5D9vRV0Ma0ggjHmWgGCxWfBWotBEw5bPY9Nge0koVAg4sTaIs
LKoa3ZCJXTQ5qiZxbRxlQk8x3kCEiu1okv3BfqdjiUMLnr0DaTt9+kFmwPiL
F0KIpm7COoYe13wpDuEQTnRUJ0MwXfb+WKNEqhx7PoZHphE5HyQQyrjTAf9v
6BRqpvtQjHu3Adge/3Ehr/DJQi5XxmGhBnoVc4zLbblsNUlXYAiK6QYr5CmN
xHh5kjw5f3s6Pbk4fjpLzE8e8tYEutu6UE6MsCdnUkC2QMNkrMCpodg0ihsA
iZTSGDYlzzSz2SJ4xAT0J946tEsciw0uFlRCzZFeChaHZbIc82Fu5NIe60oY
UgxTIlUbmIpHCm1IcdIS4OnEgHEq78girHxqMr7udNMgA/dyw3dm5/6TfxsG
ZzakY1y2yMsWnWERKYygFUaoyftkkGk8CwpP+3q0nxif9SPSVt97rQxcxYR/
UCxdgb+iMZ7kdYiTxf/8cZkz/E+A0Zhpxqdnal5zC39ogX3LEI2gDCOCE7eY
/4vYwPmhbYLVo75TMvIjYkqTjEKgTaF0ksiFSB1eIsCAKRmLNWOa0gF2X6Za
KhmHqOeTU2vXLCxaifbUMpkrD0CL2y6dggqKYqaMh+h7b8pIxoBswfdcycUa
qKWg0Ya15lnjE4yUHJAM54p516rlCcBQZebnhHZaO87tUT9E8zVSDD3gKMRr
1Rks9yGY1YdTLDFDIaPWovXS+zZpFxEuu/8iE6b63uTcgqdg8uFj1hSQpoou
QMdW0C2nCmS6E/4ycQw/7hPW19HRBes3DEYQsQ8XqW8TmfFQenIZKzPlkAv7
eEyMgSWz1kOGrG7asldLOi7KcDvgMqIYSNStCxoEFxDZpjKMtM5lfSth5aYO
026TTY/4hSScZRMuj8o5VHOqy5Z27XB+SVgHmNSBsFhkCznP9wFV7QJnHurw
qqQ3qwpjqnsBq+1RNAKjWUQ7piFsAWxSKjOu5emFswIRiwSw/FjBmuQewEHc
RQv2zGXSTLYrTCOdcWng52a+pOnGc/5Is2qDAaPWMToTl1PY4sFDwabiCRD+
hrzOylTqPLVVKUVN0W1R2KCbcztvRN5Ig4dHEsXcwKZJkbRUnbIZfsqqLcvF
A6Rw+IXdGoD2GsuMeSHmNwu7EdE44IkVFlzRANtRydrIaIvzaGW6x0Gj9IzP
0gQ/Y+ChGBShWSQKREI6XrdJ0pqjuwCOM65/JfiIIO8gKsR2IgHREJ8sRkJv
XIXiGg3DVkMtAhEPoVYkUGeDTe3UB9ihh3+s7zJCaXO6zcLsKAKLz/SLALL4
SobCgENTarcSZ9Vxa6I7HnGo/rlvn71vk3G/YXA+vbKprt/gyduYZn84lL3r
zozh3B2Edx5HnAym16pFD1h2CpxUmFoDW4VpgMkQZydG5ZlH2ZT2ZuhJjK0h
G1etVMaI1EQWI+Kp4oZLJezEKAHXiPzi3asQWfHdLqbwGYthTJnfvRGBV2l5
13JYFxHm06o8cCwyaL5znBNWB1E12E4viENAtmYkkhaxGEDklLT6q4dQOvoz
htm8SSOYVhmffcWoVZuzEt3Yhtv0u7GOsmc4XI3vSloQRfggWDE5yFG31yg7
N/ccD+giZ3A4r/a87ADfTML5uqMgdLDZHSfbSaCwtmuQPkMBt5AUFrztvnOh
l1McGqCNaoTci95sIZdlzb5FK0UPz0VyYh2DpdDNwKmciQ3jxgk746BZ/8Ta
TjnDoSkb23quo3LmH3Yb5DU8nmeYBtXik4vL10/bA+i4jNgidCyiYtfEk2yB
BeUd/Ni70zZRxutjipCQvRiZV23aC/MTgDY3DeDJCIcc3HDm/gmkhk20LfLy
1lWSkz4jPV9abILVJfbMj9+VX0E7kBG/h4YiKraL7WcwQoFyKqCjszpKYOQm
mMTYqrvtKt3UcByohr/evpLHGuqhf5ydjSyus7exFuaEi9VpZqi21yGtPOnj
4Fx6KJgjU37yo6eX7TdtMHL23/95d845g0WAnf1b8Y7k4f5RuSe6vA7/xNt0
OCgM8ttN9C+eskHKsYkFDoFX+jZJ7NlEPu2t1qJS+ZbdVgNy+Qou538Me1t4
U8edNotrNPluHTxrVvAkMryFqWgP8PIJmwlfNOTPM1fXkuvA7JEDM9Vwbrma
VwKvhZwwEQDFw/ryxDuOGQI4236nvn1bFtMvaEm9IqEoG+odxjQC3Q1f3xW8
m+ZR5DUolF3G2OXAdmXUJge29A3fzuDVKH4hmSxgr+5jrwcP4BodZgBaB7fN
0Jf2z+0gj3JFJ6ru89dnN4cU7cDzgFzYCFbfYP+7mPiQ5T5PS9+L37oa+p/M
dmdm2+WiuVT/xevztqIzOE7pXecJbKgKF/sNjyZ3m7EjsNMohNO9r2Ho6HkO
efuKnnxM9MesdfA078i2kZ7mwvbPtAd91T5uCgbsB1tYGx3kcg9TeBQVOJqH
y4rSgOSVepxRZCPE7x0gEx1pLtHT1LbTMFBC4hZjPCqRDTWhO04WmVDn7FgQ
nFD3oYVVJMikonfA2Rw31IzVcAqmi7UoCqqV8iix01NyFxN0oeiY/+YdqnPO
fE8fRI7SRV1wSqBSuRgdCN92qUo3a2oeCUMhVIdFOf0Sj8sv+ERKRaECrv60
xzTVwjv3upOfzEAzc1fPUHrBCzUmu2xIe2/KANuOV6oMjj2LJ1gig7vj+wPe
A/E+s5tm48sHq+JOSbSTWRiEG5a7gTstYy7x0LSon/jc4r3H20bGjMCJEEDc
Z9+zUnLojEsP8+1n7X98HvcwtA/RgOYiIP1g/Zfc2kxIfHFmkmEXbXCRhZDS
DaZuupNvaPWWuUbNXcxkKiC21qbQlZl4kwgqXWaqjC/NvEdtROLNZKjsCC0r
nwbzSlgrKbA9FtDgSzKY59ubKe2pcdDT7SX6CG+TcLWWo7x7UuyZNglU18qe
lqoEBYVTvO4FiT0XGotDJMG2ThU6W2jsNrBMiJbuTpoA+ua5FzWw5FLmhgSz
GFhambS3OgDS4bs9bXO/dDbxLgTD8Lu7qqris32Y0bo2l0LcrrY+Xu1Xk9pT
Kh2Z6dyH5GDIwh+QedpVONPgBkWZuXZ0TShhHdr1XQS6tNNOhUbGRdJRB1OF
fMvHDPtjdVtGs+PBdIz7c9Vu09aVywTTxhTVAyUGRR0vMjMX9I1XovJxQnP1
hy3FJp5x87PHVLmKPLLGqIfXX2JHS91xhQOa9a+/xquB2+cGj9+0twjizXyy
yNxJHNsLXnNdx0/lmSKcValS2dVyNsVt7//FMtuNZU5Ttu/q9U9CN8EfO15O
hIYQhA1vVa/vueQ2wzcsfFG56zoNymiu8PasyGnOgYngrZtVeS3NDbPu4CHJ
LQXwInfCdm4d7B9atxg7ejt3/NrCEbDdYoE7Q4GM82f2dmx0ar0OBmhOt47f
hejj+ecWwA6Mg7RpjWOW4f0xgwP7h0h4r+1xsF15cHdGLe7r8DtH/BhzrEAV
XzUAXREg7IIl3jyTxQhL9I16iqi8847mt9g0ovXuo7kNKLVH8DLvXFzrUpiy
HM5/C5ZQrtjTzWZTVnzmZ5dW3I1i+9nytVquagc5Boyg3WAvy8OrAlgEe8Ta
3iTQ6aOtd4mqf/3XsEaYBLUzVP+LVbnerlv09mJ2ODtEtQFMFr76hooY7A1S
bZLbTLJiGq+ENtd8Moi2BB58sYRu8RM05+WZa0C7q/HyaRaE9AdH2XITIE3U
7TOaWHMxtdpeLcHVIoFfYi2i3U++8LbvjHQEfzIKgez67UUFA1zYGWU4ABuz
AuYevC5eMpvDDOZLxxjijopnlyijC+47u+HMbMG5cHevhWUWCSmJsDTHqOrx
ce1sCykz2ki6mQ6Dx3gp3tjZo0FKudRYS4CxpQ2exsApea8l8a/q4+FabGFP
jFgoqAYDwTjXRuWZuUcyK28LfFWf9G8Vlh/pKsY8HiUduPPqXhXSpqQNfser
slpK0p1mmiZQ8EVDJV8jUivd0cwxlrPIztyGhVTRMpepuX2Sb0zDsFpt+9Ie
1LF3EDKkrflNEuyIwSx/p/m9G3SnQ4RqdJOpC/qMbLi7FQS/KAzJaaq1AUkU
0VauQMojGx1DpbU50GCJUkfPcNOsRiWga6Kv3Kl3Te/47J6R2S27PdwS0Rpd
5WAARGxPwUMxsYFOFDryTKibUff751pi2xaBJT8AIL2lt0Zh2AoW4dDJ3xWc
ePvcuYAzdnkGv0XDXa4b3sOukbv4oxbwDKj8kDYg8n8n0tiIyE735g40VHVA
opVwV62VfCjfnIC6wxupHkJS/3SxT4mFJW5KxPUltKWSu6K3JTXCGHv6ycPw
n1PhHPgCQwecghBN+4DLTlvs62crw2NNfuk4HYt86MUGwyd771rgHJ7Jtarb
z7PagLC9wXMhUtwgLvwdVoB+ENYZ8Ds90Cp5CwX65b7eDL+HrcYMc/hWSN2Z
OAfnMgUy0sTVh39uNV7l34MXUTqZEgtT4RYt/+dXN0Sn0z0vw/MJy+wio3sk
a/39jrPVIbeJ+LKJ5iAPgwiM8X7P0IECqyw2LNRhYIfDThgiwV+qBl/PFTqF
gKqKbGpGGBaIOJ1MDIWO96JEc4DXasQ7V2j3WdjG8UYJo8umMldb2Gy/mZC7
Au8zCBy7SuBhysTFHzwGixyrG7lXInJB6Zeeiq+ods3kXmGZ7rnfThxgqHxE
mzAr3RXErm5wSBI/uGzm+JJX/wIbfFFnv2ghVANEC2ZRc4uyz9FYomPwbrCi
u718M0F/wqXouqigbbiDuzDQq9pyqn71jXdg3vuuLR4bZ7WOJapkV3R3MGZw
YcEAVz5sCXpsDSPGtL+EcYbuXrkQwwsPXYHoJq2CL2G2dPlbsG9Od/K7dXai
DfIwfADBr6W6M96wzUcgxwjgoMWbW4KxNg41MClaL1mwW9UKo2jZaltsYTwq
tpWEfDEWBqPM6D5I72UMSneQR1DF5imkuczLW3+r36iP8n477SsNS0faJXMZ
HV35HahdOvfjKRC+U7MSi5ovoYkxx2REG3YBvv/lU8YhXa3nNx8w8k45G/aj
VF0wCfKq1zJTHfhmb/XApTVVcYeeqhJ21FeBHNXwKwoo/5I1rmzOvqqyxTIB
tWo64pszO+CpJyxQYuYCbhIUEjEn2fm+AWkuzkrRvRCaCtxGM4F9TuAqCGCg
yAHdAQfMwJE2aiagwdZcMyIogjudb6cUycWygsCNufCY2rqzeMq1OzFzXH/Y
4nTKNsV4eeckcVfRhncIBsJqALB1TgIB5HSCe3XxOBCrBoM4PRTQXoUf1BAE
14D6oh2vUO4edYidZo3LjEX9obTxeXSfjJ0l2utMbCQ0KKTwCWcc5kvLkif4
coHMXM2ou++Rsa95shw8ta9JCXxp7x3SFFu17yIxpYHdyrQ2rUn3X7i4qvf+
Iu9NgeZeXOfg8FtzvFvrOP0MNDg318T55wRD+UuDxZoXsqWreFyGjL592w1p
DFF73+LUV1Yr4Q3zjfbeVejo5F4MaZKyhjaz5I3/iht8nwtdr8M1MfXwpCf0
bqMcd4VT+nPoYqHMHS1gAW7ndLsd6Bf/ZA0vTrsXXo3fyWzLuM6P3x7v4BBO
NHFL4b1fBd/mjTPhjo5TfH9ILrOluZbmL0f81gyZ/eveAmYk9z51ezZvU+e7
lGm28AhIbwMbVzWqxvs+Dd1pN73X6sCafz2/4MA38YAorpNt2XQqTWFT3+Dx
hT82hb4tK6zf/kO5KpIfKwFI/UqtgSVBbuZSXk+S3wSw8Y8NqA3QXu/gwzQV
8DvYZgUCelnLDVbevxIVbD1ecShgej+Vi8VasFa8LBf/818CYEGuvHcoouWv
1Lyx5dCRtwHpjTIvpqSL+Mw7U/lNkXa9BPuAigQZZ4/+F+TLH7GHiwAA

-->

</rfc>
