<?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.43 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-prabel-cfrg-suf-hybrid-sigs-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.35.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-03"/>
    <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>University of Waterloo</organization>
      <address>
        <email>jjanneck@uwaterloo.ca</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="2026" month="October" day="28"/>
    <area>Security</area>
    <workgroup>CFRG</workgroup>
    <keyword>CFRG</keyword>
    <keyword>Migration</keyword>
    <keyword>PQC</keyword>
    <abstract>
      <?line 90?>

<t>This document proposes two PQ/T (Post-Quantum/Traditional) hybrid signature constructions that achieve strong unforgeability under chosen-message attacks (SUF-CMA). The first, a black-box construction, achieves SUF-CMA security provided that the second component (typically the post-quantum one) is SUF-CMA secure; it 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>The second, a non-black-box construction, requires the first (traditional) component to be built from the Fiat-Shamir paradigm, and binds the post-quantum signature directly into that component's challenge computation rather than treating it as an opaque sign/verify oracle. This variant is SUF-CMA secure as long as at least one of the two components 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-sigs/"/>.
      </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 96?>

<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 (e.g. 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 two hybrid constructions that achieve SUF-CMA security. The first is a generic (black-box) construction that guarantees SUF-CMA security when the second underlying component (e.g. the PQ scheme) is SUF-CMA. It is quite simple, can be applied generically across PQ/T signature combinations, and was originally proposed in <xref target="BH23"/>, though its SUF-CMA is not analyzed in the article. It could also be used for a hybrid PQ/PQ security, relying on two post-quantum components. The second is a non-black-box construction, for a first component built from the Fiat-Shamir paradigm (e.g. EdDSA), which guarantees SUF-CMA security as long as at least one of the two components is SUF-CMA.</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="RFC9794"/>.</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="black-box">
      <name>Black-box Construction</name>
      <t>The proposed construction ensures that the second (nesting) 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 of 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:</t>
        <ul spacing="normal">
          <li>
            <t><tt>Prefix</tt> is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235".</t>
          </li>
          <li>
            <t><tt>Label</tt>: a label which is specific to the particular component algorithms being used.</t>
          </li>
          <li>
            <t><tt>len(ctx)</tt>: a single byte representing the length of <tt>ctx</tt>.</t>
          </li>
          <li>
            <t><tt>ctx</tt>: the context bytes.</t>
          </li>
          <li>
            <t><tt>PH(m)</tt>: the hash of the message to be signed.</t>
          </li>
        </ul>
      </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-work">
        <name>Related Work</name>
        <t>The hybrid construction in <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> only provides SUF-CMA security if both components are providing SUF-CMA security and one of them is deterministic. Indeed, requiring at least one deterministic component prevents a "mix-and-match" forgery and is therefore necessary to claim SUF-CMA security. In particular, 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 computing <tt>s1 = Sign_1(sk1, m')</tt> first in order to compute <tt>s2 = Sign_2(sk2, m' || s1)</tt>.</t>
        <t>Another related construction is <xref target="I-D.draft-devevey-cfrg-silithium"/>, which combines EC-Schnorr and ML-DSA. Although presented as a standalone scheme rather than a generic framework, its signing process follows a pattern similar to the non-black-box construction described in this document: the post-quantum (ML-DSA) signature is computed over a commitment produced during the traditional (EC-Schnorr) signing process, and the traditional challenge is then derived from that post-quantum signature. This binding mechanism illustrates a concrete instantiation of the non-black-box approach.</t>
      </section>
    </section>
    <section anchor="non-black-box">
      <name>Non-black-box Construction</name>
      <t>The proposed construction of this section ensures that the overall scheme is SUF-CMA as long as at least 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 component. 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>
        <t>We use the following notations:</t>
        <ul spacing="normal">
          <li>
            <t><tt>com</tt>: the commitment output by <tt>ID.Com</tt>.</t>
          </li>
          <li>
            <t><tt>st</tt>: the internal state output by <tt>ID.Com(sk1)</tt> alongside <tt>com</tt>.</t>
          </li>
          <li>
            <t><tt>chl</tt>: the challenge.</t>
          </li>
          <li>
            <t><tt>rsp</tt>: the response of the identification scheme.</t>
          </li>
        </ul>
        <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:</t>
        <ul spacing="normal">
          <li>
            <t><tt>Prefix</tt> is the byte encoding of the string "SUFHybridSignature2025", which in hexadecimal is "5355464879627269645369676E617475726532303235".</t>
          </li>
          <li>
            <t><tt>Label</tt>: a label which is specific to the particular component algorithms being used.</t>
          </li>
          <li>
            <t><tt>len(ctx)</tt>: a single byte representing the length of <tt>ctx</tt>.</t>
          </li>
          <li>
            <t><tt>ctx</tt>: the context bytes.</t>
          </li>
          <li>
            <t><tt>pk's</tt>: the concatenation of pk1 and pk2.</t>
          </li>
          <li>
            <t><tt>PH(m)</tt>: the hash of the message to be signed.</t>
          </li>
        </ul>
      </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)
- Reject if rsp is out of bounds (for EdDSA: S >= L)
- Compute chl = PH(2 || s2)
- Compute com = ID.ExtCom(pk1, chl, rsp)
- Compute m'' = PH(1 || m' || com)
- Compute Verify_2(pk2, m'', s2)
- Accept if verification succeeds.
]]></artwork>
      </section>
      <section anchor="nbb-security">
        <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 signatures (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>Some deployments additionally require SUF-CMA, i.e. that no party other than the signer can produce a new valid signature, even for an already-signed message. This matters for example when signature values are themselves used as identifiers, deduplication keys, or inputs to other hashes (e.g. transaction identifiers, signed log entries). While a parallel hybrid is SUF-CMA only if both components are SUF-CMA and one is deterministic, it loses SUF-CMA in particular once a CRQC breaks the traditional component. Therefore, binding the components allows SUF-CMA to rely on a single component.</t>
      <t>For the black-box construction, any successful forgery falls into one of two categories:</t>
      <ul spacing="normal">
        <li>
          <t>New signature on a new input:<br/>
The attacker produces a hybrid signature on an input <tt>m' || s1*</tt> that the legitimate signer never signed with the second component. The attacker would then need to forge a valid <tt>s2*</tt> over this new input. 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>
      <t>For the non-black-box construction, the binding works in both directions: the second signature <tt>s2</tt> is computed over the commitment <tt>com</tt> (and hence over the message), and the challenge <tt>chl</tt>, and thus the response <tt>rsp</tt>, is derived from <tt>s2</tt>. Neither component can therefore be modified independently of the other.</t>
      <section anchor="ecdsa-vs-eddsa-in-hybrid-constructions">
        <name>ECDSA vs EdDSA in Hybrid Constructions</name>
        <t>Neither ECDSA (secp256r1/secp384r1) nor EdDSA (Ed25519/Ed448) is quantum-safe. However, they differ against classical adversaries:</t>
        <ul spacing="normal">
          <li>
            <t>ECDSA is not SUF-CMA, even classically and even with deterministic nonces <xref target="RFC6979"/>: given a valid signature <tt>(r, s)</tt>, anyone can compute <tt>(r, n - s)</tt>, and this is also a valid signature on the same message.</t>
          </li>
          <li>
            <t>EdDSA is SUF-CMA against classical adversaries, provided that verification enforces the checks of <xref target="RFC8032"/>, in particular <tt>0 &lt;= S &lt; L</tt>. Its signing is deterministic, but this is a property of the signing algorithm only, and the verifier cannot check it. Moreover, anyone holding the private key can produce many distinct valid signatures on the same message. Once a CRQC recovers an EdDSA private key, EdDSA therefore loses SUF-CMA, just like ECDSA.</t>
          </li>
        </ul>
        <t>This has the following consequences for hybrid constructions:</t>
        <ul spacing="normal">
          <li>
            <t>A parallel hybrid with an ECDSA component is never SUF-CMA. A parallel hybrid with an EdDSA component can be SUF-CMA against classical adversaries, but not against a quantum adversary.</t>
          </li>
          <li>
            <t>The black-box construction of this document achieves SUF-CMA with either ECDSA or EdDSA as the first component, as long as the PQ component is SUF-CMA.</t>
          </li>
          <li>
            <t>The non-black-box construction applies to EdDSA, which is built from an identification scheme with unique responses, but not to ECDSA, which does not follow the Fiat-Shamir paradigm. The hybrid verification <bcp14>MUST</bcp14> enforce <tt>0 &lt;= S &lt; L</tt> on the response. Otherwise, replacing <tt>S</tt> with <tt>S + L</tt> yields the same commitment and the same <tt>s2</tt>, so anyone can derive a second valid hybrid signature on the same message, and the construction is not SUF-CMA.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <section anchor="security-model-and-motivation">
        <name>Security Model and Motivation</name>
        <t>Both constructions are EUF-CMA as long as at least one component is EUF-CMA secure (for the non-black-box construction, under the additional requirements of <xref target="nbb-security"/>). This document additionally targets SUF-CMA, which constructions such as <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> do not guarantee in general.</t>
        <t>The black-box construction (<xref target="black-box"/>) aims to guarantee strong unforgeability of the hybrid signature whenever the second component is SUF-CMA secure. This is in contrast to <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 non-black-box construction (<xref target="non-black-box"/>) strengthens this further: because the Fiat-Shamir response is bound to the second signature with <tt>chl = PH(2 || s2)</tt>, SUF-CMA of the overall construction holds if either component is SUF-CMA secure, provided that the ID scheme has unique responses (enforced by verification) and the second signature scheme is MBS and RMV.</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 signature malleability (producing a new valid signature on an already-signed message without the private key), 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.</t>
          <t>For this reason, the construction ensures that if the second component is SUF-CMA, the hybrid resists such attacks, like recent standardized signature schemes (EdDSA, ML-DSA, etc.).</t>
        </section>
        <section anchor="security-rationale">
          <name>Security Rationale</name>
          <t>For the black-box construction, an adversary attempting to forge <tt>(m*, s1*, s2*)</tt> must either:</t>
          <ul spacing="normal">
            <li>
              <t>Produce <tt>s2*</tt> on an input <tt>m'* || s1*</tt> that was never signed by the second component (because the message or <tt>s1*</tt> is new), which is infeasible if the second scheme is EUF-CMA;</t>
            </li>
          </ul>
          <t>or</t>
          <ul spacing="normal">
            <li>
              <t>Reuse an existing <tt>(m', s1)</tt> pair with a different <tt>s2*</tt>, which is infeasible if the second scheme is SUF-CMA.</t>
            </li>
          </ul>
          <t>Consequently, if the second component is SUF-CMA, the black-box construction is SUF-CMA regardless of the security of the first component, including when the latter only provides EUF-CMA security or is fully broken by a CRQC.</t>
          <t>In contrast, if the second scheme is not SUF-CMA, the second attack is no longer excluded, and the construction is not SUF-CMA in general.</t>
          <t>For the non-black-box construction, the same reasoning applies to <tt>s2</tt>. In addition, reusing an existing <tt>s2</tt> with a different response <tt>rsp*</tt> is excluded, because <tt>s2</tt> determines the challenge, and the ID scheme has unique responses (enforced by verification). The construction is therefore SUF-CMA as long as the PQ component is SUF-CMA. It is also SUF-CMA if the traditional component is SUF-CMA, under the requirements of <xref target="nbb-security"/>.</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><xref target="RFC9955"/> defines both notions of Weak Non-Separability (WNS) and Strong Non-Separability (SNS).</t>
        <t>The black-box hybrid construction in this document achieves WNS because the <tt>Prefix</tt> of the message representative <tt>m'</tt> is evidence that a verifier may be able to identify, preventing the validation of a component signature which would have been removed from the hybrid signature.</t>
        <t>However, SNS is not achieved, as <tt>s1</tt> stripped from a hybrid 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>
        <t>For the non-black-box construction, the two components behave differently. The PQ signature <tt>s2</tt> can be stripped from the hybrid signature and is a valid component signature on <tt>m'' = PH(1 || m' || com)</tt>, so SNS is not achieved for the PQ component. However, presenting <tt>s2</tt> as a signature on a chosen message would require inverting <tt>PH</tt>. Conversely, the traditional component cannot be separated: <tt>rsp</tt> alone is not an EdDSA signature, and turning <tt>(com, rsp)</tt> into a valid EdDSA signature on some message <tt>M</tt> would require the EdDSA challenge <tt>H(com || pk1 || M)</tt> to match <tt>chl = PH(2 || s2)</tt>, which is infeasible for a secure hash function. Informally, the non-black-box construction therefore achieves SNS for the traditional component, but not for the PQ component.</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="RFC6979">
          <front>
            <title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
            <author fullname="T. Pornin" initials="T." surname="Pornin"/>
            <date month="August" year="2013"/>
            <abstract>
              <t>This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6979"/>
          <seriesInfo name="DOI" value="10.17487/RFC6979"/>
        </reference>
        <reference anchor="RFC8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8032"/>
          <seriesInfo name="DOI" value="10.17487/RFC8032"/>
        </reference>
        <reference anchor="RFC9794">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
            <author fullname="M. Parsons" initials="M." surname="Parsons"/>
            <author fullname="B. Hale" initials="B." surname="Hale"/>
            <date month="June" 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="RFC" value="9794"/>
          <seriesInfo name="DOI" value="10.17487/RFC9794"/>
        </reference>
        <reference anchor="I-D.draft-ietf-lamps-pq-composite-sigs">
          <front>
            <title>Composite Module-Lattice-Based Digital Signature Algorithm (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="21" month="April" year="2026"/>
            <abstract>
              <t>   This document defines combinations of US NIST Module-Lattice-Based
   Digital Signature Algorithm (ML-DSA) in hybrid with traditional
   algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448.
   These combinations are tailored to meet regulatory guidelines in
   certain regions.  Composite ML-DSA is applicable in applications that
   use 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 existential unforgeability (EUF-CMA) level
   security is acceptable.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-19"/>
        </reference>
        <reference anchor="RFC9955">
          <front>
            <title>Hybrid Signature Spectrums</title>
            <author fullname="N. Bindel" initials="N." surname="Bindel"/>
            <author fullname="B. Hale" initials="B." surname="Hale"/>
            <author fullname="D. Connolly" initials="D." surname="Connolly"/>
            <author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
            <date month="July" year="2026"/>
            <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 and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9955"/>
          <seriesInfo name="DOI" value="10.17487/RFC9955"/>
        </reference>
        <reference anchor="I-D.draft-devevey-cfrg-silithium">
          <front>
            <title>Silithium - A Compact, Efficient and Non-separable Hybrid Signature</title>
            <author fullname="Julien Devevey" initials="J." surname="Devevey">
              <organization>ANSSI</organization>
            </author>
            <author fullname="Maxime Roméas" initials="M." surname="Roméas">
              <organization>ANSSI</organization>
            </author>
            <author fullname="Morgane Guerreau" initials="M." surname="Guerreau">
              <organization>PQShield</organization>
            </author>
            <date day="6" month="July" year="2026"/>
            <abstract>
              <t>   This document defines Silithium, an augmentation of US NIST Module-
   Lattice-based Digital Signing Algorithm (ML-DSA) [FIPS.204] with
   traditional elliptic-curve operations, that uses ML-DSA in a black-
   box manner.  This results in a digital signature scheme with hybrid
   security, requiring solving hard lattice problems as well as discrete
   logarithm in order to forge a signature.  This augmentation is
   designed to satisfy regulatory guidelines in certain regions.
   Silithium is strongly unforgeable as long as ML-DSA is.  Morevoer,
   Silithium can be used in a backward compatible and interopable manner
   without hindering security.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-devevey-cfrg-silithium-00"/>
        </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>
    <?line 367?>

<section anchor="comparison-of-security-properties">
      <name>Comparison of Security Properties</name>
      <t>This appendix compares the security properties of the two constructions of this document with those of <xref target="I-D.draft-devevey-cfrg-silithium"/>:</t>
      <ul spacing="normal">
        <li>
          <t>Black-box construction (<xref target="black-box"/>): <tt>s1 = Sign_1(sk1, m')</tt> and <tt>s2 = Sign_2(sk2, m' || s1)</tt>.</t>
        </li>
        <li>
          <t>Non-black-box construction (<xref target="non-black-box"/>): the traditional component follows the Fiat-Shamir paradigm (e.g. EdDSA), <tt>rsp = ID.Rsp(sk1, com, chl, st)</tt> and <tt>s2 = Sig.Sign_2(sk2, m'')</tt>.</t>
        </li>
        <li>
          <t>Silithium, as specified in <xref target="I-D.draft-devevey-cfrg-silithium"/>: EC-Schnorr combined with ML-DSA, with ML-DSA signing the message with the context string <tt>R || P</tt>, and the EC-Schnorr challenge <tt>c</tt> extracted from the ML-DSA signature.</t>
        </li>
      </ul>
      <t>In the table below, "T" refers to the traditional component and "PQ" to the post-quantum component. A cell "PQ" (resp. "T") means that the property holds if the PQ (resp. traditional) component provides it. "PQ or T" means that the property holds as long as at least one component provides it. "PQ and T" means that both components must provide it. Against a quantum adversary, the traditional component provides no security, so a cell "PQ or T" reduces to "PQ". When a security property relies on several properties of a component, these properties are given in parentheses.</t>
      <section anchor="summary">
        <name>Summary</name>
        <table>
          <thead>
            <tr>
              <th align="left">Property</th>
              <th align="left">Black-box</th>
              <th align="left">Non-black-box</th>
              <th align="left">Silithium</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Specification</td>
              <td align="left">
                <xref target="black-box"/></td>
              <td align="left">
                <xref target="non-black-box"/></td>
              <td align="left">
                <xref target="I-D.draft-devevey-cfrg-silithium"/></td>
            </tr>
            <tr>
              <td align="left">EUF-CMA</td>
              <td align="left">PQ or T</td>
              <td align="left">PQ or T</td>
              <td align="left">PQ or T</td>
            </tr>
            <tr>
              <td align="left">SUF-CMA</td>
              <td align="left">PQ</td>
              <td align="left">PQ or T</td>
              <td align="left">PQ</td>
            </tr>
            <tr>
              <td align="left">SNS of the T component</td>
              <td align="left">No</td>
              <td align="left">Yes</td>
              <td align="left">Yes</td>
            </tr>
            <tr>
              <td align="left">SNS of the PQ component</td>
              <td align="left">No</td>
              <td align="left">No</td>
              <td align="left">No</td>
            </tr>
            <tr>
              <td align="left">Exclusive Ownership (EO)</td>
              <td align="left">PQ* and T</td>
              <td align="left">PQ* (EO and MBS)</td>
              <td align="left">PQ* (EO and MBS)</td>
            </tr>
            <tr>
              <td align="left">Message-Bound Signatures (MBS)</td>
              <td align="left">PQ* or T</td>
              <td align="left">PQ*</td>
              <td align="left">PQ*</td>
            </tr>
            <tr>
              <td align="left">Traditional component</td>
              <td align="left">Any</td>
              <td align="left">Fiat-Shamir with unique responses (e.g. EdDSA)</td>
              <td align="left">EC-Schnorr</td>
            </tr>
            <tr>
              <td align="left">Components used as black boxes</td>
              <td align="left">T and PQ</td>
              <td align="left">PQ</td>
              <td align="left">None</td>
            </tr>
            <tr>
              <td align="left">Signature size</td>
              <td align="left">size(s1) + size(s2)</td>
              <td align="left">size(rsp) + size(s2)</td>
              <td align="left">size(rsp) + size(s2)</td>
            </tr>
          </tbody>
        </table>
        <t>* This requirement on the PQ component is met statistically by ML-DSA, independently of the PQ hardness assumption.</t>
      </section>
      <section anchor="existential-unforgeability-euf-cma">
        <name>Existential Unforgeability (EUF-CMA)</name>
        <t>Each construction is EUF-CMA as long as at least one component is EUF-CMA.</t>
        <t>If the PQ component is EUF-CMA, in all three constructions, the PQ signature of a forgery on a new message is computed over an input that depends on this message (<tt>m' || s1</tt> for the black-box construction, <tt>m''</tt> for the non-black-box construction, and the message itself for Silithium). This input was never signed, so the PQ signature is a forgery against the PQ component.</t>
        <t>If the traditional component is EUF-CMA, in the black-box construction, <tt>s1</tt> is a traditional signature on <tt>m'</tt>, which was never signed, so <tt>s1</tt> is a forgery against the traditional component. In the non-black-box construction and Silithium, the traditional component is a response to a challenge derived from the PQ signature, which is bound to the message and the commitment. This challenge plays the same role as in a regular Fiat-Shamir signature, so the traditional part is a forgery against the traditional component.</t>
      </section>
      <section anchor="strong-unforgeability-suf-cma">
        <name>Strong Unforgeability (SUF-CMA)</name>
        <t>If the PQ component is SUF-CMA: in all three constructions, a new hybrid signature on a message either contains a new PQ signature, or reuses an existing one on the same input. In the first case, it is a forgery against the PQ component. In the second case, nothing else can change. In the black-box construction, the PQ signed input <tt>m' || s1</tt> fixes <tt>s1</tt>. In the non-black-box construction and Silithium, the PQ signature fixes the challenge, and the PQ input fixes the commitment. The response is then unique, provided that verification enforces the range check (0 &lt;= S &lt; L for EdDSA, 0 &lt;= x &lt; q for Silithium). All three constructions are therefore SUF-CMA whenever the PQ component is.</t>
        <t>If the traditional component is SUF-CMA: only the non-black-box construction remains SUF-CMA. A new signature either has a new PQ input <tt>m''</tt>, a new <tt>s2</tt> on an existing input, or the same <tt>s2</tt> with a different response. In the first two cases, the adversary must produce a valid response to a new challenge, which is a forgery against the traditional component. The last case is impossible, since the response is unique for a given commitment and challenge. In the black-box construction, a new <tt>s2</tt> on an existing input directly gives a new hybrid signature, since nothing depends on <tt>s2</tt>. In Silithium, a new ML-DSA signature on the same message and context that keeps the same challenge <tt>c</tt> can be combined with the existing <tt>x</tt>.</t>
      </section>
      <section anchor="non-separability-1">
        <name>Non-Separability</name>
        <t>A hybrid construction provides Strong Non-Separability (SNS) for a component if an adversary, given hybrid signatures, cannot extract a signature that is valid for that component scheme, on any message. SNS is considered here with respect to the component schemes as they are specified and used on their own.</t>
        <t>A component used as a black box cannot provide SNS, as the verifier has to extract its signature to verify it, so an adversary can do the same. None of the three constructions therefore provides SNS for the PQ component, and the black-box construction does not provide it for the traditional component either.</t>
        <t>In the non-black-box construction, the traditional component provides SNS: <tt>(com, rsp)</tt> is only a valid EdDSA signature on a message <tt>M</tt> if the EdDSA challenge <tt>H(com || pk1 || M)</tt> equals <tt>chl</tt>, which requires breaking the preimage resistance of the hash function. A similar argument applies to the traditional component of Silithium, under an additional assumption on how the challenge is computed from the ML-DSA signature.</t>
      </section>
      <section anchor="exclusive-ownership-eo">
        <name>Exclusive Ownership (EO)</name>
        <t><em>Definition:</em> an adversary cannot produce a signature that is valid under two different public keys, possibly for different messages <xref target="BUFF"/>.</t>
        <t>In the black-box construction, <tt>m'</tt> does not include the public keys. Therefore, an adversary can keep <tt>pk2</tt> and replace <tt>pk1</tt> with a key <tt>pk1*</tt> under which <tt>s1</tt> also verifies on <tt>m'</tt>. Since the input <tt>m' || s1</tt> and the key <tt>pk2</tt> are unchanged, <tt>s2</tt> still verifies. EO therefore requires the traditional component to provide EO. Symmetrically, replacing <tt>pk2</tt> requires the PQ component to provide EO.</t>
        <t>In the non-black-box construction, <tt>m'</tt> includes <tt>pk1 || pk2</tt>. If a hybrid signature is valid under two public keys with different PQ keys, <tt>s2</tt> is valid under two different PQ keys, which breaks EO of the PQ component. If only the traditional keys differ, <tt>m'</tt>, and hence <tt>m''</tt>, differ, so <tt>s2</tt> is valid for two different inputs under the same PQ key, which breaks MBS of the PQ component. EO therefore relies on the EO and MBS of the PQ component.</t>
        <t>In Silithium, the same reasoning applies. If the ML-DSA public keys differ, the ML-DSA signature is valid under two different keys, which breaks EO of ML-DSA. If only the EC-Schnorr public keys <tt>P</tt> and <tt>P*</tt> differ, the contexts <tt>R || P</tt> and <tt>R* || P*</tt> differ, so the ML-DSA signature is valid for two different contexts under the same key, which breaks MBS of ML-DSA. EO therefore relies on the EO and MBS of the PQ component.</t>
      </section>
      <section anchor="message-bound-signatures-mbs">
        <name>Message-Bound Signatures (MBS)</name>
        <t><em>Definition:</em> an adversary cannot produce a signature that is valid for two different messages under the same public key <xref target="BUFF"/>.</t>
        <t>In the black-box construction, <tt>m'</tt> is part of the input of both components. A hybrid signature valid for two messages would give an <tt>s1</tt> valid for two different inputs <tt>m'_1</tt> and <tt>m'_2</tt>, and an <tt>s2</tt> valid for two different inputs <tt>m'_1 || s1</tt> and <tt>m'_2 || s1</tt>. The first breaks MBS of the traditional component, and the second breaks MBS of the PQ component. MBS therefore holds if either component provides it, assuming <tt>PH</tt> is collision-resistant.</t>
        <t>In the non-black-box construction, a hybrid signature <tt>(rsp, s2)</tt> valid for two messages gives the same challenge <tt>chl</tt> and the same commitment <tt>com</tt> for both messages, but two different inputs <tt>m''_1</tt> and <tt>m''_2</tt>. Thus <tt>s2</tt> is valid for two different inputs, which breaks MBS of the PQ component. MBS therefore relies on the PQ component <xref target="Jan25"/>. The traditional component does not help here: its transcript <tt>(com, chl, rsp)</tt> is the same for both messages, since the message only enters the construction through <tt>s2</tt>.</t>
        <t>In Silithium, a signature valid for two messages gives the same challenge <tt>c</tt>, the same response <tt>x</tt>, and hence the same nonce <tt>R</tt> and context <tt>R || P</tt> for both messages. The ML-DSA signature is then valid for two different messages with the same context, which breaks MBS of ML-DSA. MBS therefore relies on the PQ component. The traditional component does not help here: <tt>R</tt>, <tt>c</tt> and <tt>x</tt> are the same for both messages, since the message only enters the construction through the ML-DSA signature.</t>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1da3vbxpX+jl8xK38I6ZJUJEuOzaZtJFmKlFq2LMrNk2e7
TwkSQxIRCDC4WGZs9690f0g/bf/YnstcAZCS0+zlQ3efyhIwM5g5c67vOTPp
9/tB8OjRo6CMy0QOxc75epLHkXgRz+MyTMQonqdhWeWyEHdxuRCjMs/SuXib
zrJ8LsNJnMTleicIJ5NcvoPuo7dnQg1huu4E07CU8yxfD0VRRkEQZdM0XMLX
ojyclf1VHk5k0p/O8nm/qGb9BfXvF/G86H/5JCiqyTIuijhLy/UKOl2c3pwJ
8UiESZHBF+M0kisJP9Jypyd2ZBSXWR6HCf5xcXQM/2Q5/HZ9c7YTpNVyIvNh
EMF8hsE0SwuZFlUxFGVeyQDm/yQIcxkOxUhOqxxWFtxl+e08z6rVUJycXX8b
3Mo1PIqGgejzA/j3Mp7nYQnzwz+u3pwE72RawfhC6J75elVm0Gi1WIuzLK+W
8I4Xcy0LGebThfgWm8LjZRgnQ4G0+CaW5WwAZIan2GQoFmW5Koa7u9gGn8Tv
5EA32sUHu5M8uyvkLnbfxe/DllWToUiqaVgwmXeZ5m3EDoKwKhdZTosTcQp0
eTkQV9QNBhNiViUJb9xLHNB9BTMI0/hnIsNQnFfhnYzpheQF0QwGPIVvFvR6
MM2W9kvfDsT3YTqvfefbChgstW/u+8wdNBzMqVPrV74biO/CNJXT29qHvstS
WJD7zv/U2xSInRfAEiKbwXxKmSdZ5n76xx+58zfVnXo7mIb2yzcD2OsoWte+
exMDN4SJLO7C3Gngf/xVdhuH9HwKExiKY1hlmGS5pGe5nFOrP4Y5yFt4q1pm
VVqixF2kkeqsJrpzm6VRGeffzPFvpM8OTlPTYZGKj7CzsvrH38RlWJZFgYxN
UxqK0zye4gNxdBw4S4dOg6Vq+41UbYjyQYyaAt4B+YCvrs9Onj7/6jn/9uzL
J/v8Gzw6gN8u+i8GzJ7I1f0kXK6K/uqnPgy0yoD2ktgUuO/o8mrUP3l9efV6
dHFzykM8Pzz0hojkO/j/teJ01FOLuFqCaF+8vLg5v3h7GYjj8/0nKKZCK78j
IHUpBayvrsPEaLqQS1nsYHNSH+K7KlmL/S/3n+AjIzn0f33e81cDcYzqKVGP
hSLyqzgN/Teqw/FAnAMz1JofgyYqQ/OmDEHzllYbyFUep+UgDqc5KQKc0u7B
/pPBKpoFyNL7h94ij+M8QiaGPQb2ABmelvHUVfXiJFtO4hTYHdsUMn8Xg8rf
oPkNOV5PywyUK1LkcCNFavJn19iQvwes8nB379nBAS/z+O3Zmb9KeIDTLsyq
Ct5BMZFrEABReQsRITwqF1KAmpJIHWC4sv9TFaZltbSDuPsPM9jbuNCTAWh9
+Fxe1BZ6Asv036geo4F48Y+//5z84++1HiP4GdXeqT7XA3EWyyiRea3PdZXK
2ivV5RK7AClAQ9b6XIIFqb+zq4GtUYrAXcwij4syDlPndX3jYinl+xVqqwH+
SpsHDkC1BIO9+/xw7/nB/pdB0O/3RTgpSuTGILhZxIXQjcQqz2A3YOfKuwzs
6+6N6Fzh7rzh3dm9yUMw+qADw6Qr2J45245WHsz7FBvAEIuwFCGYTtAN4IwQ
S9c4oQK5zMV0AZ9M+8AwRTiXApRbOL0tRAccnP7J5VF3IG6AW2ZxXpQ9EYpJ
Aq/7k+y9972e/lQhVD9RKM8CV/UujmTEU0LWg1fImKTtUlx4B3wEFE3QM/je
Y0lo0RVxbVz5WxGXIopnMxTeWZ4tmaerPMfxjB7VVApXMAuYopisBUh8hALj
zKTjfrHr0LTMeNwsRc8uJTOFQoMPDcWUQBGJYCnuJpmRkIqwCDMPdMfQ1ySa
1LeyQOcoLeF/TWoCjVNxt4Af9puWkFmaGIIX4rTWeYAMpxeNm5lmaX/Thuby
pyrmKbavzX4VqDSRYgLeSGn34iwOy/5oES7jXKxC7Dhf9ohYuAFFc6Mt1SP4
7rSElQARMiaR+dgXBXAscIpM55KeViXvCnimC2BnaA2kAd+2xD0GJgE1BE+y
VfhTJekbu+DfxDNwb0AEE70x70JwpWEpDUbD/gkKD45TikSGBZJZai5AUTWT
K5r9ByzyyzgCFQURCLgpIIwRUzkIvsdYA8dBRTmX6bSpkztXb7pAEg5TLI/0
4AOwEnhGzjdIbJxOk4pY+/RmdCFOfjg+vSaCUyBBvkRP3Lwcie9ej057YjQ6
vwQ1EoJ+UHor0pzoq5IpWUkSGbv/NPDVGwhOIN6BRSwLVhTIuWKeQQMgBewe
MzqRsA/e4tJycgT/KDGEcdOCBsYu3uqnTkiBWuY2ze4SGc25KyoUd05mMhBI
wFwy/KEkGfmirlgKJbxKLyWg/ICFQNEnCfBTDAaygh3JURLRck6yihoCRzsi
dbJJ6Wg7bJWbkkygN1gT6APR2+cpZSXR3R5IG+i/DCS41CRuVfIDw47yPXwx
skoBNCGLuKEkCMvEkymaM/i1wPPxJCFtuCLelag75B1ITeKZIFJO8Hl4rabe
ty9XIWoCiJ7jrCpg4GyCHpeMlARGaGBTYjlgygJaan8tXq4S+IWZEbgLx0Di
wbw1gXK5SkLgD2KkkAeJKtON9U6SzYEDYjDf0BU27igBf6aaL4wggdbBjXS4
qKhAV8NkTqMXo6OeuHzZp39xtNHLc/xDTJMwXiJptLGtq2wQ1GyJum5VQTDr
8avmkI4czAfi9ATG67IO14Op3SLZyiWQVvYc6US1pLmtoSHU6MaWkG+r5kYG
BLWYVeJRBhNBdoK9QBUU5kB9mjF0h28XJZoPWGYUwR+ov+OCDKPMgb6l58gU
KzmNZ7HyZFqViuef1Enm+Bw4nVCAZsRoS3SMtep64/Fw8wrsDEy2zQsxJlOZ
fJKzZI1EcfwQ2gdsBZqNyef6HgNxQfMBqSnRlgBf4naAYgG5AdOegB+qp0qy
Az58BqQiV8511FCfMj8zL90BiwHLgVLTagL9wAiZ/cMHDN4+fUISE7PGpV1d
zDsWQrf1z9weJ09bh6btArVSlUQEIeEkKxyVBVTtCswN12p4NZdMFKTpXV0X
GzvHG6RISTu0zZXgD9Z9lQf4C1owUPpA590tYhDHbbv8S401sDaY5pMsJcWC
/Inb8kLOQGzob/acbiUwUpaDFt25fDu6QeQN/xWvXtPv16dv3l5cn77A30fn
Ry9fml8C1WJ0/vrtyxf2N9sTgvzL01cvuDM8Fd6jYOfy6IcdZpad11c3F69f
Hb3c4f12BS9knxV2moQWNGUJGx4WAbiD0zyeMI8cn1z913/uHQBv/dv12cn+
3t7zT5/UH8/2vjqAP1Ba+GukjfhPoOA6ADaXpBOApxLg/RUqHWRjUJaL7A50
tySn5/G/I2X+Yyi+nkxXewe/Vw9wwd5DTTPvIdGs+aTRmYnY8qjlM4aa3vMa
pf35Hv3g/a3p7jz8+g8QQkrR33v2h98H9XBuliVJdseeLro+cZqBCVqTOHhy
VfMXImQ7Lf0KNPr0aaCGB15nf1eijinYuBB/o8NlP8MuAgk+qGzQL+QeR5al
WRmUixzVivJsYKczMPR6CUPYR2WBHg+FOHXclrdtbssJuS3iUlnlI3JbkBlG
dpBWeOW+/m4YLI6K9XIpS7QHDuAMfx1pw43fOQIONQ2DqdfQWHjl+BQkLikF
qSQ92vefg90sykD7X1WBqtFVh1WJASgw/50EcYB/wR0oCnJbzOsB6o412Qmt
h3Hr4GNqpD4YVKAsxh/AGvphEc6k614jGdCQbEpc0KLFskrKuG8XuMUtAEe0
WhHrgFqED5O77DgEjZ6OY3SHYu7rWDIDHl/bWaAmaTZudd0b2+2gHhgL7d50
NQlOjMfNoGU7BdR6W2Zs12pb/0qrMKgAbC3OR7sZNFs1I+gNgRcZerRXApnL
OlyzcGrsVhFCc8yjYEMGJBozJwY5Mc+ZIsPHILWIN/j8ryZAzL8Mb0HnACOE
7Kd4ygjZwn0KnkmZTbNkgOby2Jj7E9cV+/DI+AGf2Gwaf8Zz2TwIxAVjIC5D
grk4jIUMFBKBbWTkNOnhQnQ8mZE/r/1r4yY43gG2clAnDLEtTZtBPLk7WxE3
7OQobpoq6X/CZquJUtu4S8fkx9M47MHrKGa8HJOVre0BaMYYkbXQDXcQr05L
SjdAvy/G7EjBCBSKKB9d+eFT6yAph135nRhMWT/fiWHQmyskumGsn3vOYpBR
l5iXs2gW9PzwoV/LVpDJevRIC+sfQQV+i74xZxCDv/71r4H62+VncLHA2eoL
86qzut2DEOp2r0uGU8EFtRBqUOuxjz32bQ8faDJdnF1dVROIFsnDg50cr27F
7+jT4uNHAeN1xwOasbMgVLzM3/xggA8cDYDcAVqdoqm2vYY9452N7N7daTio
5iz3tD5JzVBNXBKGxNkWe2OtN/T4+qO14S0nmxd1aHZQ2ygX+PS5EDfthE2e
gIn8DlMqs/g9zuglJkPxl0SmnWkJsRv8Dv/iP1fnnWU3sB+oC5k7bLEHwyKV
/7LXKZArll903df7+vU+vN7H10wPbPS6KlfKx2nIcYF7XdBWF/td3ueL1Cha
jTDWcF9/+UOc6JjXPCbsC5pO1jAtmU4zQuW0Mi8JcsEKAmYcY8Ex1bOjw5wY
Xen3YKSn8ZLRtJ3DJ4eHB08Pnn31/On+V/tPnz89OHwCP796evoU3PavDuHZ
4ZP9J1/C/w53kL/HRPnxEPguoT1QQzuaQSHcjhposy3gs+Cc0WOkcfVG0tBo
txK1WEMUzaII1AJvwdrH0GFMvfGXoWbgUr4vqW9B74gf1NtFWCzqVFf+GZAM
p+KI458I1WV25d+38tJns2hfXIV5gcwC5gO4pUe8YgfkbwJnrpgze4rxau/3
WTtp1tSjHE2ncgWWZyYm4KgLgqgN5lVU8BaXqzXQtUxCDOy+z/JbVkEtGAvH
D02tXEsSNGJoPQcnUMawkju4IJKNuilO1N7Kkk0hhyII6k0HmJuHBfQcxNHz
o7zWDgMqpA9N384yft+HD/WXYTld7AiKHnL+Nksbw2MilVNkFXgFrMLgXBNe
unANHwWvnk2xiRgFsWrgNkzXzrI5OjDxAEcJ4PD3GG1qJX5cWBCm6W/1KK2l
kTj91SbBN32ZVuZBAj3e7ta0Wwp7UiiJMt/IrEPmuyEbM3wD0pYoyjlu6AZn
gD0bbb1gabhNWrrb2NdFwXyUAyIpJM+E1BZGUkn8M+LImstYaWsN1FD3Y1/f
j22qy3Yct9masYYkwRbkGK+WmY7yoMNG6zNGrDnl+DtXklt3HYFipl4DacWK
mpFCzOSd9MGhT7M8J4ZnHHogDIKtlK6JJCCWjMIERUttnpsds3DqLIfAAiu/
egQr1jdHAxgQEFFmJDWen7Iam0E/4QFO3vYNmx5Zhxfkevyx3g0YAd15mAT8
vYxLnSnHNERUSyLZONESrFtflvGlvB42qcjaJPWdM5KJ9nSlyl/otPJSwlCg
yUANJkmFif6SfHf01RCOw0IDDPVjz6nwKakdawqzXnmvaqGW129ruKUhIo0f
NcKvWtDkBEGbUNX/tYjJtXCMthsd2ix74cxC/qCEtA4F69g0cgh1JIVfh05U
p4avLM4xgctAKc4Qdz2EHeIsFhZuGqOuh+pcvOi6uYjQm6ZHLkIfmpPpgM75
y353EOgCg4TyLpmTtiX8nPvDcjYk3bUBQqKC34m5Da1n/hWy/tMhq186cfHi
gXHrxsKUz4phe79CBIuMtdaqtlWU9JzrsaUjHy+sttY2phPOSpnrWEvrd0wA
T6RMjQ3o9tpdGMPyESa03di4Xp5jR2fdlGNNJ6HOSgW7i2q3Qwz/OvNoWSSp
dxlGm6qEnEWG6ApWIYJp35NGq+lAcBk4AODYEnqaqMmMkXFYC2sfX7wYQKzB
EVZRqqYEJZJPWyKLNZqjbwN+DfoK8wJ9TfoMR2mLRH9P20Z6nhcr9RwEdoWl
5XqtrSrufxxBWN1+UXwuktCBVYKolV34ikMIbwI0g/MOuYnsy0GnNrxh4Ht9
HiYBRORh9jW6YN8BIfnz18WKfUyaFXShqT0EtMAh/oVa/N+jFsiD9qVfK4gg
Iko/6OD/rwiHL0I+0uGwWF9cyx/BK0OIAB9jpQiwZ4aAQYUAfQdtAHkbQzES
v/+dePlQWYDtY1k4fV+iNJLVIkmAD32mXNaRli+aIIuLr2h4pbD2ceQiG0cr
qiNSiUpwuSeTvnZOPrmuqeMEwyecsgPHv3OghRaf+SjSPkKyZoNnPAWxhFiC
q/WqNMZaRq19C2NbtlilTnshR5eHnVXJDGvedNEWbac7187l8aiLtShvz84+
faIP5vAjW5oSNSoFQwJ1ri//hE2pHl+lrbVToAJtslydLN0A5lPJjZoS23V2
YI0acBx7iAYsiQjFrlPHK1Vpm0BLbqA5A3ScYTdfXYxuVHSdR8UumOmU8J54
ALunq8NUZVhPnIUJfBV8P5Los1cU42KpCUR13y8YlDlWYeO54aFrnmMUBKOM
XOlVkq2XDIM5/KHXoplITYKinzQj1bhWSX+uiVXoC1YXhun2Qr6eU8mHDmEO
Ds26zypJM4kKe5eEDBRe2HCn8xTMhTB4JRlERHiwkAmGBpXKe2qngegYSadq
jxxrOtUWpyDYFNTwglBtmrI5t+bPG0zNF8v+4GkOYVF3AHSPE0mIBiNHLcJL
gNkGFNSExAryrEOdBOAlVMRvdIEXsWAwA58/uX5zIiZA19uiCUVYh9mp+nPL
1t1JMUSjPwYkwgouLN8yJs5N5pwpJ31jGT/Gu6gPiwL436CsMyo1oXJsrdew
lIpPOwJhsVBEvAJGsrtOM0Deos0bChEIkkSNVWoOLGwtmt855Z42rfV47JTq
yjmQaxmWhqlTLOLUe745n+XP4Y6q4wjuQTAUyUdLhjmxSIyLffgsAVCEnpgF
4XlBnD+DFVglmqrGVBRg4GmF1HJN4Ylf5iBe0AEGqpikefbrFKiJ3iZS5rJi
O8CVxQRgdlQKYkx1QLNwgkWJDEXpUls1YR24UZUB9tO4ZU+sY5kw18F2KyVR
MzIs+sgVWjEEwTFKDrgGQHZCVYECcYmmOTSM2kag+mYNXWwGjytxISHugfqW
FxXyW/VHvTSZ6WnIY5SYuJhtjCx989yDD8ekfmguJjC0pdK6ULrnRnsTAri0
lkmhv1vB6WDoWjS3VVKS6CpFgLgt1UOTnuIzExQttvsCsNfjJqpaCycp+oOY
HHou+DCCbqQI1nXWZhBTChX1i6rwY0OKF3usKN1sN0xnACpDUdSQfcqmSiVz
JljEH6FCR9qZ88/JWrtWZA/YS6byafFOFWsjYUyZkFN4HAT6m9y+A4Ra7R8+
zfd28bcnzw7yvS7sgfJjRec02j883Hu+exodHDzrcvmvLdAaiPPsDjWPQv34
SJLhalsNFkZ4rDY0ypK/rgp4jQkns2s6JeyA8pEf1Gh+nixFW1JwjSAeNv30
aSjmMTYOG+w/7sAMiy7t0pqw29CAK/wyFX3dIGJdh4qMygfbhMkoDCv1jzXl
HeR4Gx16taNhnlMusT5wqo4fgVOG5Xew57RYPE+LSRLfso6/FF9DPC6+Fi/H
WPps8xlNIz2hqFqtkQBzmZeGqQzMaZAwdAks5/NE2ZHC7aPpgeEHFxCYNiNu
UGReZElkIa/4HRqsW1UMqF2wJRpdo5NrtC5aiS1eO24ECD5+k/Q/74DzpZ56
ZGXK80564kcMAJL4VjJL6jLThUbGDRxFtwiAa01Mh7q2ra6fePuo4V0R9+L0
iOs9Jct221TYb+kb+X1VJuCBrIY7TrXyqllok6eq2ZpY+Gajc2QyKLbaup4R
pal66sXokfZEQ69ek3b1ptUEmaltybg50L86rrIhYGrPRLQGT5ZuOOqJM6pJ
UjODbISFvUSQJ+FUDq7E3BNezfF6FsDtSNG7uJA9PulDXtd4pOqlxiPxG+xG
zkphhcWFWnWETC4OmB48lOOqQrZNdfehzS+ty6Jr7P3klqPZKZFnUAU0SLAJ
nFYofMThMoskH667zEqUYso8HHMo4h6gwWjk9HMSdN5pUMlYzX3+BpdlYysb
erpBtNLJHiTyqatPdBk5ccNWPjbtKCCd6nYXp89dtZZQqJoMcw4E7QBltAlK
3yLAnQ8fbK70U1eE8ZLExY7UflDaL1JwqubAR5LaQbrfgVRkoWrzB5RLcMGy
CUpnNvKjImK1YgsEFI2A1avsGNynP4A6fjYZKARvCQmVqTrwNatylMUhDDwN
dcrClXvj96HaIRhJYbUNh5RltwEKgmjW1qwT095s0bAWGKU3PMgWx715BN2C
RmjoGohaR+klwn5crdXdDLbZvPnl8YiaXV/+iV1TPR9z2w7eREQQkH6jYJQg
YHyifnJbHeNCXLiawVxizjSZk4u4ExiVYOmRDG9TUE2S2AwHIjxDZ8cJL3Bm
vURbqxm9szIxbfsBz9ao1K0u1edIHA8EQgaZhpMER4V+SR8CF1gLnTmmqhMl
63yGEzddDYh4UFbhwVM8mBmvyqLtHKfjc5Ejpe8AYNwMplesi1KCoPMx0hiD
B/AQKl3/jpzVPF1twB5zipvDsxjnGRY6Fttc0B7fG1Z6eXM+AaKJwcdNeuyW
qVOpGnXEUqeWqodO7YiqLKeD7oAZzRiXaxWryocAQdYxwgnJ5YqzIxohGXeW
jxFgwB/7j7tjRpJZGimtdKXcWwWh+IjOYx/SwQOQHoAz2VCy1nH1jmY8WMqY
xmKAput4Ps7pZX9HrLQqWfttEGR5QDkOKt1ox1LoEDN7pCrWo7AZl/h5X7WO
wYn2q0uMMR7KNxuUuKP8cjkHdkmcKjujTdTfDWfU3iBgjsuqM/HbL5YgjJYQ
c2g1ybNb6IygOcUnfnlgfYWWIl4g7LRgaeAW5OZIRJpxoljr9wDny/cPHgqz
kI/Hsk760HrXDF1cpMav6REAR61crkHApcEqHi7CLGsXo5mbuuqQ1cTACm6x
a/7FRox9gTrJbIi44cDMpuBEHYsmsMDJgG3EtT1mti7mfX6lDk01K6mb+vwT
d+4NDDpDMMZZdC4p43n1Bn4Zd5V3pVblXD2iwxq87AjDpKmuWVClE1lzXU7a
BEwp3SEF02DxD+mKPI6XtYHzitaqCWOjMBT7CljuN3LqmIKAD4E+PzxE35cK
5pSrB/MkbxkvagOr3+gqOt+/GrHHok5dNluMoEXDa95QTb4h+oWPeO6gqSfY
WnrAJWDI/qhTEM5gc2zRlSUQCw/Wq6snVNi67rkXQBAcg06KSbeHDp+5rjqq
Zob7KYlK1UXAbJlT4tl08YEyBt8DSpkD97z0iML3MR64wfKI1UoP1ZLRaBQd
E/LE/lXbhGu0I2LhRmoY9/P6qnNBn6H+akflJ5KoZvRYou5o8ISH5qZgGZ8g
reFTqO8O2LISOtXUnvHnGL5lV0xCw9VXDlDr1HrQjNXhSy9xxRewWNeWGEdn
XOMUxuH+V+dgCujegLyQOmnfrvRs1TqXKZYyGjI6LrhU29zmoCAjR6+Qxq/y
lL0RKhPCuogxp+Q0BWvdcCV0OtwwwuW4thKcrcLVLJp/jh/gshAiOehLlD86
eNEesLU5PiYbgzOhOpdZxde7oO2kuxJNlcOWqNQaJYu2wZa3HQV0HBmNWrVy
AuXfL45eHTWAGB+2QKMKLge1DE0tMt7mNIGp8oURS9hJjERQ5oybfcV4MrgL
ganKlWkUv6dJhPpSLfeGNNXev6jCRUQa4KNKcWZcfuefHyD/+/hBIMhw01EH
pWy2HGro10rT70MThluEw70r4QE3gYzvqZ2rTb9RoUezH+m7Mvn2CnVnjbp3
wSOne/7CpPRoA3S45fzRWoVqEtK6dkzV042vySkZW6fO/ZSTYRvjBU54JZKr
Up0PanOlKgBLspoTCUTtiZ2bHZB4uipPgTHtm0C3i1y92THlda01Q4jRT/G2
A2raQX9zgJ/owmLD1DlQYNIqBqtRoqj6bLhNzkQZmFCBb6DDBAvYPvj9CGhj
WFytP24dP6OIVh/Cwm5Hm5MH2zS/+TRoE/dWKLQzipBqkbnkkgjYAKQulqtQ
Oq+uKhD0o3AksxiQr0VCVx3C1ArpNkB0g1OFnEODVtikUHBVtVzCkoLgo1Zl
a/HR0Scfa4L/0YqS+Bh8BA3p/Q+GGanCTfbSPgpPB9HfNWVBz1wZxIFN3Ilu
PFGs/Tf8oNuy1ojegw1RuvbG2SlcGfz4AUikfvptvQhINTY/cIIYyhXo3b6+
w8qwRbwSndPXXfrwnx8zz+k/4AUD/Vhb1/oMRlR3ofSPCUt1binvuN3M4uB3
/Q90vmllx4/iKMUNdfVsa/bHU7rQwVFNOPqJlRRdzEU7CHL0ngh4oy8JVLvw
CiWSKGrjn/hneET/gHPcFb9Rv+539VP0cx7yOAj+/JgBdrfITyVs6pHrUhKg
VlI6mEB0CJG1Lm8tNIARFmEeIbLK8OHKhmxb7sUxN/YFAd/DUYu5f0kGB7V8
CzvaBj19PVO5yGXtYtheM+YlbaHrcUzZlrZczYN4GsYjncmkUllqoix36zi3
EczuwRrRxbettkUm2kiayZXgdc+oq1FBOv3Ek6wjiz0+4VojwZaaLc9xvLgH
1XA3YOuKkSyN22PqcY/xrFsXYcdom/iGgkLlHmxLI5OaMZ7R1uWGFs6iMMQ6
LLXDkz653cy0myLafmQndm9+RSTFSfXmeGtVSBkPnBNfo9N6oMfsv7sorCL5
XFKypWy9zMrcnbxRUFWD4VZBZTlsrY00pDLZL7risVB9fGJnrQWCVMfppLNV
VeOFd7FwWPCR9IfJh+6swWvqjQef8XsyKVTV0SLEo0S68TYQQq1DVz66N5zM
YrQxKAO/kKk9+efRNsCs0JI/77RqHCazWU/EDZUpfXiFUx7SfcZUSNSxtRDC
HKjoCXr6Hp7+1NB3R+0spEuua6iul7auceYDdJzhXXOxwBbC8ym7wq3vSb0y
YcXAi9DhXbPZqAH5KQE1tRpOakbs7ZV2bMbca9zNJcyUNOUKB53u0n6/KpBn
cMXXdDgnh1WMPvssZXxD+RVd3BpTilIBx1i9zpioz1zKRWNwhT34WpmLPax3
n4TdQ1l7DfdcneVtU0d6olrMHX/A5EncQJsGqcetbXU1vBgVLZP03Eq5cst7
vOhYwY5+dI5tbT4Gz3G1I+xHmy6gUFekbAPP1V44IjLzkqc9tU2NS957GhFU
gb0HQup7CZn32DVyr0E3x7Vp59a2MFDhoVOFbGHpsdTFFshIeHzL3GrvD1ao
PM+a9IbFQ3AjyMHnXQJrmt2h5+sW41XmFjsTAujlmVtMXo16OpNkMH4qM8wM
CfQtFOb2fXVXe1yqgi1HSqlsKzP8MODwQgNoLdrQakK7sw6U6GpCq/w3XW9R
v6MlLrdjkkrRWYTmXgB+O5QAMx/WoOBCXR29GQ0OPShYATIPwn8hpAqTQld6
s7qzdUd4jsVWucp4yekevtTSXmNYQ4GP7Kn8fK5ySjbLupkGCLVajcL5wzB1
K9RsgCaoVOjON+1eTLMNTKPYrj2iD4LH9nrg4eMGayreUCZkk2Cr5CcYImut
7Cl+rJBme8CXxto2ukLGHMmzfLUlyBo7l3xTpp/ti/NB78RRQ9pQAeNZ132G
V7kUU+KTPWN1sbgZHzweq8Uxr1CwQgliJfqFjnFAZRlL1/DytBSqUfHDOV3K
Tz5k1GPrxRf264EH4vS1I+vef8einaH4XnsS49PXMB99aywnKJyKU5qBN6Dn
PvnjPEjSOQnKm0FXNugLB9FyztoSiS2842ygOidgGAXmx4yk84ab+c405R1T
h9OAli3YF03O+H8uVWkSPGhPxbD2NIly6fTrIqtNizSoNyl18s8WCZDp56nW
ZopVd61TrbGDxk1J9xm0rbUrbWEtbmivCxnoc0RKi7hbopfbpmS2b8nG/dAX
QLm74KBz7tfHVyoZcgUi6U5F+VaFyUFws2sqzXIbq4B589Sb22bGrm3cxl3T
C/pn9gq09Xa09NfR2c3VGm1cW61zH8tn6mn4GGES+mKNdKXP2XsZCrShDQXh
z9LMjRO/c6pyT1kf3yN0MJO/KB2Mv+4rUeaDjg/r7epxGkMXIjj/gYem+G5I
6tYqb+8Te3xheWlzvbCTGOqx56Az++wnJEmM/01Oe0n3wzR7Ww0IotY9Lv/Y
sEscarXGOOB5+ecYGuf2cDTiEFtASwedNmyPu7u4vbgpVfFAlfxQ5evvgi/R
nvG0NwYQb7RbauO/LGSyoshmSDEDnQGf5vGq1D6xuTvCXGtCNGshkQ20TT0p
qlSZ0rl2pSndggS6MJ+j27qBCO+Xwy07PPYsjK4TfO+ZUNOATv+Buh57gbLR
5Y2FMlnblDgBVvfqNnukmnmPvrddmT907z93x2HRPQr6iXnfjzXO9WtvcXtU
8N88P9N/SngAAA==

-->

</rfc>
