<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-prabel-cfrg-suf-hybrid-sigs-00" 
category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="SUF Hybrid Signature">Hybrid Digital Signatures with Strong Unforgeability</title>
    <seriesInfo name="Internet-Draft" value="draft-prabel-cfrg-suf-hybrid-sigs-00"/>
    <author initials="L." surname="Prabel" fullname="Lucas Prabel">
      <organization>Huawei</organization>
      <address>
        <email>lucas.prabel@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Wang" fullname="Guilin Wang">
      <organization>Huawei</organization>
      <address>
        <email>wang.guilin@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Janneck" fullname="Jonas Janneck">
      <organization>Ruhr University Bochum</organization>
      <address>
        <email>jonas.janneck@rub.de</email>
      </address>
    </author>
    <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization>Ericsson AB</organization>
      <address>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="20"/>
    <area>Security</area>
    <workgroup>CFRG</workgroup>
    <keyword>CFRG</keyword>
    <keyword>Migration</keyword>
    <keyword>PQC</keyword>
    <abstract>
      <?line 87?>

<t>This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF-CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security.</t>
      <t>In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure.</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-prabel-cfrg-suf-hybrid/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Cryptography Forum Research Group mailing list (<eref target="mailto:cfrg@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cfrg/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cfrg/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/lucasprabel/draft-cfrg-suf-hybrid-sigs"/>.</t>
    </note>
  </front>
  <middle>
    <?line 93?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>With the emergence of post-quantum (PQ) digital signatures, several groups (including ETSI CYBER and IETF LAMPS, TLS JOSE, SSHM) have explored hybrid constructions combining traditional and PQ algorithms. The main goal is to ensure long-term security during the transition to post-quantum cryptography, acknowledging that traditional algorithms are more mature than post-quantum ones and that the latter still raise uncertainty about their security.</t>
      <t>Current composite hybrid schemes typically provide existential unforgeability under chosen-message attacks (EUF-CMA), but do not ensure strong unforgeability. SUF-CMA extends EUF-CMA by requiring that it be computationally infeasible to produce a new valid signature even for a message-signature pair previously observed. This distinction has practical implications in preventing message replay, transaction duplication, and log poisoning.</t>
      <t>Although several recent algorithms such as EdDSA, ML-DSA, and SLH-DSA claim to achieve SUF-CMA security, some popular traditional schemes (RSA, ECDSA) only achieve EUF-CMA. Therefore, constructing a hybrid digital signature scheme maintaining SUF-CMA when one component does not is of particular interest.</t>
      <t>To address this concern, this document specifies a generic hybrid construction that guarantees SUF-CMA security when the second underlying component (e.g. the PQ scheme) is SUF-CMA. The construction is quite simple and can be applied generically across PQ/T signature combinations. It is originally proposed in <xref target="BH23"/>, though its SUF-CMA is not analyzed in the article.The construction could also be used for a hybrid PQ/PQ security, relying on two post-quantum components.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>This document follows the terminology for post-quantum hybrid schemes defined in <xref target="I-D.draft-ietf-pquip-pqt-hybrid-terminology"/>.</t>
      <t>This section recalls some of this terminology, but also adds other definitions used throughout the whole document:</t>
      <t><em>EUF-CMA</em>:  Existential Unforgeability under Chosen Message Attack.</t>
      <t><em>SUF-CMA</em>:  Strong Unforgeability under Chosen Message Attack.</t>
      <t><em>Post-Quantum Asymmetric Cryptographic Algorithm</em>:  An asymmetric
cryptographic algorithm that is intended to be secure against
attacks using quantum computers as well as classical computers.
They can also be called quantum-resistant or quantum-safe algorithms.</t>
      <t><em>PQ/T Hybrid Digital Signature</em>:  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><em>Post-Quantum Traditional (PQ/T) Hybrid Composite Scheme</em>:  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><em>Component Scheme:</em>  Each cryptographic scheme that makes up a PQ/T hybrid scheme or PQ/T hybrid protocol.</t>
    </section>
    <section anchor="proposed-construction">
      <name>Proposed Construction</name>
      <t>The proposed construction ensures that the second (nested) signature binds the first (nested) signature, making the overall scheme SUF-CMA as long as the (typically PQ) component is SUF-CMA secure. The hybrid signature construction is defined in the following subsections.</t>
      <t>Before signing a message <tt>m</tt>, the hybrid scheme derives a message representative <tt>m'</tt> from <tt>m</tt> to address specific security concerns, and in particular to achieve non-separability, following a similar approach to <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>.</t>
      <section anchor="hybrid-key-generation">
        <name>Hybrid Key Generation</name>
        <artwork><![CDATA[
Generate component keys

- Generate `(pk1, sk1)` for the traditional scheme.
- Generate `(pk2, sk2)` for the post-quantum scheme.
- The hybrid public key is `pk = (pk1 || pk2)`.
]]></artwork>
      </section>
      <section anchor="hybrid-sign">
        <name>Hybrid Sign</name>
        <t>The Hybrid.Sign algorithm consists in signing a message <tt>m'</tt> derived from <tt>m</tt> with the first component, and then signing the concatenation <tt>m' || s1</tt> of the derived message with the first signature with the second component.</t>
        <artwork><![CDATA[
Generate the message representative

- Compute m' = Prefix || Label || len(ctx) || ctx || PH(m)

Generate hybrid signature

- Compute s1 = Sign_1(sk1, m')
- Compute s2 = Sign_2(sk2, m' || s1)
- Output the hybrid signature s = (s1 || s2)
]]></artwork>
        <t>In the computation of the message representative:
- <tt>Prefix</tt> is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235".
- <tt>Label</tt>: a label which is specific to the particular component algorithms being used.
- <tt>len(ctx)</tt>: a single byte representing the length of <tt>ctx</tt>.
- <tt>ctx</tt>: the context bytes.
- <tt>PH(m)</tt>: the hash of the message to be signed.</t>
      </section>
      <section anchor="hybrid-verify">
        <name>Hybrid Verify</name>
        <artwork><![CDATA[
Verify hybrid signature

- Compute m' = Prefix || Label || len(ctx) || ctx || PH(m)
- Parse s as (s1, s2)
- Compute Verify_1(pk1, m', s1)
- Compute Verify_2(pk2, m' || s1, s2)
- Accept if both verifications succeed.
]]></artwork>
      </section>
      <section anchor="related-works">
        <name>Related works</name>
        <t>The hybrid construction in <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> only provides SUF-CMA security if both components is providing SUF-CMA security and one of the components are deterministic. As traditional signatures do not provide any security against quantum attackers, when <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> is used for
PQ/T hybrid scheme, it does not provide SUF-CMA security against quantum attackers. In this document, only the second component needs to be SUF-CMA so that the hybrid scheme achieves SUF-CMA security.</t>
        <t>In contrast to <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, the signing process of the hybrid construction proposed in this document cannot be parallelized. Indeed, computing the hybrid signature <tt>s = (s1 || s2)</tt> requires to compute <tt>s1 = Sign_1(sk1, m')</tt> first in order to compute <tt>s2 = Sign_2(sk2, m' || s1)</tt>.</t>
      </section>
    </section>
    <section anchor="non-black-box-construction">
      <name>Non-black-box Construction</name>
      <t>The proposed construction of this section ensures that the overall scheme is SUF-CMA as long as only one component is SUF-CMA secure. The hybrid signature construction is defined in the following subsections.</t>
      <t>The hybrid can be used for signature schemes that are built from the Fiat-Shamir paradigm as the first component and from any signature scheme as the second compoenent. Hence, they use a canonical identification scheme (ID) underlying a Fiat-Shamir construction and a signature scheme (Sig_2).
This applies to combining EdDSA and any post-quantum signature scheme, for example ML-DSA.</t>
      <t>Before signing a message <tt>m</tt>, the hybrid scheme derives a message representative <tt>m'</tt> from <tt>m</tt> to address specific security concerns, and in particular to achieve non-separability, following a similar approach to <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>.</t>
      <section anchor="hybrid-key-generation-1">
        <name>Hybrid Key Generation</name>
        <artwork><![CDATA[
Generate component keys

- Generate `(pk1, sk1)` for the (traditional) ID scheme.
- Generate `(pk2, sk2)` for the (post-quantum) signature scheme.
- The hybrid public key is `pk = (pk1, pk2)`.
]]></artwork>
      </section>
      <section anchor="hybrid-sign-1">
        <name>Hybrid Sign</name>
        <t>The Hybrid.Sign algorithm consists of applying the Fiat-Shamir paradigm for the first signature component. During the process (after the commitment has been computed), the second component is applied by signing the message and the commitment. The remainder of the Fiat-Shamir signature is computed using the second signature component instead of the message and the commitment as usual.</t>
        <artwork><![CDATA[
Generate the message representative

- Compute m' = Prefix || Label || len(ctx) || ctx || pk's || PH(m)

Generate hybrid signature

- Compute (com, st) = ID.Com(sk1)
- Compute m'' = PH(1 || m' || com)
- Compute s2 = Sig.Sign_2(sk2, m'')
- Compute chl = PH(2 || s2)
- Compute rsp = ID.Rsp(sk1, com, chl, st)
- Output the hybrid signature s = (rsp || s2)
]]></artwork>
        <t>In the computation of the message representative:
- <tt>Prefix</tt> is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235".
- <tt>Label</tt>: a specific label which is specific to the particular component algorithms being used.
- <tt>len(ctx)</tt>: a single byte representing the length of <tt>ctx</tt>.
- <tt>ctx</tt>: the context bytes.
- <tt>pk's</tt>: the concatenation of pk1 and pk2.
- <tt>PH(m)</tt>: the hash of the message to be signed.</t>
      </section>
      <section anchor="hybrid-verify-1">
        <name>Hybrid Verify</name>
        <artwork><![CDATA[
Verify hybrid signature

- Compute m' = Prefix || Label || len(ctx) || ctx || pk's || PH(m)
- Parse s as (rsp || s2)
- Compute chl = PH(2 || s2)
- Compute com = ID.ExtCom(pk1, ch, rsp)
- Compute m'' = PH(1 || m' || com)
- Compute Verify_2(pk2, m'', s2)
- Accept if verification succeeds.
]]></artwork>
      </section>
      <section anchor="security-and-applicability">
        <name>Security and Applicability</name>
        <t>The hybrid is SUF-CMA if one of the underlying signatures is SUF-CMA secure. Additionally, the ID scheme must have unique responses and the second signature component (post-quantum component) must fulfill message-bound security (MBS) <xref target="BUFF"/> and random-message validity (RMV) <xref target="Jan25"/>.</t>
        <t>The first requirement (on the traditional scheme) is fulfilled by EdDSA which is built from an ID scheme with unique responses. The second requirement (on the post-quantum scheme) is fulfilled by any of NIST standards/winners, i.e. ML-DSA, SLH-DSA, Falcon (to be FN-DSA).</t>
      </section>
    </section>
    <section anchor="why-the-binding-hybrid-is-required">
      <name>Why the Binding Hybrid is Required</name>
      <t>Hybrid constructions will have to provide SUF-CMA at the artifact level to ensure single-signature semantics and non-repudiation.  In many real-world deployments the artifact signing use case is central: software releases, firmware images, signed logs, and legal/financial documents are all artifacts that rely on a single, unambiguous signature to prove provenance and integrity. A hybrid design achieves SUF-CMA only if one signature component is cryptographically bound to the other, forming a binding hybrid rather than signing the same message independently.</t>
      <t>Any successful forgery of a binding hybrid must fall into one of two categories:</t>
      <ul spacing="normal">
        <li>
          <t>New second signature on a new input:<br/>
The attacker generates a new traditional signature <tt>s1*</tt> that the legitimate signer never produced. The attacker would then need to forge a valid <tt>s2*</tt> over the concatenation <tt>m' || s1*</tt>.  Producing such an <tt>s2*</tt> is a forgery against the PQC algorithm.</t>
        </li>
        <li>
          <t>Different second-signature on an already-signed input:<br/>
The attacker reuses an existing <tt>(m', s1)</tt> but fabricates a distinct <tt>s2*</tt> for the same <tt>(m' || s1)</tt>, yielding two valid second signatures for one message.</t>
        </li>
      </ul>
      <t>Both outcomes constitute a SUF-CMA forgery against the second component: the first case for a new message, the second for a second valid signature on an existing message.  If the second component is SUF-CMA secure, neither case is computationally feasible, and the combined hybrid inherits SUF-CMA security.</t>
      <section anchor="loss-of-non-repudiation-in-parallel-hybrids-under-crqc">
        <name>Loss of Non-Repudiation in Parallel Hybrids under CRQC</name>
        <t>As described in <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, composite hybrids produce multiple component signatures independently over the same message.<br/>
Once a CRQC can forge the traditional component, an attacker can create an alternate classical signature <tt>s1*</tt> for a message that already has a valid hybrid signature <tt>(s1, s2)</tt>.  Because the PQC signature <tt>s2</tt> remains valid independently of the classical signature, the modified pair <tt>(s1*, s2)</tt> also verifies successfully.</t>
        <t>While authenticity of the PQC component remains intact, non-repudiation cannot be guaranteed: multiple distinct hybrid signatures <tt>(s1, s2)</tt> and <tt>(s1*, s2)</tt> can exist for the same message. Therefore, once the classical algorithm becomes breakable, parallel hybrids no longer provide single-signature semantics, the assurance that each message corresponds to exactly one, unique signature from the signer.</t>
        <t>On the contrary, this document’s hybrid construction, by binding the second signature <tt>s2</tt> to the first signature <tt>s1</tt>, ensures single-signature semantics and preserves non-repudiation.</t>
      </section>
      <section anchor="ecdsa-vs-eddsa-in-hybrid-constructions">
        <name>ECDSA vs EdDSA in Hybrid Constructions</name>
        <t>Even though both ECDSA (secp256r1/secp384r1) and EdDSA (Ed25519/Ed448) become mathematically breakable once a CRQC can derive private keys from public keys, their behaviour in hybrid constructions differs significantly:</t>
        <ul spacing="normal">
          <li>
            <t>ECDSA is randomized and non-deterministic, producing multiple distinct valid signatures for the same message. After CRQCs arrive, an attacker can generate arbitrarily many valid classical signatures, and hence multiple valid hybrids, destroying non-repudiation.</t>
          </li>
          <li>
            <t>Ed25519 and Ed448, in contrast, are deterministic and provide SUF-CMA security in their standard formulations, yielding a unique valid signature per message for a given key. This determinism eliminates malleability and preserves non-repudiation even if a CRQC later compromises the private key. In parallel hybrids, this property avoids ambiguity about which signature is authentic. In binding hybrids, EdDSA’s fixed, deterministic format enables unambiguous inclusion of <tt>s1</tt> in the PQC input (<tt>m' || s1</tt>), simplifying verification and ensuring consistent interpretation across implementations.</t>
          </li>
        </ul>
        <t>Consequently, ECDSA can only be used in a binding hybrid to preserve non-repudiation, and cannot be used in a parallel hybrid, because it is not SUF-CMA and becomes forgeable and repudiable once a CRQC can recover its private key.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <section anchor="security-model-and-motivation">
        <name>Security Model and Motivation</name>
        <t>The hybrid construction described in this document aims to guarantee strong unforgeability of the composite signature whenever the second component is SUF-CMA secure. This is in contrast to the composite construction in <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, where SUF-CMA of the composite generally requires both components to be SUF-CMA. The design proposed here strengthens that property: SUF-CMA of the overall construction depends only on the SUF-CMA of the second component, regardless of the security level of the first one.</t>
      </section>
      <section anchor="suf-cma-security">
        <name>SUF-CMA Security</name>
        <section anchor="why-suf-cma-matters">
          <name>Why SUF-CMA matters</name>
          <t>While EUF-CMA security could be sufficient in several use cases, weaknesses in EUF-only schemes allow "re-signing" the same message, enabling real-world exploits such as replay of messages, double receipts, and log poisoning. Moreover, many current deployed systems implicitly assume that all digital signatures are SUF-secure, and that a single unique signature exists per message.</t>
          <t>For this reason, the construction ensures that if the second component is SUF-CMA, the hybrid automatically resists replay and duplication attacks, aligning with best practices in recent signature standards (EdDSA, ML-DSA, SLH-DSA, etc.).</t>
        </section>
        <section anchor="security-rationale">
          <name>Security Rationale</name>
          <t>Intuitively, an adversary attempting to forge <tt>(m*, s1*, s2*)</tt> must either:</t>
          <ul spacing="normal">
            <li>
              <t>Forge <tt>s2*</tt> on <tt>(m* || s1*)</tt>, which is infeasible if the second scheme is SUF-CMA;</t>
            </li>
          </ul>
          <t>or</t>
          <ul spacing="normal">
            <li>
              <t>Reuse an existing <tt>(m, s1)</tt> pair with a modified <tt>s2</tt>, which again breaks SUF-CMA of the second scheme.</t>
            </li>
          </ul>
          <t>Consequently, if the second component is SUF-CMA secure, the hybrid construction remains SUF-CMA secure even when the first component provides only EUF-CMA security.</t>
          <t>In contrast, if the second scheme were only EUF-CMA, the second attack (re-signing the same message differently) would no longer be excluded, and the hybrid construction would not be SUF-CMA secure.</t>
          <t>This contrasts with classical composite hybrids (e.g. <tt>trad(M) || PQ(M)</tt>)
where the PQ signature does not authenticate the output of the
traditional signature, leaving possible avenues for replay or
signature substitution.</t>
        </section>
      </section>
      <section anchor="non-separability">
        <name>Non-Separability</name>
        <t>The document <xref target="I-D.draft-ietf-pquip-hybrid-signature-spectrums"/> defines both notions of Weak Non-Separability (WNS) and Strong Non-Separability (SNS).</t>
        <t>The hybrid construction in this document achieves WNS because the <tt>Prefix</tt> of the message representative <tt>m'</tt> is an evidence that a verifier may be able to identify, preventing the validation of a component signature which would have been removed from the composite signature.</t>
        <t>However, SNS is not achieved, as <tt>s1</tt> stripped from a composite signature <tt>s = (s1 || s2)</tt> is a valid component signature of the message <tt>m'</tt> and <tt>s2 </tt> is a valid component signature of the message <tt>m' || s1</tt>.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.draft-ietf-pquip-pqt-hybrid-terminology">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="Flo D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Michael P" initials="M." surname="P">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <date day="10" month="January" year="2025"/>
            <abstract>
              <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>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-06"/>
        </reference>
        <reference anchor="I-D.draft-ietf-lamps-pq-composite-sigs">
          <front>
            <title>Composite ML-DSA for use in X.509 Public Key Infrastructure</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="10" month="October" year="2025"/>
            <abstract>
              <t>   This document defines combinations of ML-DSA [FIPS.204] in hybrid
   with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA,
   Ed25519, and Ed448.  These combinations are tailored to meet
   regulatory guidelines.  Composite ML-DSA is applicable in
   applications that uses X.509 or PKIX data structures that accept ML-
   DSA, but where the operator wants extra protection against breaks or
   catastrophic bugs in ML-DSA, and where EUF-CMA-level security is
   acceptable.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-12"/>
        </reference>
        <reference anchor="I-D.draft-ietf-pquip-hybrid-signature-spectrums">
          <front>
            <title>Hybrid signature spectrums</title>
            <author fullname="Nina Bindel" initials="N." surname="Bindel">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Flo D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <date day="20" month="June" year="2025"/>
            <abstract>
              <t>   This document describes classification of design goals and security
   considerations for hybrid digital signature schemes, including proof
   composability, non-separability of the component signatures given a
   hybrid signature, backwards/forwards compatibility, hybrid
   generality, and simultaneous verification.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signature-spectrums-07"/>
        </reference>
        <reference anchor="BH23" 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"/>
          </front>
        </reference>
        <reference anchor="Jan25" target="https://eprint.iacr.org/2025/1844.pdf">
          <front>
            <title>Bird of Prey: Practical Signature Combiners Preserving Strong Unforgeability</title>
            <author initials="J." surname="Janneck" fullname="Jonas Janneck">
              <organization/>
            </author>
            <date year="2025" month="October"/>
          </front>
        </reference>
        <reference anchor="BUFF" target="https://ieeexplore.ieee.org/document/9519420">
          <front>
            <title>BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures</title>
            <author initials="C." surname="Cremers" fullname="Cas Cremers">
              <organization/>
            </author>
            <author initials="S." surname="Düzlü" fullname="Samed Düzlü">
              <organization/>
            </author>
            <author initials="R." surname="Fiedler" fullname="Rune Fiedler">
              <organization/>
            </author>
            <author initials="M." surname="Fischlin" fullname="Marc Fischlin">
              <organization/>
            </author>
            <author initials="C." surname="Janson" fullname="Christian Janson">
              <organization/>
            </author>
            <date year="2021"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1c23IjR3J9x1eUqQcREwC45JAjCd6LeBWpHXI4BGcVCodj
0UAXgF42uqGubnKg3dnwb/jJ/pB98v6Jv8QnM6uqqxvgjGSvI2yHJ2JIoLsu
WVl5OZmVxX6/3+l89tlnnTIpUz1UO5frSZHE6iyZJ2WUqlEyz6KyKrRRT0m5
UKOyyLO5epfN8mKuo0mSJuV6pxNNJoV+RPfRuwtlh/BddzrTqNTzvFgPlSnj
TifOp1m0xGxxEc3K/qqIJjrtT2fFvG+qWX/B/fsmmZuOqSbLxJgkz8r1Cj2u
zu8vlPpMRanJMV2SxXql8SMrd3pqR8dJmRdJlNKXq+MT/MoLfLq7v9jpZNVy
oothJwYxw840z4zOTGWGqiwq3QHxLztRoaOhGulpVWBZnae8eJgXebUaqtOL
u286D3qNR/Gwo/ryAL+vk3kRlaCPvty+Pe086qzC+Eq5nsV6VeZotFqs1UVe
VEu8k8XcaaOjYrpQ31BTPF5GSTpUxIivE13OBuAxnlKToVqU5coM9/aoDT1J
HvXANdqjB3uTIn8yeo+679H82K9qMlRpNY2M8HhPGL6V052oKhd5wYtTSQa+
vB6oW+6GwZSaVWkqu/aaBgxfgYIoS35kNgzVZRU96YRfaFkQUzAQEr5e8OvB
NF/WM30zUN9F2bw1zzcVpCur33xqmic0HMy509ZZvh2ob6Ms09OH1kTf5hkW
FL5rTnVXLQqIPDheGMiFOsmnC95GP/UfaITBH2SEr4tqMoh1PfH9AFsdx+vW
tPcJhCFKtXmKiqBBc+6b/CGJ+PkUUw/VCRYZpXmh+Vmh59zqt1EBXYsebMu8
ykrStqsstp0tnTsPeRaXSfH1nL4Te3aITMeGRab+hI3V1V//RV1HZWkMyTWT
NFTnRTKlB+r4pBOufJENlrbt19q2YcZ3ErISeAfGQayu+mcDkT8S2/7qhypZ
4WfppLDUxTLJ8jSfg/LL70/urs769+d311c3b16/+eb7jQHSaLkyGKCPuVY5
NkazIEM+j69vR/3TN9e3b0ZX9+fPzFzLvlipvlnpKUzB0vjZR7fnp/d3765H
HXVyefCSlFo5O3mMnSm1Ajva5k6Npgu91GaHmrOxUd9W6Vod/OLgJT3yesb/
+iIiNwN1QsYstY+V3ZObJIuab2yHk4G6hOy0mp/AbpWRf1NGMNJlbTv0qkiy
cpBE04LNBpG0d3jwcrCKZx1SgIOjxiJPkiJW+YxEAnsCjZ+WyTT0Cuo0X06S
DHpBbYwuHhN4h2echGfHm2mZwxQTR46e5UhLW+s1bmjrT1jl0d7+l4eHssyT
dxcXzVXiAZHtRUEZ2UE10Wvoi6oaC1ERHpULrWDUNHEHwlf2f6iirKyW9SDh
/oOC/WcXejqAj8B0hWkt9BTLbL6xPUYDdfbXv/yY/vUvrR4j/Ixb72yfu4G6
SHSc6qLV567KdOuV7XJNXcAK2NNWn2v4m/a7ejXYGms3wsUsisSUSZQFr9sb
l2it36/IuA3oI28esEK1hHvf++po/6vDg190Ov1+X0UTU5I0djr3i8Qo10it
ihy7gZ2L1FxnZI2U6HmwueT5oedTsq/Yx6hUEbypfkQvI4Lb2u8K2leo6QID
Z32IhYnmWsHiRdMHo3aBePqn18fdHk3+mMQ6lkFJQoyekvywgcqIvl04ftIg
mAN635ActOgqLMYOSJ1B7kDdU0NZV+xW01hDnMxmpIGzIl+KYFZFQbN5w+i6
RSsMhNWqyVpBbWOS+oDO3ZCebsCyMpdx84yQXMauiSSfHnqGWK2YJYWhhRYR
wBjaRWkwEq0GS/R0EAIjbMkca++UITyUlfjf5AntCbYrU08LnQVz1mzOMzDY
bodR563Og07nKlNRLPTJ4kAUCwyM2xYW96SFFzNCn6GsZXnWn6SQh/4kf68e
I0BQtCKHkszcdsNbQrBjBdGq7QvASlnv20USlf3RIlomhVpFxMD50nLMjbkh
HwpGIiWhxW9eNjgQcGJTnkSBlkkMhQf0B0aA0Meyzk7nOwL5RAuZHXBkumnh
dm/fdiFzEh/Um9XDBI/MQAa+0Iwkm6YVy9j5/ehKnX5/cn7HYsIgnr10T92/
Hqlv34zOe2o0urzuqkX0iMnFCmwVd0Org/Cy7NZCxgPfvsXWINDAIpZGNIdE
SM1zNAArsNUiccwyRhy1SMX4ZfUB42bGS0dj9dMAzvdgOR6y/CnV8Vy6kt6H
NHliAOJBS04/rEotYArb+m+sFlnzkcLIwPLAbKapKqIE7qbCjhSkEuSHJnnF
DSEugWyfPqf9TupqG2RVBPyGbUYfRE4/z/ide+M3ASlxDk0oHYu3GtOBF0f9
HjPGtXbCJBUayKzwnExKOGBeRlVGwlHQDFCpI5NMUjZLK5ZdTTqon6AlacPU
s5UghYucmarxHjSM1Axha5JXhhRnQvhFx1bjYnJXmVjYBZRr5dFPslyl+CDC
COmiMYh5oNsxqNCrNIJ8sCBF1kxXvluP9xlIFxKQwBmiKzbuOAU6qOYLr0iF
noq18VJkKhhNEHMen42Oe+r6dZ9/02ij15f0RU3TKFkSa6xX27CdUNR8Sb5n
VSGQbMirk5DdOxr1/BTjdcWquMHsbrFuFRqs1b1AO8kMOWnbsBB2dG/UGSla
2tiSNy1XnIMQEifsBZmgqAD3mWJ0x9ymBMvuc7Lj+GLEQpOH0sWGvbaWeBsu
2EQD8wqmF1Nos+l2vMexHpO1I13TUgInrwfzAbeCPZJFh45d7FJjXryE5ENT
DcmW+NIp7APEH64yBThzZLMKANjmWPHt2737Bq4hsyhiOVBXwrgCu5A5XRcI
AYn94x8pnvnwgfjEEpeU9WITYXuEbusfpT2thfmf6sEG8Yg201hcIuitjPVx
XhBAJvHBS1+hhWHE76e2dXVMNNhcOKfTPGPVIk0jppzpGQSHvxP00+pBY1Py
AnZk5/rd6J7yPvRb3bzhz3fnb99d3Z2f0efR5fHr1/5Dx7YYXb559/qs/lT3
RAB5fX5zJp3xVDUedXauj7/fEdXbeXN7f/Xm5vj1jjCrARUEPoEzLLawFSUY
FJkOkMm0SCbC4JPT23/71/1DbMzf3V2cHuzvf/Xhg/3y5f4Xh/hCkiezsT7K
V+zLugMJ0awV2IMUYrMitYM7hpkwi/wJ1kuz23/xD8SZfxyqX06mq/3DX9sH
tODGQ8ezxkPm2eaTjc7CxC2Ptkzjudl43uJ0k97j7xvfHd+Dh7/8DUISrfr7
X/7m1512eDDL0zR/MuLj63QDy2tDDlseMyaxc6rT38xNfPgwsFNBzFkpYLqx
G0ZMLSNlgh/1lOIwWWlgwKCoIKmQeUS8RZHKRUH6af08dj2HdXDLGWJPrT1+
MVTqPHDi77Y58VN24ura+qhjduIkGKN6kK2h+6f63xLr3lrWHZv1cqlLMrFB
6hPfjp0bo3mOIa2+YWfaaOj9nYUBhlUn48iKNckh3zm8iCk7Do1UhsxKaEqq
kuIiKMKThmrgN5yjMezE/esB2ZE1m1tnw2jrMJkdqQ/3As4S+oaYuIcmmukQ
bBIbyB4/lz/nRatllZZJv17gR5wkYFm1YtGBkcTEDB4D97jRM4AJT6TyQGkq
BVQq2bFS1NWU8ZoKsiqbjbcC2Y3tvg9a7RIHuo4Fpx5/SkJsOwfserdQXK+1
bv03WoUPVrG1RI9z30ytpQi9EYawx4xoIBKuGn7Moql2EbCJ0Jwy+tRQ4uQN
yllATv1z4cjwBbSWwuCm/FsCWPiX0QPsDwQhEnffMEwkFuFTuPgyn+bpgFzn
rfP3p4GzFqfpoUDDjzdi8TArgLgEPivMB1DuwITR/kaTHlHuwqmc4ayDlx5o
BJErtQpyIxRhfiyGZQT18cRO0rDaTCobf070VRNrp2lbThjG8jgCYB2IHy/H
7GJbTIcpTB4ZSgZon5KfWcmpbvT7fCxBPUZgJG4hqksI1HjS4lUjnp1iiRrm
BhCe8gtGU0pADHIvWAxJ5pKOhOqsCnrCTbXS4OyjPvvMaedvYfO+4YyHyMWf
//znjv0eCjDwFZBWX/lX493Vwz5CiIf97pj9po2XWzHEoN3ngPocBH2aWVPf
KdjZVTVBwMQQD7s5Xj2oXymaXf3pT2pFYw2Y6mBRZG1FxOXBgB4Eak8SAlPO
Udu2/ca+ye7G9f49uYxIK8nUc0akHmozR4YhiVqzP3bGwo3vJm0NX0uzf9FO
Ig5amxUm4ZqSSBt3Kn5OgZBfUY5+lrwnil7TWRx9SHW2Oy3fd+kzftOv28vd
ZbdTT9BWtHBYs49hicu/3981JBjLz7vh6wP3+gCvD+i18IMavanKlQU2G7ps
aK8Nb7U56Mo+X2XeutqEQDsH2Vz+EHOMZcljzv6g5WQNqnQ2zTkv5Qx4yUkH
OrwWufFem44OAPKfYJYXJDQL/R6OeZosJZ+0c/Ty6Ojw1eGXX3z16uCLg1df
vTo8eomfX7w6fwXY/sURnh29PHj5C/w/2iHxHjPjx0OIXcpbYIcOjINNtgaW
YJs/AU4hmgkl8rhuH3lo8lWpXazniZNQtJxDtLD2MTqMuTd9GDr5LfX7kvsa
fsfiYN8uIrNoM91iMrCMSAm08XcQ9dlapFU+f1SUfraE9tVtVBiSFXgQCEuP
RaUeUOaEYK5EMHtW7lrvD8Q6Ocl0oxxPp3oF5zNTE4Bz9UiNfdbHVHhLy3UG
6E6nEQV2VDJgQ9NtCQYJIDYscythvZF2cETU4TFJjLQP0yi+g8SJHqEE/Sge
jbVEIpThmg6A2JsGvM6/24SeSxNG2TqYQtC3x9uCwgGoe5Il2brOxPgEQWcT
z/Qo5efzPm7WzcU9N/NAXbXC755wdutZTIYNNFZ6/Rx5DX+aXt+fEbXJkdME
UpuCgOczvleAhHMUWNqUAIHdnm2SEqZrmhkFRCrEngmbCIpU0uRHylpeIULS
cc/aR6ftG5Z13DStY5t11cwKGxWh0Ra7PrY+ChTlBQWEjQ7PWvqxpHJuGmck
PxWUutDZxdUbILWFLQOs+HMPRv6moDI0AJLI84mxzWNmOYQkXP3p8yCHlttH
XqTx3JGVtB1O2k6hDmjGEuqSzngkk0QkwnmA3jyTRDfVVXmr58bavTrrhonP
qEFng18ckm1Ssws5+f1Bd9Bxh4Fp4sXPnuxwglv6Yz3bT9i91SCuwjFz6lRS
4v8P6/8WsL55iHt19pOx/bMHyT8L5/f+qygfxoOEa+1s4VZ9cjS38XeNt9VZ
fTLoLPduNKOjOetcl0nJppnOiSZaZ84sxt3edt/jxT6mc68wfmgfp9eji4Eq
qO6K03HWeYSLqqnnsxChwebFAjq2LJKKN0odxc+d6geLjMiHV1H63x6HrB4+
Nz83HtkFoZDGsotZrs4GeEzuq9sggCm43GUPKF4KnbZFLYOmP2tENtNFKsMc
uBilfleYlUx/Z1biPZkqdGHSfkroQ0P8H459vMn83xIEkSzWL5tVMJSSID2B
tfqfGjA1VakZOAWi9tPEGzsh4n3+viQFY1M9XfRI7n+mprVDsM83o68w8HJx
l6l9wigMeY5XfMQu3jTEYAHaw5BBZBTgmCDu2QIOj2PnCdO1GHXvD9WyMqUU
rlRZ8kPFaeUV1Zcbbz8/Ynl3t5+AdmXYWZXOqPzD1S9M8orGcavevT4Zdek8
993FBeIrmq7Aj3zpazW4JoKb3l3/jppymac9sXJuz8YAbN938+yZpB6fYluC
xHMJTPPqG+BXgN6aQZzLavNG/JllzDYCtmQINykgeIi9vLka3Ss6pImjIjZ7
gFAZh6LJAHvnyiRsiURPXUQpZgW+YU28uKGnXQpTEKd8t5B48cTWx116CboT
GuNO53JbWdITbRNLgdSlNIJXG62QOZtFUzqleISy1vVIYqyC6hQDPw9zNRUR
IqQIG1bFCevBQFGku6S1FzpK+095kcZAsKs0Xy85zG9M5vAF4XsuWiV0oClg
TYcIeWflEwUfhaajEyrkgkws+RFs/Zwru9hWUcGKhbSpnkfpHiKhKJvSeaML
TiW/QPGYm9xGN3ToTyf+ziz3IA4RwP68yivTrDQk1mn5ScNri6FLPedwWx37
ChNtGPi1I3OO9qyab4U6pnngwkcOolfW7fBpLMcVS8HirljSzgwYsmD0FzWT
v3wS5BQvuJuSUpbgmAIzsl/GQIIVH7AWLLwb44vmExux7tzbqydESHKTBvES
nf6qG/20aVqYzVQOlWQwskOlOopVzeVJbKVjKaWLaLc1+0M5gBfjoBhNz9Fm
GZXWdRXoCtvsKrDiQXOOJ64K4fQ4JVqIs7xiTClVWmNzgOEpfP9Y3vzFGLJ+
y1NIkE31T5ntzAd8jo8uKyR1N6fNI0t1xjWyXAvE7Oo32UXhAzQpXvetqD/H
ukJXYtalZo5oGu/a1OKYz/Rn0YTqdIS7rojMEuxiDZYT6udSJD21TnQq9bjY
ZVvH1tpYw/1JGKyIUZRLacG8KiHd2ohBSkryrJFXh20MagckwzCnQBZCKnhI
OOxcjUBG3tov7aI74adnj6MVJmv2bDDU9LY9TJywhnlr1SoCdCWAvTBAmXBi
xnn8DP3DsqYgXwfY8DqX9Btlpe5qw0o499Zm1azlN6764e7tKZSYMkBB4c72
XF+79NL4OkU+/qY8Rb38EHeEJqPWjdCsgI+dN2wVmSLOLolitX1246SqlmDq
MIWsk4yQ2COMzTg54Esj2iagUUBpk1WiLRzwOoXezDS6nDzp8ImeRuR/nHqG
kxyMbVhr7FAtPtgk9iaBIpRLBDQzCqW5opNmfSHTSkGHAEhtAuPL9vi7RUKl
dhXZKDhagkh2JqKv3h9HGlUtTsHMli8O8rG+cjAe1hvtTcBmeXvNIBbjkPKp
U6GmzfBCEJRfUq6pxaA6FzLRYhkm2K+HiDXGZY29bGY5J0rFljNqeR6NCMcx
T1VEMi+kQVN2ysnHNC8E4klyHUHjtJTsa89BwHpcn+oUl4JdeeMCXYInxbpV
yfnv//TPZnuB/vYbDS0ps+69neqBmMMCu9TyJ6DYSu458SFFE5SxYeGiWfVo
S3TJRPhymAAsdjrnj1xJytWXfLYjHXdB+Org6FWxv0efXn55WOx3eV4Zb/c8
Pjg62v9q7zw+PPyya/eXisoBj6PSgRm32yIcgamQLCcWkTyS0lMeUDahTsLJ
HkOTJhpoNskrri3cWonvbp4wBqIgjfSVgYmsBjsn0QidUHgg2zh+6lnTyK5i
Q2davsU8ow3HnIyjRRIApRVu2jwHetBgkpBsJWAUQ2iZZIt5sWB3wdcgPHGh
tUMLuIOyyDmC3BQIMEL2y24h9qxH3HTHRb3N8zgrZM+cfcmxA6X6bKzDILVK
5VwygBGRU7a2e16BH05XxbLPE5JF7LyrfPfkLJVOkyUVFfNlHFiN8A7cs5og
dffJzAkeHY1KAgeSlhhtbCrVyyAf3LXtklV9OhfSBU35mJO1kqgh8fcfJPhs
ZD69Tedxm9gaw7ImsSWZJe/pxKzJf7mzCnNACmQacQrfaDE27UNWwx0Dkcdg
yKh265KPbk/quZMZS0cjkUH8Y4MjtWecsJY0rC0Sts2k0purwpeS25PzJbIm
CEfZQdpKfZZyjn3caROVBLdDCw6wZN/a29ZzdefWndVjtLamR2aHvXlSunJx
H+hiCOd0bA2pLWi3M22zSgU6ENghvBaKBcXjPsFDS4ZOyMmGaSZ/rvNYyxWg
67yk/v5YceuFuRDBtcq1kyW7Le/Kn7kTGB6sS9VgXbgD2dMeun0S7Fql4yrX
xjFyc/yfUkbQs2WUPhBuE2mvuKXr+tC3XVfQOA+XmM7G2fUdRC23eziFCiEW
EOD0dNie3p3QtrZgxbd/7MksN2z1a7OObg7MYfHS4OTc20XJp9in4t/RSVyy
G9f/XQf6gxec53FvlnzRyjhM2L4waK84UNK2mkGFE9FUf0/H5VWo9AGONwOB
DOZ5IF6hO+mN6HhP7RQCL6CWOxverCeWh1Q2yO3wjThSD3cDSG4Y0YptP3JF
eUXaRdeGklVptt0ygn4UmnakJ77PXRWV3BE216xhiJbGXnJKCLoR2lt64J9u
ufvHXoyY6eI3f43Np+E3oB+jWxO6I+zWBbt3gg0I8OTeZUv0GwUAyScjysZJ
L/xCXoMkKev2nCSSgyta7o4b1pLaDA9nMSdw9+4umGyyvaUV4EWXhiS01rin
5ROQupwOugMRRG/E7mx8q+m4p4SLg18m605IJqa/PRFRFA9JXa7kHMOlVMa7
S4obJHh4geiB80cSQg/pxOBCmknGJeP2Nr1CqQefvg2u1jU5u1Fc8fedTl7Q
yHeaiwaa6RCbDeFwjJkW1TEa4XA3JWckBKyaZ7TfHRi3HN6nN96nEp4rsHFh
Xes67ccvFvsSLdbq7ReLa2y3lYlPmnMkdfdGZkWkTu3WFmIzsRi7XFa67to8
Wx3CTUiz6N4tARuXHNm2ftexbNQ/uTvC9/Y2Ha/E/u2f5uWJZn5D7ryNKf+w
e80nT7dv8WHc7YhLEpAUKIkv8/JgzZ0h53I2KnLQ2Zqb7FGVP/+pCZAhAhvx
392RAMHZxqITKGU1kdSYj9Qo9TMKqi8EL3gkUF/08X8G5MMHW/5j3SbI5zAI
pH4HGd4YUe1+dzOS6M3eq9lsMUKLwUcLBlsAxWW7MbSHYcQ2f9r70XNhqWJJ
JINJouyD+MglSmCPI8aQkb1ja8uA1r3wpitNwaGFPwaNtuW0rKaLsPHhCNdH
QPlyX2X9DJACVy7zJ82+Clzy9xKFATFfcGMMTkfYq5UbLdoKyjaq3pI6cbWN
7BYTmWucozEH6j/R2UYEDGivjm+ON8Bs854apdWg0twycjVl/wF3pRJtq0sA
AA==

-->

</rfc>
