<?xml version='1.0' encoding='utf-8'?> 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.4.4) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pquip-hybrid-signature-spectrums-07" number="9955" updates="" obsoletes="" consensus="true" xml:lang="en" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->

  <front>

<!--[rfced] Note that we have updated the short title, which appears in the running header
In the PDF output, as follows.

Original:
 ietf-pquip-hybrid-spectrums

Current:
 Hybrid Signature Spectrums
-->
    <title abbrev="ietf-pquip-hybrid-spectrums">Hybrid signature spectrums</title> abbrev="Hybrid Signature Spectrums">Hybrid Signature Spectrums</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signature-spectrums-07"/> name="RFC" value="9955"/>
    <author initials="N." surname="Bindel" fullname="Nina Bindel">
      <organization>SandboxAQ</organization>
      <address>
        <email>nina.bindel@sandboxaq.com</email>
      </address>
    </author>
    <author initials="B." surname="Hale" fullname="Britta Hale">
      <organization>Naval Postgraduate School</organization>
      <address>
        <email>britta.hale@nps.edu</email>
      </address>
    </author>
    <author initials="D." surname="Connolly" fullname="Deirdre Connolly">
      <organization>SandboxAQ</organization>
      <address>
        <email>durumcrustulum@gmail.com</email>
      </address>
    </author>
    <author initials="F." surname="Driscoll" fullname="Florence Driscoll">
      <organization>UK National Cyber Security Centre</organization>
      <address>
        <email>flo.d@ncsc.gov.uk</email>
      </address>
    </author>
    <date year="2025" month="June" day="20"/>
    <keyword>Internet-Draft</keyword> year="2026" month="April"/>

    <area>SEC</area>
    <workgroup>pquip</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <?line 157?>
<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 backwards and forwards compatibility, hybrid generality,
and simultaneous verification.</t> Simultaneous Verification (SV).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Post-Quantum Use In Protocols Working Group mailing list (pqc@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pqc/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/dconnolly/draft-connolly-pquip-hybrid-signature-spectrums"/>.</t>
    </note>
  </front>
  <middle>
    <?line 165?>

    <section anchor="introduction">
      <name>Introduction</name>
      <t>Plans to transition protocols to post-quantum cryptography sometimes focus on
confidentiality, given the potential risk of store and decrypt attacks, where
data encrypted today using traditional algorithms could be decrypted in the
future by an attacker with a sufficiently powerful quantum computer, also
known as a Cryptographically-Relevant Cryptographically Relevant Quantum Computer (CRQC).</t>
      <t>It is important to also consider transitions to post-quantum authentication;
delaying such transitions creates risks. For example, attackers may be able
to carry out quantum attacks against RSA-2048 <xref target="RSA"/> years before the public
is aware of these capabilities. Furthermore, there are applications where
algorithm turn-over turnover is complex or takes a long time. For example, root
certificates are often valid for about 20 years or longer. There are also
applications where future checks on past authenticity play a role, such as
      long-lived digital signatures on legal documents.</t>

<!--[rfced] We note that both of the following terms are used in the document
(note "Project" vs. "Process"). Should these be made consistent?

NIST Post-Quantum Cryptography Standardization Project
NIST Post-Quantum Cryptography Standardization Process

Original:
   Research has indicated
   that implementation-independent attacks published in 2023 or earlier
   had broken 48% of the proposals in Round 1 of the NIST Post-Quantum
   Cryptography Standardization Project, 25% of the proposals not broken
   in Round 1, and 36% of the proposals selected by NIST for Round 2
   [QRCSP].
   ...
   Of note, some next-generation algorithms have received considerable
   analysis, for example, following attention gathered during the NIST
   Post-Quantum Cryptography Standardization Process [NIST_PQC_FAQ].
-->

<!--[rfced] FYI - We updated "25% of the proposals not broken in Round 1" as
follows for clarity.

Original:
   Research has indicated
   that implementation-independent attacks published in 2023 or earlier
   had broken 48% of the proposals in Round 1 of the NIST Post-Quantum
   Cryptography Standardization Project, 25% of the proposals not broken
   in Round 1, and 36% of the proposals selected by NIST for Round 2
   [QRCSP].

Perhaps:
   Research indicates
   that implementation-independent attacks published in 2023 or earlier had
   broken 48% of the proposals in Round 1 of the NIST Post-Quantum
   Cryptography Standardization Project, 25% of the proposals not broken by
   the end of Round 1, and 36% of the proposals selected by NIST for Round 2
   [QRCSP].
-->

      <t>Still, there have been successful attacks against algorithms using
post-quantum cryptography, as well as implementations of such
algorithms. Sometimes an attack exploits implementation issues, such as
<xref target="KYBERSLASH"/>, which exploits timing variations, or <xref target="HQC_CVE"/> target="HQC_CVE"/>, which exploits
implementation bugs. Sometimes an attack works for all implementations of the
specified algorithm. Research has indicated indicates that implementation-independent
attacks published in 2023 or earlier had broken 48% of the proposals in Round
1 of the NIST Post-Quantum Cryptography Standardization Project, 25% of the
proposals not broken in by the end of Round 1, and 36% of the proposals selected by NIST
      for Round 2 <xref target="QRCSP"/>.</t>

      <t>Such cryptanalysis and security concerns are one reason to consider
'hybrid' cryptographic algorithms, which combine both traditional and
post-quantum (or more generally a combination of two or more) algorithms. A
core objective of hybrid algorithms is to protect against quantum computers
while at the same time making clear that the change is not reducing
security. A premise of security of premise for these algorithms being is that if at least
one of the two component algorithms of the hybrid scheme holds, the
confidentiality or authenticity offered by that scheme is maintained. It
should be noted that the word 'hybrid' has many uses, but this document uses
'hybrid' only in this algorithm sense.</t>
      <t>Whether or not hybridization is desired depends on the use case and security
threat model. Users may recognize a need to start post-quantum transition,
even while issues such as those described above are a concern. For this,
hybridization can support transition. It should be noted that hybridization
is not necessary for all systems; recommendations on system types or analysis
methods for such determination are out of scope of this document. For cases
where hybridization is determined to be advantageous, a decision on how to
hybridize needs to be made. With many options available, this document is
intended to provide context on some of the trade-offs and nuances to
consider.</t>
      <t>Hybridization of digital signatures, where the hybrid signature may be
expected to attest to both standard and post-quantum components, is subtle to
design and implement due to the potential separability of the hybrid/dual
signatures and the risk of downgrade/stripping attacks.  There are also a
range of requirements and properties that may be required from hybrid
signatures, which will be discussed in this document. Some of these are
mutually exclusive, which highlights the importance of considering use-case
specific use-case-specific requirements.</t>
      <t>This document focuses on explaining a spectrum of different hybrid signature
scheme design categories and different security goals for them. It is
intended as a resource for designers and implementers of hybrid signature
schemes to help them decide what properties they do and do not require from
their use case. In scope limitations, it does not attempt to give concrete
recommendations for any use case. It also intentionally does not propose
concrete hybrid signature combiners or instantiations thereof. As with the
data authenticity guarantees provided by any digital signature, the security
guarantees discussed in this document are reliant on correct provisioning and
management of the keys involved, e.g. e.g., entity authentication, key revocation revocation,
etc.  This document only considers scenarios with a single signer and a
single verifier, verifier; constructions with multiple signers or verifiers are out of
scope.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>We follow existing Internet documents on hybrid terminology <xref target="RFC9794"/> and
hybrid key encapsulation mechanisms (KEM) (KEMs) <xref target="I-D.ietf-tls-hybrid-design"/> target="RFC9954"/> to
enable settling on a consistent language. We will make clear when this is not
possible. In particular, we follow the definition definitions of 'post-quantum
algorithm', 'traditional algorithms', algorithm', and 'combiner'. Moreover, we use the
definition of 'certificate' to mean 'public-key certificate' as defined in
<xref target="RFC4949"/>.</t>
        <ul spacing="normal">
          <li>
            <t>Signature scheme: A

<dl spacing="normal" newline="false">
  <dt>Signature scheme:</dt><dd><t>A signature scheme is defined via the
  following three algorithms:
            </t>
            <ul spacing="normal">
              <li>
                <t><tt>KeyGen() algorithms:</t>
  <dl spacing="normal" newline="true">
    <dt><tt>KeyGen() -&gt; (pk, sk)</tt>: A sk)</tt>:</dt><dd>A probabilistic key
    generation algorithm, which generates a public verifying key <tt>pk</tt>
    and a secret signing key
<tt>sk</tt>.</t>
              </li>
              <li>
                <t><tt>Sign(sk, <tt>sk</tt>.</dd>
    <dt><tt>Sign(sk, m) -&gt; (sig)</tt>: A (sig)</tt>:</dt><dd>A probabilistic signature
    generation, which takes as input a secret signing key <tt>sk</tt> and a
    message <tt>m</tt>, and outputs a signature <tt>sig</tt>.  In this draft, document,
    the secret signing key <tt>sk</tt> is assumed to be implicit for
    notational simplicity, and the following notation is used: <tt>Sign(m)
    -&gt; (sig)</tt>. If the message <tt>m</tt> is comprised of multiple
    fields, <tt>m1, m2, ..., mN</tt>, this is notated as <tt>Sign(m) = Sign (m1,
    m2, ... mN) -&gt;
(sig)</tt>.</t>
              </li>
              <li>
                <t><tt>Verify(pk, (sig)</tt>.</dd>
    <dt><tt>Verify(pk, sig, m) -&gt; b</tt>: A b</tt>:</dt><dd>A verification algorithm,
    which takes as input a public verifying key <tt>pk</tt>, a signature <tt>sig</tt>
    <tt>sig</tt>, and a message <tt>m</tt>, and outputs a bit <tt>b</tt>
    indicating <tt>accept (b=1)</tt> or <tt>reject (b=0)</tt> of the signature
    for the message <tt>m</tt>.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Hybrid <tt>m</tt>.</dd>
  </dl>
  </dd>

<!-- [rfced] We were unable to find the quoted text below in [RFC9794].
Is this quote from [RFC9794] or another reference?

Original:
   This is different from [RFC9794] where the term
   is used as a specific instantiation of hybrid schemes such that
   "where multiple cryptographic algorithms are combined to form a
   single key or signature such that they can be treated as a single
   atomic object at the protocol level."
-->

<!--[rfced] To improve readability, may we break up this long sentence
into two sentences and update as follows?

Original:
   While it often makes sense for security purposes to require that
   the security of the component schemes is based on the hardness of
   different cryptographic assumptions, in other cases hybrid schemes
   might be motivated, e.g., by interoperability of variants on the
   same scheme and as such both component schemes are based on the
   same hardness assumption (e.g., both post-quantum assumptions or
   even both the same concrete assumption such as Ring LWE).

Perhaps:
   For security purposes, it often makes sense to require that
   the security of the component schemes be based on the hardness of
   different cryptographic assumptions, but in some cases, hybrid schemes
   might be motivated, e.g., by interoperability of variants on the
   same scheme. As such, both component schemes are based on the
   same hardness assumption (e.g., both post-quantum assumptions or
   even both the same concrete assumption, such as Ring Learning With Errors (LWE)).
-->

  <dt>Hybrid signature scheme: Following scheme:</dt><dd>Following <xref target="RFC9794"/>, we
  define a hybrid signature scheme to be "a multi-algorithm digital signature
  scheme made up of two or more component digital signature algorithms". While
  it often makes sense for security purposes to require that the security of
  the component schemes is based on the hardness of different cryptographic
  assumptions, in other
cases cases, hybrid schemes might be motivated, e.g., by
  interoperability of variants on the same scheme scheme, and as such such, both component
  schemes are based on the same hardness assumption (e.g., both post-quantum
  assumptions or even both the same concrete assumption assumption, such as Ring LWE). Learning With Errors (LWE)).  We
  allow this explicitly. This In particular, this means in particular that in contrast to <xref
  target="RFC9794"/>, we will use the more general term 'hybrid signature
  scheme' instead of requiring one post-quantum and one traditional algorithm
  (i.e., PQ/T Post-Quantum Traditional (PQ/T) hybrid signature schemes) to allow also the combination of
  several post-quantum algorithms. The term 'composite scheme' has sometimes
  been used as a synonym for 'hybrid scheme'. This is different from <xref
  target="RFC9794"/> where the term is used as a specific instantiation of
  hybrid schemes such that "where multiple cryptographic algorithms are
  combined to form a single key or signature such that they can be treated as
  a single atomic object at the protocol level." level". To avoid confusing confusion, we will
  avoid the term 'composite
scheme'.</t>
          </li>
          <li>
            <t>Hybrid signature: A scheme'.</dd>
  <dt>Hybrid signature:</dt><dd>A hybrid signature is the output of the hybrid
  signature scheme's signature generation. As synonyms a synonym, we might use 'dual
  signature'.  For example, NIST defines a dual signature as "two or more
  signatures on a common message" <xref target="NIST_PQC_FAQ"/>. For the same
  reason as above above, we will avoid using the term 'composite signature' signature', although
  it sometimes appears as a synonym for 'hybrid/dual signature'.</t>
          </li>
          <li>
            <t>Component signature'.</dd>
  <dt>Component (signature) scheme: Component scheme:</dt><dd>Component signature schemes are
  the cryptographic algorithms contributing to the hybrid signature
  scheme. This has a similar purpose as in <xref
  target="RFC9794"/>. 'Ingredient (signature) scheme' may be used as a synonym.</t>
          </li>
          <li>
            <t>Next-generation algorithms: Following
  synonym.</dd>
  <dt>Next-generation algorithms:</dt><dd>Following <xref target="I-D.ietf-tls-hybrid-design"/>,
  target="RFC9954"/>, we define next-generation algorithms
  to be "algorithms which that are not yet widely deployed but which may eventually
  be widely deployed". Hybrid signatures are mostly motivated by preparation
  for post-quantum transition or use in long-term post-quantum deployment,
  hence the reference to post-quantum algorithms through in this document.
  However, the majority of the discussion in this document applies equally
  well to future transitions to other next-generation algorithms.</t>
          </li>
          <li>
            <t>Policy: Throughout algorithms.</dd>
  <dt>Policy:</dt><dd>Throughout this document document, we refer to 'policy' in the
  context of of, e.g., a system policy requiring verification of two signatures,
  an RFC description, guidance documentation, etc. Similar terminology may
  include 'security configuration settings', settings' or related phrasing. We treat
  these terms as equivalent for the purposes of this document.</t>
          </li>
          <li>
            <t>Artifact: An document.</dd>
  <dt>Artifact:</dt><dd>An artifact is evidence of the sender's intent to
  hybridize a signature that remains even if a component signature is
  removed. Artifacts can be be, e.g., at the algorithmic level (e.g., within the
  digital signature),
or at the protocol level (e.g., within the certificate),
  or on the system policy level (e.g., within the message). Artifacts should
  be easily identifiable by the receiver in the case of signature stripping.</t>
          </li>
          <li>
            <t>Stripping attack: A
  stripping.</dd>
  <dt>Stripping attack:</dt><dd>A stripping attack refers to a case where an
  adversary takes a message and hybrid signature pair and attempts to submit
  (a potential modification of) the pair to a component algorithm verifier,
  meaning that the security is based only on the remaining component scheme.
  A common example of a stripping attack includes a message and hybrid
  signature, comprised of concatenated post-quantum and traditional
  signatures, where an adversary with a quantum computer simply removes the
  post-quantum component signature and submits the (potentially changed)
  message and traditional component signature to a traditional verifier. This
  could include an authentic traditional certificate authority signature on a
  certificate that was originaly originally hybrid-signed. An attribute of this is that
the
  an honest signer would attest to generating the signature. Stripping
  attacks should not be confused with component message forgery attacks.</t>
          </li>
          <li>
            <t>Component attacks.</dd>
  <dt>Component message forgery attacks: A attacks:</dt><dd>A forgery attack refers to a
  case where an adversary attempts to forge a (non-hybrid) signature on a
  message using the public key associated with a component algorithm. An A
  common example of such an attack would be a quantum attacker compromising
  the key associated with a traditional component algorithm and forging a
  message and signature pair.  Message forgery attacks may be formalized with
  experiments such as
existential unforgeability the Existential Unforgeability under chosen-message attack Chosen Message Attack
  (EUF-CMA) <xref target="EUFCMA"/>, while the difference introduced in
  component message forgery attacks is that the key is accepted for both
  hybrid and single algorithm use. Further
discussions on discussion of this appear under appears in
  <xref target="euf-cma-challenges"/>.</t>
          </li>
        </ul> target="euf-cma-challenges"/>.</dd>
</dl>
      </section>
      <section anchor="motivation">
        <name>Motivation for Use of Hybrid Signature Schemes</name>
        <t>Before diving into the design goals for hybrid digital signatures, it is
worth taking a look at motivations for them. As many of the arguments hold in
general for hybrid algorithms, we again refer to <xref target="I-D.ietf-tls-hybrid-design"/>
that target="RFC9954"/>,
which summarizes these well. In addition, we explicate the motivation for
hybrid signatures here.</t>
        <section anchor="complexity">
          <name>Complexity</name>
<!-- [rfced] Is "CRYSTALS-DILITHIUM" another name for "ML-DSA"? Or are they
separate schemes? Please review and let us know if/how this text may be clarified.

Current:
   For example, the
   signature scheme Module-Lattice-Based Digital Signature Algorithm
   (ML-DSA) [MLDSA] (also known as CRYSTALS-DILITHIUM) follows the well-
   known Fiat-Shamir transform [FS] to construct the signature scheme
   but also relies on rejection sampling that is known to give cache
   side channel information (although this does not lead to a known
   attack).

Section 1.2 of [MLDSA] (FIPS 204) states the following about ML-DSA
and CRYSTALS-DILITHIUM:
   ML-DSA is derived from one of the selected schemes, CRYSTALS-DILITHIUM
   [5 , 6 ], and is intended to protect sensitive U.S. Government
   information well into the foreseeable future, including after the
   advent of cryptographically relevant quantum computers. For the
   differences between ML-DSA and CRYSTALS- DILITHIUM, see Appendix D.
-->

          <t>Next-generation algorithms and their underlying hardness assumptions are
often more complex than traditional algorithms. For example, the signature
scheme ML-DSA Module-Lattice-Based Digital Signature Algorithm (ML-DSA) <xref target="MLDSA"/> (also known as CRYSTALS-DILITHIUM) follows the
well-known Fiat-Shamir transform <xref target="FS"/> to construct the signature scheme, scheme but
also relies on rejection sampling that is known to give cache side channel
information (although this does not lead to a known attack).  Likewise, the
signature scheme Falcon FALCON <xref target="FALCON"/> uses complex sampling during signature
generation. Furthermore, attacks against the next-generation multivariate
schemes Rainbow <xref target="RAINBOW"/> and GeMSS Great Multivariate Short Signature (GeMSS) <xref target="GEMSS"/> might raise concerns for
conservative adopters of other algorithms, which could hinder adoption.</t>
          <t>As such, some next-generation algorithms carry a higher risk of
implementation mistakes and revision of parameters compared to traditional
algorithms, such as RSA. RSA is a relatively simple algorithm to understand
and explain, yet during its existence and use use, there have been multiple
attacks and refinements, such as adding requirements to how padding and keys
are chosen, and implementation issues issues, such as cross-protocol attacks (e.g.,
component algorithm forgeries).  Thus, even in a relatively simple algorithm algorithm,
subtleties and caveats on implementation and use can arise over time. Given
the complexity of next generation next-generation algorithms, the chance of such discoveries
and caveats needs to be taken into account.</t>
          <t>Of note, some next-generation algorithms have received considerable analysis,
for example, following attention gathered during the NIST Post-Quantum
Cryptography Standardization Process <xref target="NIST_PQC_FAQ"/>.  However, if and when
further information on caveats and implementation issues come to light, it is
quite possible that vulnerabilities will represent a weakening of security
rather than a full "break". Such weakening may also be offset if a hybrid
approach has been used.</t>
        </section>
        <section anchor="time">
          <name>Time</name>
          <t>In large systems, including national systems, space systems, large healthcare
support systems, and critical infrastructure, acquisition and procurement
time can be measured in years years, and algorithm replacement may be difficult or
even practically impossible. Long-term commitment creates further urgency for
immediate post-quantum algorithm selection, for example example, when generating root
certificates with their long validity windows.  Additionally, for some
sectors, future checks on past authenticity plays a role (e.g., many legal,
financial, auditing, and governmental systems).  This means there is a need
to transition some systems to post-quantum signature algorithms imminently.
However, as described above, there is a need to remain aware of potential,
hidden subtleties in next-generation algorithms' resistance to standard
attacks, particularly in cases where it is difficult to replace algorithms.
This combination of time pressure and complexity drives some transition
designs towards hybridization.</t>
        </section>
      </section>
      <section anchor="goals">
        <name>Goals</name>
        <t>There are various security and usability goals that can be achieved through
hybridization. The following provides a summary of these goals, goals while also
noting where goals are in conflict, i.e., that achievement of one goal
precludes another, such as backwards compatibility.</t>
        <section anchor="hybrid-authentication">
          <name>Hybrid Authentication</name>

          <t>One goal of hybrid signature schemes is security. As defined in <xref target="RFC9794"/>,
ideally a hybrid signature scheme can achieve 'hybrid authentication' authentication', which
is the property that (cryptographic) authentication is achieved by the hybrid
signature scheme scheme, provided that a least one component signature algorithm
remains 'secure'. There might be, however, other goals in competition with
this one, such as backward-compatibility - backwards compatibility -- referring to the property where a
hybrid signature may be verified by only verifying one component signature
(see description below). Hybrid authentication is an umbrella term that
encompasses more specific concepts of hybrid signature security, such as
'hybrid unforgeability' described next.</t>
          <section anchor="hybrid-unforgeability">
            <name>Hybrid Unforgeability</name>

<!-- [rfced] The second sentence below seems to be saying the same thing as
the first. Should the second sentence be removed?

Current:
   Hybrid unforgeability is a specific type of hybrid authentication,
   where the security assumption for the scheme (e.g., EUF-CMA) is
   maintained as long as at least one of the component schemes maintains
   that security assumption.  We call this notion 'hybrid
   unforgeability'; it is a specific type of hybrid authentication.

Perhaps:
   Hybrid unforgeability is a specific type of hybrid authentication,
   where the security assumption for the scheme (e.g., EUF-CMA) is
   maintained as long as at least one of the component schemes maintains
   that security assumption.
-->

<!-- [rfced] For the ease of the reader, may we update "description below" and
"discussion below" to a section number? If so, please confirm that
Section 1.3.5 is correct.

Original:
   There might be, however, other goals in competition with this one,
   such as backward-compatibility - referring to the property where a
   hybrid signature may be verified by only verifying one component
   signature (see description below).
   ...
   For more details, we refer to our discussion below.

Perhaps:
   There might be, however, other goals in competition with this one,
   such as backward compatibility - referring to the property where a
   hybrid signature may be verified by only verifying one component
   signature (see Section 1.3.5).
   ...
   For more details, refer to Section 1.3.5.
-->

<!-- [rfced] We are having trouble understanding the first part of this
sentence. Would revising as shown below improve clarity while retaining
the intended meaning?

Original:
   Use cases where a hybrid scheme is used with, e.g., EUF-CMA security
   assumed for only one component scheme generally use hybrid techniques
   for their 'functional transition' pathway support.
   ...
   In contrast, use cases where a hybrid scheme is used with e.g., EUF-
   CMA security assumed for both component schemes without
   prioritisation between them can use hybrid techniques for both
   functional transition and security transition ...

Perhaps:
   In some use cases, a hybrid scheme is used with (for example) EUF-CMA security
   assumed for only one component scheme; these cases generally use hybrid techniques
   for their 'functional transition' pathway support.
   ...
   In contrast, in other use cases, a hybrid scheme is used with (for example) EUF-
   CMA security assumed for both component schemes without
   prioritisation between them; these cases can use hybrid techniques for both
   functional transition and security transition ...
-->

            <t>Hybrid unforgeability is a specific type of hybrid authentication, where the
security assumption for the scheme, e.g. EUF-CMA, scheme (e.g., EUF-CMA) is maintained as long as at
least one of the component schemes maintains that security assumption. We
call this notion 'hybrid unforgeability'; it is a specific type of hybrid
authentication. For example, the concatenation combiner in <xref target="HYBRIDSIG"/> is
'hybrid unforgeable'. As mentioned above, this might be incompatible with
backward-compatibility,
backwards compatibility, where the EUF-CMA security of the hybrid signature
relies solely on the security of one of the component schemes instead of
relying on both, e.g., the dual message combiner using nesting in
	    <xref target="HYBRIDSIG"/>. For more details, we refer to our the discussion below.</t>
            <t>Use cases where a hybrid scheme is used with, e.g., EUF-CMA security assumed
for only one component scheme generally use hybrid techniques for their
'functional transition' pathway support.  For example, hybrid signatures may
be used as a transition step for gradual post-quantum adoption, adoption while
ensuring interoperability when a system includes both verifiers that only
support traditional signatures and verifiers that have been upgraded to
support post-quantum signatures.</t>
            <t>In contrast, use cases where a hybrid scheme is used with with, e.g., EUF-CMA
security assumed for both component schemes without prioritisation prioritization between
them can use hybrid techniques for both functional transition and security
transition (i.e., a transition to ensure security even if it may not be
known which algorithm should be relied upon).</t>
          </section>
        </section>
        <section anchor="proof-composability">
          <name>Proof Composability</name>
          <t>Under proof composability, the component algorithms are combined in such a
way that it is possible to prove a security reduction from the security
properties of a hybrid signature scheme to the properties of the respective
component signature schemes and, potentially, other building blocks such as
hash functions, key derivation functions, etc. Otherwise, an entirely new
proof of security is required, and there is a lack of assurance that the
combination builds on the standardization processes and analysis performed to
date on component algorithms. The resulting hybrid signature would be, in
effect, an entirely new algorithm of its own. The more the component
signature schemes are entangled, the more likely it is that an entirely new
proof is required, thus not meeting proof composability.</t>
        </section>
        <section anchor="weak-non-separability">
          <name>Weak Non-Separability</name>
          <t>Non-Separability

<!-- [rfced] How may we update "algorithms/the" here?

Original:
   For instance, this can intuitively be seen in
   cases of a message containing a context note on hybrid
   authentication, that is then signed by all component algorithms/the
   hybrid signature scheme.

Perhaps:
   For instance, this can intuitively be seen in
   cases of a message containing a context note on hybrid
   authentication, that is then signed by all component algorithms in the
   hybrid signature scheme.
-->

          <t>Non-separability was one of the earliest properties of hybrid digital
signatures to be discussed <xref target="HYBRIDSIG"/>. It was defined as the guarantee that
an adversary cannot simply "remove" one of the component signatures without
evidence left behind. For example, there are artifacts that a carefully
designed verifier may be able to identify, identify or that are identifiable in later
audits. This was later termed Weak Non-Separability (WNS)
<xref target="HYBRIDSIGDESIGN"/>. Note that WNS does not restrict an adversary from
potentially creating a valid component digital signature from a hybrid one (a
signature stripping attack), attack) but rather implies that such a digital signature
will contain artifacts of the separation. Thus, authentication that is
normally assured under correct verification of digital signature(s), signature(s) is now
potentially also reliant on further investigation on the receiver side that
may extend well beyond traditional signature verification behavior. For
instance, this can intuitively be seen in cases of a message containing a
context note on hybrid authentication, authentication that is then signed by all component
algorithms/the hybrid signature scheme. If an adversary removes one component
signature but not the other, then artifacts in the message itself point to
the possible existence of a hybrid signature such as a label stating, stating "this
message must be hybrid signed". hybrid-signed". This might be a counter measure countermeasure against
stripping attacks if the verifier expects a hybrid signature scheme to have
this property. However, it places the responsibility of signature validity
not only on the correct format of the message, as in a traditional signature
security guarantee, but the precise content thereof.</t>
        </section>
        <section anchor="strong-non-separability">
          <name>Strong Non-Separability</name>
          <t>Strong Non-Separability (SNS) is a stronger notion of WNS, which is introduced in
<xref target="HYBRIDSIGDESIGN"/>. SNS guarantees that an adversary cannot take as input a
hybrid signature (and message) as input and output a valid component signature (and
potentially different message) that will verify correctly. In other words,
separation of the hybrid signature into component signatures implies that the
component signature will fail verification (of the component signature
scheme) entirely. Therefore, authentication is provided by the sender to the
receiver through correct verification of the digital signature(s), as in
traditional signature security experiments. It is not dependent on other
components, such as message content checking, or protocol level protocol-level aspects, such
as public key provenance. As an illustrative example distinguishing WNS from
SNS, consider the case of component algorithms <tt>Sigma_1.Sign</tt> and
<tt>Sigma_2.Sign</tt> where the hybrid signature is computed as a concatenation
<tt>(sig_1, sig_2)</tt>, where <tt>sig_1 = Sigma_1.Sign(hybridAlgID, m)</tt> and <tt>sig_2 =
Sigma_2.Sign(hybridAlgID, m)</tt>.  In this case, a new message <tt>m' =
(hybridAlgID, m)</tt> along with signature <tt>sig_1</tt> and <tt>Sigma_1.pk</tt>, with the
hybrid artifact embedded in the message instead of the signature, could be
correctly verified. The separation would be identifiable through further
investigation, but the signature verification itself would not fail. Thus,
this case shows WNS (assuming the verification algorithm is defined
accordingly) but not SNS.</t>
          <t>Some work <xref target="I-D.ietf-lamps-pq-composite-sigs"/> has looked at reliance on the
public key certificate chains to explicitly define hybrid use of the public
key. Namely,
key, namely that <tt>Sigma_1.pk</tt> cannot be used without <tt>Sigma_2.pk</tt>. This
implies pushing the hybrid artifacts into the protocol and system level and a
dependency on the security of other verification algorithms (namely those in
the certificate chain). This further requires that security analysis of a
hybrid digital signature requires analysis of the key provenance, i.e., not
simply that a valid public key is used but how its hybridization and hybrid
artifacts have been managed throughout the entire chain. External
dependencies such as this may imply hybrid artifacts lie outside the scope of
the signature algorithm itself. SNS may potentially be achievable based on
dependencies at the system level.</t>
        </section>
        <section anchor="backwardsforwards-compatibility">
          <name>Backwards/Forwards
          <name>Backwards and Forwards Compatibility</name>
          <t>Backwards compatibility refers to the property where a hybrid signature may
be verified by only verifying one component signature, allowing the scheme to
be used by legacy receivers. In general, this means verifying the traditional
component signature scheme, potentially ignoring the post-quantum signature
entirely. This provides an option to transition sender systems to
post-quantum algorithms while still supporting select legacy
receivers. Notably, this is a verification property; the sender has provided
a hybrid digital signature, but the verifier is allowed, due to internal
policy and/or implementation, to only verify one component
signature.</t>
          <t>Forwards compatibility has also been a consideration in hybrid proposals
<xref target="I-D.becker-guthrie-noncomposite-hybrid-auth"/>. Forward Forwards compatibility assumes
that hybrid signature schemes will be used for some time, time but that eventually
all systems will transition to use only one (particularly, only one
post-quantum) algorithm. As this is very similar to backwards compatibility,
it also may imply separability of a hybrid algorithm; however, it could also
simply imply capability to support separate component signatures. Thus, the
key distinction between backwards and forwards compatibility is that
backwards compatibility may be needed for legacy systems that cannot use
and/or process hybrid or post-quantum signatures, whereas in forwards
compatibility
compatibility, the system has those capabilities and can choose what to
support (e.g., for efficiency reasons).</t>
          <t>As noted in <xref target="I-D.ietf-tls-hybrid-design"/>, ideally, forward/backward
          <t>Ideally, backwards and forwards
compatibility is achieved using redundant information as little as possible.</t> possible, as noted in <xref target="RFC9954"/>.</t>
        </section>
        <section anchor="simultaneous-verification">
          <name>Simultaneous Verification</name>
          <t>Simultaneous Verification (SV) builds on SNS and was first introduced in
<xref target="HYBRIDSIGDESIGN"/>. SV requires that not only is the entire hybrid signature
(e.g., all component signature elements) needed to achieve a successful
verification present in the signature presented for verification, verification but also
that verification of both component algorithms occurs roughly simultaneously.
Namely, "missing" information needs to be computed by the verifier so that a
normally functioning verification algorithm cannot "quit" the verification
process before the hybrid signature elements attesting for both component
algorithms are verified. This may additionally cover some error-injection and
similar attacks, where an adversary attempts to make an otherwise honest
verifier skip component algorithm verification. SV mimics traditional digital
signatures guarantees, essentially ensuring that the hybrid digital signature
behaves as a single algorithm vs. two separate component
stages. Alternatively phrased, under an SV guarantee guarantee, it is not possible for
an otherwise honest verifier to initiate termination of the hybrid
verification upon successful verification of one component algorithm without
also knowing if the other component succeeded. Note that SV does not prevent
dishonest verification, such as if a verifier maliciously implements a
customized verification algorithm that is designed with intention to subvert
the hybrid verification process or skips signature verification altogether.</t>
        </section>
        <section anchor="hybrid-generality">
          <name>Hybrid Generality</name>
          <t>Hybrid

<!-- [rfced] Should 'component digital signatures "categories"' be updated to
use singular 'signature' as shown in Perhaps A, recast as shown in
Perhaps B, or revised in some other way?

Original:
   Hybrid generality means that a general signature combiner is defined,
   based on inherent and common structures of component digital
   signatures "categories."

Perhaps A:
   Hybrid generality means that a general signature combiner is defined
   based on inherent and common structures of component digital
   signature "categories".

Perhaps B:
   Hybrid generality means that a general signature combiner is defined
   based on inherent and common structures of "categories" of the component digital
   signatures.
-->

          <t>Hybrid generality means that a general signature combiner is defined based
on inherent and common structures of component digital signatures
"categories". For instance, since multiple signature schemes use a
Fiat-Shamir Transform, transform, a hybrid scheme based on the transform can be made
that is generalizable to all such signatures. Such generality can also result
in simplified constructions constructions, whereas more tailored hybrid variants might be
more efficient in terms of sizes and performance.</t>
        </section>
        <section anchor="high-performance">
          <name>High Performance</name>
          <t>Similarly
          <t>Similar to performance goals noted for hybridization of other cryptographic
components <xref target="I-D.ietf-tls-hybrid-design"/> target="RFC9954"/>, hybrid signature constructions are
expected to be as performant as possible. For most hybrid signatures signatures, this
means that the computation time should only minimally exceed the sum of the
component signature computation time. It is noted that performance of any
variety may come at the cost of other properties, such as hybrid generality.</t>
        </section>
        <section anchor="high-space-efficiency">
          <name>High Space Efficiency</name>
          <t>Similarly
<!-- [rfced] We could not find any mention of "space" in
draft-ietf-tls-hybrid-design (RFC-to-be 9954). Please review and let us
know how this citation may be updated.

Original:
   Similarly to space considerations in [I-D.ietf-tls-hybrid-design],
   hybrid signature constructions are expected to be as space performant
   as possible.
-->
          <t>Similar to space considerations in <xref target="I-D.ietf-tls-hybrid-design"/>, target="RFC9954"/>, hybrid
signature constructions are expected to be as space performant as
possible. This includes messages (as they might increase if artifacts are
used), public keys, and the hybrid signature.  For the hybrid signature, size
should no more than minimally exceed the signature size of the two component
signatures. In some cases, it may be possible for a hybrid signature to be
smaller than the concatenation of the two component signatures.</t>
        </section>
        <section anchor="minimal-duplicate-information">
          <name>Minimal Duplicate Information</name>
          <t>Duplicated information should be avoided when possible, as a general point of
efficiency. This might include repeated information in hybrid certificates or
in the communication of component certificates in additional addition to hybrid
certificates (for example, to achieve backwards/forwards-compatibility) backwards and forwards compatibility) or
sending multiple public keys or signatures of the same component algorithm.</t>
        </section>
      </section>
    </section>
    <section anchor="non-separability-spectrum">
      <name>Non-Separability Spectrum</name>
      <t>Non-separability is not a singular definition but rather is a scale, scale
representing <tt>degrees</tt> of separability hardness, visualized in
      <xref target="fig-spectrum-non-separability"/>.</t>

<!-- [rfced] We made a few changes to Figures 1 and 2 (e.g., updated
spacing, added articles, and included punctuation). Please review.
-->

      <figure anchor="fig-spectrum-non-separability">
        <name>Spectrum of non-separability Non-Separability from weakest Weakest to strongest.</name> Strongest</name>
        <artwork><![CDATA[
|-----------------------------------------------------------------------------|
|**No Non-Separability**
   | no artifacts exist
|-----------------------------------------------------------------------------|
|**Weak Non-Separability** ----------------------------------------------------------|
   | *No Non-Separability*
   |
   | No artifacts exist.
   | ----------------------------------------------------------|
   | *Weak Non-Separability*
   |
   | Artifacts exist in the message, signature, system,
   | application, or protocol protocol.
   | ----------------------------------------------------------------------------|
|**Strong Non-Separability** ----------------------------------------------------------|
   | artifacts *Strong Non-Separability*
   |
   | Artifacts exist in the hybrid signature signature.
   | ----------------------------------------------------------------------------|
|**Strong ----------------------------------------------------------|
   | *Strong Non-Separability w/ with Simultaneous Verification** Verification*
   | artifacts
   | Artifacts exist in the hybrid signature signature, and verification
   | or failure of both
| components occurs simultaneously simultaneously.
   | ----------------------------------------------------------------------------|
▼
]]></artwork> ----------------------------------------------------------|
   ▼]]></artwork>
      </figure>
      <t>At one end of the spectrum are schemes in which one of the component
signatures can be stripped away with the verifier not being able to detect
the change during verification. An example of this includes simple
concatenation of signatures without any artifacts used. Nested signatures
(where a message is signed by one component algorithm and then the
message-signature combination is signed by the second component algorithm)
may also fall into this category, dependent on whether the inner or outer
      signature is stripped off without any artifacts remaining.</t>

<!-- [rfced] Will readers understand what is meant by "hybrid" and "hybrids"
(noun) in these sentences? Should these be updated to "hybrid signature"
and "hybrid signatures" (or to something else), or is the current clear?

Original:
   Under Weak
   Non-Separability, if one of the component signatures of a hybrid is
   removed artifacts of the hybrid will remain (in the message,
   signature, or at the protocol level, etc.).
   ...
   Note that in this latter case, it is not
   possible for an adversary to strip one of the component signatures or
   use a component of the hybrid to create a forgery for a component
   algorithm.
   ...
   applies equally to any guidance or
   policy direction that specifies that at least one component algorithm
   of the hybrid has passed some certification type while not specifying
   requirements on the other component.
   ...
   however, we use it as motivation to highlight some points
   that implementers of hybrids may wish to consider when following any
   guidance documents that specify ...
   ...
   This type of need for approval (i.e., a requirement that an
   implementer is looking to follow regarding approval or certification
   of the software module implementation of a hybrid or its component
   algorithms) can drive some logistical decisions on what types of
   hybrids an implementer should consider.
   ...
   If the hybrid signature is
   stripped, such that a single component signature is submitted to a
   verification algorithm for that component along with the message that
   was signed by the hybrid, the result would be an EUF-CMA forgery for
   the component signature.
   ...
   Thus, if EUF-CMA security for hybrids is considered to be informally
   defined in the straightforward way as ...
-->

<!-- [rfced] How may we clarify "message/inner" here?

Original:
   In another example, under nested signatures the verifier
   could be tricked into interpreting a new message as the message/inner
   signature combination and verify only the outer signature.

Perhaps A:
   In another example, under nested signatures, the verifier
   could be tricked into interpreting a new message as the message and inner
   signature combination and verify only the outer signature.

Perhaps B:
   In another example, under nested signatures, the verifier
   could be tricked into interpreting a new message as the combination of the
   message and inner signature and verify only the outer signature.
-->

      <t>Next on the spectrum are weakly non-separable signatures. Under Weak
Non-Separability, if one of the component signatures of a hybrid is removed removed,
artifacts of the hybrid will remain (in the message, in the signature, or at the
protocol level, etc.). This may enable the verifier to detect if a component
signature is stripped away from a hybrid signature, but that detectability
depends highly on the type of artifact and permissions.  For instance, if a
message contains a label artifact "This message must be signed with a hybrid
signature"
signature", then the system must be allowed to analyze the message contents
for possible artifacts. Whether a hybrid signature offers (Weak/Strong)
Non-Separability might also depend on the implementation and policy of the
protocol or application the hybrid signature is used in on the verifier
side. Such policies may be further ambiguous to the sender, meaning that the
type of authenticity offered to the receiver is unclear.  In another example,
under nested signatures signatures, the verifier could be tricked into interpreting a new
message as the message/inner signature combination and verify only the outer
signature.  In this case, the inner signature is an artifact.</t>
      <t>Third on the scale is the Strong Non-Separability notion, in which
separability detection is dependent on artifacts in the signature
itself. Unlike in Weak Non-Separability, where artifacts may be in the actual
message, the certificate, or in other non-signature components, this notion
more closely ties to traditional algorithm security notions (such as EUF-CMA)
where security is dependent on the internal construct of the signature
algorithm and its verification. In this type, the verifier can detect
artifacts on an algorithmic level during verification. For example, the
signature itself may encode the information that a hybrid signature scheme is
used. Examples of this type may be found in <xref target="HYBRIDSIGDESIGN"/>.</t>
      <t>For schemes achieving the most demanding security notion, Strong
Non-Separability with Simultaneous Verification, verification succeeds
only when both of the component signatures are present and the
verifier has verified both signatures. Moreover, no information is leaked to
the receiver during the verification process on the possible validity of the
component signatures until both verify (or verification failure may or may
not be attributable to a specific component algorithm). This construct most
closely mirrors traditional digital signatures where, assuming that the
verifier does verify a signature at all, the result is either a positive
verification of the full signature or a failure if the signature is not
valid. For fused hybrid signatures, a <tt>full signature</tt> implies the fusion of
both component algorithms, and therefore algorithms; therefore, this type of construction has the
potential to achieve the strongest non-separability notion notion, which  ensures an
all-or-nothing approach to verification, regardless of adversarial
action. Examples of algorithms providing this type of security can be found
in <xref target="HYBRIDSIGDESIGN"/>.</t>
    </section>
    <section anchor="art-spectrum">
      <name>Artifacts</name>
      <t>Hybridization benefits from the presence of artifacts as evidence of the
sender's intent to decrease the risk of successful stripping attacks. This,
however, depends strongly on where such evidence resides (e.g., in the
message, in the signature, or somewhere on the protocol level instead of at the
algorithmic level). Even commonly discussed hybrid approaches, such as
concatenation, are not inherently tied to one type of security (e.g., WNS or
SNS). This can lead to ambiguities when comparing different approaches and
assumptions about security or lack thereof. Thus, in this section section, we cover
artifact locations and also walk through a high-level comparison of a few
hybrid categories to show how artifact location can differ within a given
approach. Artifact location is tied to non-separability notions as described above; thus thus,
the selection of a given security guarantee and general hybrid approach must
also include finer grained a finer-grained selection of artifact placement.</t>
      <section anchor="art-sep">
        <name>Artifacts vs. Separability</name>

<!--[rfced] To improve readability, may we update the second sentence below as
follows? The first sentence is included for context.

Original:
   The verifier could indeed ignore the artifact, hence the scheme achieving
   only weak non-separability and not strong non-separability.  It is
   rather that an artifact exists that could be identified if an
   investigation occurred, etc.

Perhaps:
   The verifier could indeed ignore the artifact, resulting in the scheme
   achieving only weak non-separability and not strong non-separability. However,
   an existing artifact could be identified if an investigation occurred.
-->

        <t>Note that non-separability is a security notion of the signature scheme and
not directly related to artifacts – -- however, artifacts may be used for detection of
separation, however.
separation. For instance, under strong non-separability, the scheme
would fail verification if separation occurs, while for weak non-separability non-separability,
some artifacts exist if separation occurs but verification would not
necessarily fail. The verifier could indeed ignore the artifact, hence resulting in the
scheme achieving only weak non-separability and not strong
non-separability. It is rather that an artifact exists that could be
identified if an investigation occurred, etc.  Under weak non-separability,
detection of separation may depend on non-cryptographic configurations or
other dependencies. Also, strong non-separability and weak non-separability
are properties of the signature scheme – -- artifacts are not necessarily in the
signature and may appear in the signed message, the certificate, the
protocol, or policy (hence them not necessarily being related to the strong
non-separability and weak non-separablity non-separability security notions). Artifacts may
still be useful (albeit dependent on system configurations) even if separable
signatures are used.</t>
      </section>
      <section anchor="art-locations">
        <name>Artifact Locations</name>
        <t>There are a variety of artifact locations possible, ranging from within the
message to the signature algorithm to the protocol level and even into
policy, as shown in <xref target="tab-artifact-location"/>.  For example, one artifact
location could be in the message to be signed, e.g., containing a label
artifact.  Depending on the hybrid type, it might be possible to strip this
away. For example, a quantum attacker could strip away the post-quantum
signature of a concatenated dual signature, and, being able to forge the
traditional signature, it could remove the label artifact from the message as
well. So, for many applications and threat models, adding an artifact in the
message might be insufficient under stripping attacks.  Another artifact
location could be in the public key certificates as described in
<xref target="I-D.ietf-lamps-pq-composite-sigs"/>. In such a case, the artifacts are still
present even if a stripping attack occurs. In yet another case, artifacts may
be present through the fused hybrid method, thus making them part of the
signature at the algorithmic level. Note that in this latter case, it is not
possible for an adversary to strip one of the component signatures or use a
component of the hybrid to create a forgery for a component algorithm. Such
signatures provide SNS. This consequently Consequently, this also implies that the artifacts of
hybridization are absolute in that verification failure would occur if an
adversary tries to remove them.</t>
        <t>Eventual security analysis may be a consideration in choosing between
levels. For example, if the security of the hybrid scheme is dependent on
system policy, then cryptographic analysis must necessarily be reliant on
specific policies, and it may not be possible to describe a scheme's security
in a standalone sense.  In this case, it is necessary to consider the
configuration of a particular implementation or use to assess security, which
could increase the risk of unknown and unanticipated vulnerabilities,
	regardless of the algorithms in use.</t>

        <table anchor="tab-artifact-location">
          <name>Artifact placement levels</name> Placement Levels</name>
          <thead>
            <tr>
              <th align="left">Location of Artifacts of Hybrid Intent</th>
              <th align="left">Level</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Signature                                 </td> align="left">Signature</td>
              <td align="left">Algorithm</td>
            </tr>
            <tr>
              <td align="left">Certificate</td>
              <td align="left">Protocol</td>
            </tr>
            <tr>
              <td align="left">Algorithm agreement / negotiation</td>
              <td align="left">Protocol</td>
            </tr>
            <tr>
              <td align="left">Message                                    </td> align="left">Message</td>
              <td align="left">Policy</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="art-spectrum-example">
        <name>Artifact Location Comparison Example</name>
        <t>Here we provide a high-level example of how artifacts can appear in different
locations even within a single, common approach. We look at the following
categories of approaches: concatenation, nesting, and fusion.  This is to
illustrate that a given approach does not inherently imply a specific
non-separability notion and that there are subtleties to the selection
decision, since hybrid artifacts are related to non-separability guarantees.
Additionally, this comparison highlights how artifacts artifact placement can be
identical in two different hybrid approaches.</t>
        <t>We briefly summarize the hybrid approach categories (concatenation, nesting,
and fusion) for clarity in description, description before showing how each one may have
artifacts in different locations in <xref target="tab-hybrid-approach-categories"/>.</t>
        <ul spacing="normal">
          <li>
            <t>Concatenation: variants Variants of hybridization where, for component algorithms
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calculated as a
concatenation <tt>(sig_1, sig_2)</tt> such that <tt>sig_1 = Sigma_1.Sign(hybridAlgID ||
m)</tt> and <tt>sig_2 = Sigma_2.Sign(hybridAlgID || m)</tt>.</t>
          </li>
          <li>
            <t>Nesting: variants Variants of hybridization where where, for component algorithms
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calculated in a
layered approach as <tt>(sig_1, sig_2)</tt> such that, e.g., <tt>sig_1 =
Sigma_1.Sign(hybridAlgID || m)</tt> and <tt>sig_2 = Sigma_2.Sign(hybridAlgID || (m ||
sig_1))</tt>.</t>
          </li>
          <li>
            <t>Fused hybrid: variants Variants of hybridization hybridization, where for component algorithms
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calculated to
generate a single hybrid signature <tt>sig_h</tt> that cannot be cleanly separated
to form one or more valid component constructs. For example, if both
signature schemes are signatures schemes constructed through the Fiat-Shamir
transform, the component signatures would include responses r_1 and r_2 and
challenges c_1 and c_2, where c_1 and c_2 are hashes computed over the
respective commitments comm_1 and comm_2 (and the message).  A fused hybrid
signature could consist of the component responses, responses r_1 and r_2 and a
challenge c that is computed as a hash over both commitments, i.e., c =
Hash((comm_1 || comm_2) || Hash2(message)).  As such, c does not belong to
either of the component signatures but rather both, meaning that the
signatures are 'entangled'.</t>
          </li>
        </ul>
        <table anchor="tab-hybrid-approach-categories">
          <name>Artifact locations depending Locations Depending on the hybrid signature type</name> Hybrid Signature Type</name>
          <thead>
            <tr>
              <th align="left">#</th>
              <th align="left">Location of artifacts Artifacts of hybrid intent</th> Hybrid Intent</th>
              <th align="left">Category</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left"> </td>
              <td align="left"> </td> align="left"/>
              <td align="left"/>
              <th align="left">
                <strong>Concatenated</strong></td>
                <strong>Concatenated</strong></th>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">None</td>
              <td align="left">No label in message, public keys are in separate certs</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">In message</td>
              <td align="left">Label in message, public keys are in separate certs</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">In cert</td>
              <td align="left">No label in message, public keys are in combined cert</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">In message and cert</td>
              <td align="left">Label in message, public keys are in combined cert</td>
            </tr>
            <tr>
              <td align="left"> </td>
              <td align="left"> </td> align="left"/>
              <td align="left"/>
              <th align="left">
                <strong>Nested</strong></td>
                <strong>Nested</strong></th>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">In message</td>
              <td align="left">Label in message, public keys are in separate certs</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">In cert</td>
              <td align="left">No label in message, public keys are in combined cert</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">In message and cert</td>
              <td align="left">Label in message, public keys are in combined cert</td>
            </tr>
            <tr>
              <td align="left"> </td>
              <td align="left"> </td> align="left"/>
              <td align="left"/>
              <th align="left">
                <strong>Fused</strong></td>
                <strong>Fused</strong></th>
            </tr>
            <tr>
              <td align="left">8</td>
              <td align="left">In signature</td>
              <td align="left">Public keys are in separate certs</td>
            </tr>
            <tr>
              <td align="left">9</td>
              <td align="left">In signature and message</td>
              <td align="left">Label in message, public keys are in separate certs</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">In signature and cert</td>
              <td align="left">Public keys are in combined cert</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">In signature and message and cert</td>
              <td align="left">Label in message, public keys are in combined cert</td>
            </tr>
          </tbody>
        </table>

<!-- [rfced] Will "As can be seen" be clear to readers in these two sentences?
Could it be updated to "As shown in Table 1" in the first sentence and
removed in the second sentence?

Original:
   As can be seen, while concatenation may appear to refer to a single
   type of combiner, there are in fact several possible artifact
   locations depending on implementation choices.
   ...
   However, as can be seen, this does not imply that
   every implementation using concatenation fails to achieve non-
   separability.

Perhaps:
   As shown in Table 1, while concatenation may appear to refer to a single
   type of combiner, there are in fact several possible artifact
   locations depending on implementation choices.
   ...
   However, this does not imply that
   every implementation using concatenation fails to achieve non-
   separability.
-->

        <t>As can be seen, while concatenation may appear to refer to a single type of
combiner, there are in fact several possible artifact locations depending on
implementation choices. Artifacts help to support detection in the case of
stripping attacks, which means that different artifact locations imply
different overall system implementation considerations to be able to achieve
such detection.</t>
        <t>Case 1 provides the weakest guarantees of hybrid identification, as there are
no prescribed artifacts and therefore non-separability is not achieved.
However, as can be seen, this does not imply that every implementation using
concatenation fails to achieve non-separability. Thus, it is advisable for
implementors
implementers to be transparent about artifact locations.</t>
        <t>In cases 2 and 5 5, the artifacts lie within the message. This is notable as the
authenticity of the message relies on the validity of the signature, and the
artifact location means that the signature in turn relies on the authentic
content of the message (the artifact label). This creates a risk of circular
dependency. Alternative approaches approaches, such as cases 3, 4, 6 6, and 7 7, solve this
circular dependency by provisioning keys in a combined certificate.</t>
        <t>Another observation from this comparison is that artifact locations may be
similar among some approaches. For instance, case cases 3 and case 6 both contain
artifacts in the certificate. Naturally Naturally, these examples are high-level examples and
further specification on concrete schemes in the categories are needed before
prescribing non-separability guarantees to each, but this does indicate how
there could be a strong similarity between such guarantees.  Such comparisons
allow for a systematic decision process, where security is compared and
identified and,
identified, and if schemes are similar in the desired security goal, then
decisions between schemes can be based on performance and implementation
ease.</t>
        <t>A final observation that this type of comparison provides is how various
combiners may change the security analysis assumptions in a system. For
instance, cases 3, 4, 6, and 7 all push artifacts - -- and therefore the
signature validity - -- into the certificate chain. Naturally Naturally, the entire chain
must then also use a similar combiner if a straightforward security argument
is to be made. Other cases, such as 8, 9, 10, and 11 11, put artifacts within the
signature itself, meaning that these bear the closest resemblance to
traditional schemes where message authenticity is dependent on signature
validity.</t>
      </section>
    </section>
    <section anchor="need-for-approval-spectrum">
      <name>Need For for Approval Spectrum</name>
      <t>In practice, use of hybrid digital signatures relies on standards where
      applicable. This is particularly relevant in the cases where use of FIPS
(Federal Information Processing Standard) approved FIPS-approved software modules
      is
required,
required but applies equally to any guidance or policy direction that
specifies that at least one component algorithm of the hybrid has passed some
certification type while not specifying requirements on the other component.
NIST provides the following guidance in  <xref target="NIST_PQC_FAQ"/> (emphasis added),</t>
      <ul empty="true">
        <li>
          <t>Assume added):</t>

<!-- [rfced] The quoted text below no longer appears at the URL provided for
[NIST_PQC_FAQ]: https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs.
That page was lasted updated on 19 November 2025.

We found an archived URL from the Internet Archive from 5 July 2022
(the original date used for this reference):
https://web.archive.org/web/20220705163944/https://csrc.nist.gov/Projects/
post-quantum-cryptography/faqs

May we update this reference to use the archived URL?

Original:
   Assume that in a [hybrid] signature, _one signature is generated
   with a NIST-approved signature scheme as specified in FIPS 186,
   while another signature(s) can be generated using different
   schemes_, e.g., ones that are not currently specified in NIST
   standards..._hybrid signatures can be accommodated by current
   standards in FIPS mode, as defined in FIPS 140, provided at least
   one of the component methods is a properly implemented, NIST-
   approved signature algorithm_. For the purposes of FIPS 140
   validation, any signature that is generated by a non-approved
   component scheme would not be considered a security function,
   since the NIST-approved component is regarded as assuring the
   validity of the hybrid signature.  [NIST_PQC_FAQ]
   ...
   [NIST_PQC_FAQ]
           National Institute of Standards and Technology (NIST),
           "Post-Quantum Cryptography FAQs", 5 July 2022,
           <https://csrc.nist.gov/Projects/post-quantum-cryptography/
           faqs>.
-->

<blockquote>Assume that in a [hybrid] signature, <em>one signature is generated
with a NIST-approved signature scheme as specified in FIPS 186, while
another signature(s) can be generated using different schemes</em>, e.g.,
ones that are not currently specified in NIST standards...<em><tt>hybrid standards ... <em><tt>[hybrid] signatures</tt> can be accommodated by current standards in <tt>FIPS mode,</tt> <tt>"FIPS mode"</tt>,
as defined in FIPS 140, provided at least one of the component methods
is a properly implemented, NIST-approved signature algorithm</em>. For the
purposes of FIPS 140 validation, any signature that is generated by a
non-approved component scheme would not be considered a security
function, since the NIST-approved component is regarded as assuring
the validity of the <tt>hybrid</tt> <tt>[hybrid]</tt> signature. <xref target="NIST_PQC_FAQ"/></t>
        </li>
      </ul>
</blockquote>
      <t>This draft document does not define a formal interpretation of the NIST statement;
however, we use it as motivation to highlight some points that implementors implementers
of hybrids may wish to consider when following any guidance documents that
specify that 1) the signature scheme for one of the component algorithms
must be approved and 2) the said algorithm must be a well implemented well-implemented or a
certified implementation. This type of <tt>need for approval</tt> (i.e., a
requirement that an implementor implementer is looking to follow regarding approval or
certification of the software module implementation of a hybrid or its
component algorithms) can drive some logistical decisios decisions on what types of
hybrids an implementor implementer should consider.</t>
      <t>In this respect, there is a <tt>scale of approval</tt> that developers may
consider as to whether they are using at least one approved component
algorithm implementation (<tt>1-out-of-n approved software module</tt>), module</tt>) or
whether every component algorithm implementation is individually approved
(<tt>all approved software module</tt>).</t>
      <t>We provide a scale for the different nuances of <tt>approval</tt> of the hybrid
combiners, where "approval" means that a software implementation of a
component algorithm can be used unmodified for creation of the hybrid
signature. This may be related to whether a hybrid combiner is likely to need
      dedicated certification.</t>

<!-- [rfced] We do not see "Generality" used elsewhere in Section 4. Should it
be removed from the title of Figure 2?

Original:
  Figure 2: Generality / Need for Approval Spectrum

Perhaps:
  Figure 2: Need for Approval Spectrum
-->

      <figure anchor="fig-generality-spectrum">
        <name>Generality / Need for Approval spectrum</name> Spectrum</name>
        <artwork><![CDATA[
   | ---------------------------------------------------------------------------------| ---------------------------------------------------------|
   | *New Algorithm*
   | **New Algorithm**
   | New signature scheme based on a selection of hardness assumptions
   | assumptions.
   |
   | Separate approval needed needed.
   | ---------------------------------------------------------------------------------| ---------------------------------------------------------|
   | **No *No Approved Software Module** Module*
   |
   | Hybrid combiner supports security analysis that can be
   | reduced to
| approved component algorithms, potentially
   | changing the component implementations implementations.
   |
   | Uncertainty about whether separate approval is needed needed.
   | ---------------------------------------------------------------------------------| ---------------------------------------------------------|
   | **1-out-of-n *1-out-of-n Approved Software Module** Module*
   |
   | Combiner supports one component algorithm and
   | implementation in a black-box way
| but potentially
   | changes the other component algorithm implementation(s) implementation(s).
   |
   | No new approval needed if the black-box component
   | (implementation) is approved approved.
   | ---------------------------------------------------------------------------------| ---------------------------------------------------------|
   | **All *All Approved Software Modules** Modules*
   |
   | Hybrid combiner acts as a wrapper, fully independent of
   | the component
| signature scheme implementations implementations.
   |
   | No new approval needed if at least one component
   | implementation is approved approved.
   | ---------------------------------------------------------------------------------|
▼
]]></artwork> ---------------------------------------------------------|
   ▼]]></artwork>
      </figure>

      <t>The first listed "combiner" would be a new construction with a security
reduction to different hardness assumptions but not necessarily to approved
(or even existing) signature schemes. Such a new, singular algorithm relies
on both traditional and next-gen next-generation principles.</t>
      <t>Next,
      <t>Next is a combiner that might take inspiration from existing/approved
signature schemes such that its security can be reduced to the security of
the approved algorithms. The combiner may, however, alter the
implementations.  As such such, it is uncertain whether new approval would be
needed as it might depend on the combiner and changes. Such a case may
potentially imply a distinction between a need for fresh approval of the
algorithm(s) and approval of the implementation(s).</t>
      <t>The 1-out-of-n combiner uses at least one approved algorithm implementation
in a black-box way (i.e., without modification to the software module
implementaton
implementation for that algorithm). It may potentially change the specifics
of the other component algorithm implementations. If the premise is that no
new approval is needed so long as at least one component is approved, then
      this is likely considered sufficient.</t>
      <t>In an all-approved combiner, every algorithm implementation is used in a
black-box way. A concatenation combiner is a simple example (where a
signature is valid if all component signatures are valid). Thus, as all
algorithm implementations are approved, a requirement that at least one of
hybrid component algorithms is approved would be satisfied.</t>
    </section>
    <section anchor="euf-cma-challenges">
      <name>EUF-CMA Challenges</name>
      <t>Unforgeability properties for hybrid signature schemes are more nuanced than
      for single-algorithm schemes.</t>
      <t>Under

<!-- [rfced] Is "game" the correct word choice here? Or would "assumption"
(used earlier in the paragraph) be better?

Original:
   Namely, the most straightforward extension of the traditional EUF-CMA
   security assumption, game would be that an adversary can request hybrid
   signatures for messages of their choosing and succeeds if they are
   able to produce a valid hybrid signature for a message that was not
   part of an earlier request.
-->

      <t>Under the traditional EUF-CMA security assumption, an adversary requests
signatures for messages of their choosing and succeeds if they are able to
produce a valid signature for a message that was not part of an earlier
request. EUF-CMA can be seen as applying to the hybrid signature scheme in
the same way as single-algorithm schemes. Namely, the most straightforward
extension of the traditional EUF-CMA security game would be that an adversary
can request
requests hybrid signatures for messages of their choosing and succeeds if
they are able to produce a valid hybrid signature for a message that was not
part of an earlier request. However, this has several layers of nuance under
a hybrid construct.</t>
      <t>Consider, for example, a simplistic hybrid approach using concatenated
component algorithms. If the hybrid signature is stripped, such that a single
component signature is submitted to a verification algorithm for that
component along with the message that was signed by the hybrid, the result
would be an EUF-CMA forgery for the component signature. This is because as
the component signing algorithm was not previously called for the message - message,
the hybrid signing algorithm was used to generate the signature. This is an
example of a component algorithm forgery, a.k.a. a case of cross-algorithm
attack or cross-protocol attack.</t>
      <t>The component algorithm forgery verifier target does not need to be the
intended recipient of the hybrid-signed message and may even be in an
entirely different system. This vulnerability is particularly an issue among
concatenated or nested hybrid signature schemes where individual component
verification could be possible. It should be noted that policy enforcement of
a hybrid verification does not mitigate the issue on the intended message
recipient: the The component forgery could occur on any system that accepts the
      component keys.</t>
      <t>Thus,

<!--[rfced] We are having difficulty parsing this sentence, particularly "is
considered to be informally defined in the straightforward way as that an
adversary can request...". Please review and let us know how it may be
updated for clarity.

Original:
   Thus, if EUF-CMA security for hybrids is considered to be informally
   defined in the straightfoward way as that an adversary can request
   hybrid signatures for messages of their choosing and succeeds if they
   are able to produce a valid hybrid signature for a message that was
   not part of an earlier request, implicit requirements must hold in
   order to avoid real-world implications.

Perhaps:
   Thus, if the straightforward EUF-CMA security assumption for hybrids is that
   an adversary requests
   hybrid signatures for messages of their choosing and succeeds if they
   are able to produce a valid hybrid signature for a message that was
   not part of an earlier request, implicit requirements must hold in
   order to avoid real-world implications.
-->
<!-- [rfced] Please review the relationship between "cross-protocol attack"
and "component algorithm forgery" in the sentences below and let us know
if updates are needed for consistency. Also, in the last sentence below
(starts with "Otherwise"), perhaps "which can be seen as a type of
cross-protocol attack" can be removed as it is mentioned in the previous
sentence.

Original:
   such as cross-protocol attacks (e.g., component algorithm
   forgeries).
   ...
   This is an
   example of a component algorithm forgery, a.k.a. a case of cross-
   algorithm attack or cross-protocol attack.
   ...
   Namely, either component
   algorithm forgeries, a.k.a. cross-protocol attacks, must be out of
   scope for the use case or the hybrid signature choice must be
   strongly non-separable.  Otherwise, component algorithm forgeries,
   which can be seen as a type of cross-protocol attack, affect the type
   of EUF-CMA properties offered ...

Perhaps:
   such as cross-protocol attacks (a.k.a. component algorithm
   forgeries).
   ...
   This is an
   example of a component algorithm forgery (a.k.a. cross-
   algorithm attack or cross-protocol attack).
   ...
   Namely, either component
   algorithm forgeries (a.k.a. cross-protocol attacks) must be out of
   scope for the use case or the hybrid signature choice must be
   strongly non-separable.  Otherwise, component algorithm forgeries
   affect the type of EUF-CMA properties offered ...
-->

      <t>Thus, if EUF-CMA security for hybrids is informally defined
in the straightforward way as that an adversary requests hybrid signatures
for messages of their choosing and succeeds if they are able to produce a
valid hybrid signature for a message that was not part of an earlier request,
implicit requirements must hold in order to avoid real-world implications.
Namely, either component algorithm forgeries, a.k.a. cross-protocol attacks,
must be out of scope for the use case or the hybrid signature choice must
be strongly non-separable. Otherwise, component algorithm forgeries, which
can be seen as a type of cross-protocol attack, affect the type of EUF-CMA
properties offered and are a practical consideration that system designers
and managers should be aware of when selecting among hybrid approaches for
their use case.</t>
      <t>There are a couple approaches to alleviating this issue, as noted above.  One
is on restricting key reuse. As described in
<xref target="I-D.ietf-lamps-pq-composite-sigs"/>, prohibiting hybrid algorithm and
component algorithm signers and verifiers from using the same keys can help
ensure that a component verifier cannot be tricked into verifying the hybrid
signature. This would effectively put component forgeries out of scope for a
use case. One means for restricting key reuse is through allowed key use
descriptions in certificates. While prohibiting key reuse reduces the risk of
such component forgeries, and is the mitigation described in
<xref target="I-D.ietf-lamps-pq-composite-sigs"/>, it is still a policy requirement and not
a cryptographic assurance. Component forgery attacks may be possible if the
policy is not followed or is followed inconsistently across all entities that
might verify signatures using those keys.  This needs to be accounted for in
any security analysis. Since cryptographic provable security modeling has not
historically accounted for key reuse in this way, it should not be assumed
that systems with existing analyses are robust to this issue.</t>
      <t>The other approach noted for alleviating the component forgery risk is
through hybrid signature selection of a scheme that provides strong
non-separability.  Under this approach, the hybrid signature cannot be
separated into component algorithm signatures that will verify correctly,
thereby preventing the signature separation required for the component
forgery attack to be successful.</t>
      <t>It should be noted that weak non-separability is insufficient for mitigating
risks of component forgeries. As noted in <xref section="9.3"
sectionFormat="of" target="I-D.ietf-lamps-pq-composite-sigs"/>,
Sect. 11.3, in cases of hybrid algorithm selection that provide only weak
non-separability, key reuse should be avoided, as mentioned above, to
mitigate risks of introducing EUF-CMA vulnerabilities for component
algorithms.</t>
    </section>
    <section anchor="advantages-disadvantages">
      <name>Discussion of Advantages/Disadvantages</name> Advantages and Disadvantages</name>
      <t>The design (and hence, hence security guarantees) of hybrid signature schemes
depend heavily on the properties needed for the application or protocol
using hybrid signatures. It seems that not all goals can be achieved
simultaneously as exemplified below.</t>
      <section anchor="backwards-compatibility-vs-sns">
        <name>Backwards Compatibility vs. SNS</name>
        <t>There is an inherent mutual exclusion between backwards compatibility and
SNS.  While WNS allows for a valid separation under leftover artifacts, SNS
will ensure verification failure if a receiver attempts separation.</t>
      </section>
      <section anchor="backwards-compatibility-vs-hybrid-unforgeability">
        <name>Backwards Compatibility vs. Hybrid Unforgeability</name>

<!--[rfced] May we update "additional" to "in addition" in this sentence?

Original:
   Since the goal of backwards compatibility is
   usually to allow legacy systems without any software change to be
   able to process hybrid signatures, all differences between the legacy
   signature format and the hybrid signature format must be allowed to
   be ignored, including skipping verification of signatures additional
   to the classical signature.

Perhaps:
   Since the goal of backwards compatibility is
   usually to allow legacy systems without any software change to be
   able to process hybrid signatures, all differences between the legacy
   signature format and the hybrid signature format must be allowed to
   be ignored, including skipping verification of signatures in addition
   to the classical signature.
-->

        <t>Similarly, there is an inherent mutual exclusion between backwards
compatibility, when acted upon, and hybrid unforgeability unforgeability, as briefly
mentioned above. Since the goal of backwards compatibility is usually to
allow legacy systems without any software change to be able to process hybrid
signatures, all differences between the legacy signature format and the
hybrid signature format must be allowed to be ignored, including skipping
verification of signatures additional to the classical signature. As such, if
a system does skip a component signature, security does not rely on the
security of all component signatures. Note that this mutual exclusion occurs
at the verification stage, as a hybrid signature that is verified by a system
that can process both component schemes can provide hybrid unforgeability
even if another (legacy) system, processing the same hybrid signature, loses
that property.</t>
      </section>
      <section anchor="simultaneous-verification-vs-low-need-for-approval">
        <name>Simultaneous Verification vs. Low Need for Approval</name>
        <t>Hybrid algorithms that achieve simultaneous verification tend to fuse (or
'entangle') the verification of component algorithms such that verification
operations from the different component schemes depend on each other in some
way. Consequently, there may be a natural connection between achieving
simultaneous verification and a higher need-for-approval. need for approval. As a contrasting
example, NIST accommodate accommodates concatenation of a FIPS approved FIPS-approved signature and
another (potentially non-FIPS approved) signature without any artifacts in
FIPS 140 validation <xref target="NIST_PQC_FAQ"/>, however target="NIST_PQC_FAQ"/>; however, as the component signatures are
verified separately separately, it is not possible to enforce 'simultaneous
verification'.</t>
      </section>
    </section>
    <section anchor="sec-considerations">
      <name>Security Considerations</name>
      <t>This document discusses digital signature constructions that may be used in
security protocols. It is an informational Informational document and does not directly
affect any other Internet-Draft. documents. The security considerations for any specific
implementation or incorporation of a hybrid scheme should be discussed in the
relevant specification documents.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This document is based on the template of <xref target="I-D.ietf-tls-hybrid-design"/>.</t>
      <t>We would like to acknowledge the following people in alphabetical order
who have contributed to pushing this document forward, offered useful
insights and perspectives, and/or stimulated work in the area:</t>
      <t>D.J. Bernstein, Scott Fluhrer, Felix Günther, John Gray, Serge Mister,
Max Pala, Mike Ounsworth, Douglas Stebila, Falko Strenzke, Brendan Zember</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-lamps-pq-composite-sigs" to="COMP-MLDSA"/>
    <displayreference target="I-D.becker-guthrie-noncomposite-hybrid-auth" to="NC-HYBRID-AUTH"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

<!--
draft-ietf-tls-hybrid-design-16
companion doc RFC 9954
-->
<reference anchor="I-D.ietf-tls-hybrid-design"> anchor="RFC9954" target="https://www.rfc-editor.org/info/rfc9954">
<front>
<title>Hybrid key exchange Key Exchange in TLS 1.3</title>
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> surname="Stebila" fullname="Douglas Stebila">
<organization>University of Waterloo</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer"> surname="Fluhrer" fullname="Scott Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Shay Gueron" initials="S." surname="Gueron"> surname="Gueron" fullname="Shay Gueron">
<organization>University of Haifa and Meta</organization>
</author>
<date day="17" month="June" year="2025"/>
            <abstract>
              <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

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

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-13"/>
        </reference>
        <reference anchor="RFC4949">
          <front>
            <title>Internet Security Glossary, Version 2</title>
            <author fullname="R. Shirey" initials="R." surname="Shirey"/>
            <date month="August" year="2007"/>
            <abstract>
              <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="FYI" value="36"/>
          <seriesInfo name="RFC" value="4949"/>
          <seriesInfo name="DOI" value="10.17487/RFC4949"/>
        </reference>
        <reference anchor="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> month='April' year='2026'/>
</front>
<seriesInfo name="RFC" value="9794"/> value="9954"/>
<seriesInfo name="DOI" value="10.17487/RFC9794"/> value="10.17487/RFC9954"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9794.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="EUFCMA" target="https://blog.cryptographyengineering.com/euf-cma-and-suf-cma/">
          <front>
            <title>EUF-CMA and SUF-CMA</title>
            <author initials="M." surname="Green" fullname="Matthew Green">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="FALCON" target="https://falcon-sign.info/falcon.pdf">
          <front>
            <title>FALCON: Fast-Fourier Lattice-based Compact Signatures over NTRU</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
            <author fullname="Pierre-Alain Fouque"/>
            <author fullname="Jeffrey Hoffstein"/>
            <author fullname="Paul Kirchner"/>
            <author fullname="Vadim Lyubashevsky"/>
            <author fullname="Thomas Pornin"/>
            <author fullname="Thomas Prest "/>
            <author fullname="Thomas Ricosset"/>
            <author fullname="Gregor Seiler"/>
            <author fullname="William Whyte"/>
            <author fullname="Zhenfei Zhang"/>
            <date day="10" month="January" year="2020"/>
          </front>
          <refcontent>Specification v1.2</refcontent>
        </reference>
        <reference anchor="FS" target="https://doi.org/10.1007%2F3-540-47721-7_12">
          <front>
            <title>How To Prove Yourself: Practical Solutions to Identification and Signature Problems</title>
            <author initials="A." surname="Fiat" fullname="Amos Fiat">
              <organization/>
            </author>
            <author initials="A." surname="Shamir" fullname="Adi Shamir">
              <organization/>
            </author>
            <date year="1986"/>
          </front>
          <refcontent>Advances in Cryptology -- CRYPTO' 86, Lecture Notes in Computer Science, vol. 263, pp. 186-194</refcontent>
          <seriesInfo name="DOI" value="10.1007/3-540-47721-7_12"/>
        </reference>
        <reference anchor="GEMSS" target="https://www-polsys.lip6.fr/Links/NIST/GeMSS_specification_round2_V2.pdf">
          <front>
            <title>GeMSS: A Great Multivariate Short Signature</title>
            <author>
              <organization/>
            </author>
            <date year="2020" month="April" day="15"/>
          </front>
        </reference>

        <reference anchor="HQC_CVE" target="https://nvd.nist.gov/vuln/detail/CVE-2024-54137">
          <front>
            <title>Correctness
            <title>CVE-2024-54137: liboqs has a correctness error in HQC decapsulation</title>
            <author>
              <organization/>
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
            </author>
            <date year="2024" month="December" day="06"/>
          </front>
        </reference>
        <reference anchor="HYBRIDSIG" target="https://eprint.iacr.org/2017/460">
          <front>
            <title>Transitioning to a Quantum-Resistant Public Key Infrastructure</title>
            <author initials="N." surname="Bindel" fullname="Nina Bindel">
              <organization/>
            </author>
            <author initials="U." surname="Herath" fullname="Udyani Herath">
              <organization/>
            </author>
            <author initials="M." surname="McKague" fullname="Matthew McKague">
              <organization/>
            </author>
            <author initials="D." surname="Stebila" fullname="Douglas Stebila">
              <organization/>
            </author>
            <date year="2017" month="May"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2017/460</refcontent>
        </reference>

        <reference anchor="HYBRIDSIGDESIGN" target="https://eprint.iacr.org/2023/423">
          <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="March"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
        </reference>
        <reference anchor="I-D.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="18" month="June" 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 security
   best practices and regulatory guidelines.  Composite ML-DSA is
   applicable in any application 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.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-06"/>
        </reference>
        <reference anchor="I-D.becker-guthrie-noncomposite-hybrid-auth">
          <front>
            <title>Non-Composite Hybrid Authentication in PKIX and Applications to Internet Protocols</title>
            <author fullname="Alison Becker" initials="A." surname="Becker">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Michael J. Jenkins" initials="M. J." surname="Jenkins">
              <organization>National Security Agency</organization>
            </author>
            <date day="22" month="March" year="2022"/>
            <abstract>
              <t>   The advent of cryptographically relevant quantum computers (CRQC)
   will threaten the public key cryptography that is currently in use in
   today's secure internet protocol infrastructure.  To address this,
   organizations such

<!-- [I-D.ietf-lamps-pq-composite-sigs]
draft-ietf-lamps-pq-composite-sigs-13
IESG State: IESG Eval as the National Institute of Standards and
   Technology (NIST) will standardize new post-quantum cryptography
   (PQC) that is resistant to attacks by both classical and quantum
   computers.  After PQC algorithms are standardized, the widespread
   implementation 3/27/2026
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lamps-pq-composite-sigs.xml"/>

<!-- [I-D.becker-guthrie-noncomposite-hybrid-auth]
draft-becker-guthrie-noncomposite-hybrid-auth-00
IESG State: Expired as of this cryptography will be contingent upon adapting
   current protocols to accommodate PQC.  Hybrid solutions are one way
   to facilitate the transition between traditional and PQ algorithms:
   they use both a traditional and a PQ algorithm in order to perform
   encryption or authentication, with the guarantee that the given
   security property will still hold in the case that one algorithm
   fails.  Hybrid solutions can be constructed in many ways, and the
   cryptographic community has already begun to explore this space.
   This document introduces non-composite hybrid authentication, which
   requires updates at the protocol level and limits impact to the
   certificate-issuing infrastructure.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-becker-guthrie-noncomposite-hybrid-auth-00"/>
        </reference> 11/24/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.becker-guthrie-noncomposite-hybrid-auth.xml"/>

        <reference anchor="KYBERSLASH" target="https://eprint.iacr.org/2024/1049">
          <front>
            <title>KyberSlash: Exploiting secret-dependent division timings in Kyber implementations</title>
            <author>
              <organization/>
            </author>
            <author fullname="Daniel J. Bernstein"/>
            <author fullname="Karthikeyan Bhargavan"/>
            <author fullname="Shivam Bhasin"/>
            <author fullname="Anupam Chattopadhyay"/>
            <author fullname="Tee Kiah Chia"/>
            <author fullname="Matthias J. Kannwischer"/>
            <author fullname="Franziskus Kiefer"/>
            <author fullname="Prasanna Ravi"/>
            <author fullname="Goutam Tamvada"/>
            <date year="2024" month="June" day="30"/> month="June"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2024/1049</refcontent>
        </reference>

<reference anchor="MLDSA" target="https://doi.org/10.6028/NIST.FIPS.204"> target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf">
  <front>
    <title>Module-Lattice-Based Digital Signature Standard</title>
    <author>
              <organization>National
      <organization abbrev="NIST">National Institute of Standards and Technology (NIST)</organization> Technology</organization>
    </author>
    <date year="2024" month="August" day="13"/> year="2024"/>
  </front>
  <seriesInfo name="NIST FIPS" value="204"/>
  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.204"/>
</reference>

        <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
          <front>
            <title>Post-Quantum Cryptography FAQs</title>
            <author>
              <organization>National
              <organization abbrev="NIST">National Institute of Standards and Technology (NIST)</organization> Technology</organization>
            </author>
            <date year="2022" month="July" day="05"/>
          </front>
        </reference>
        <reference anchor="QRCSP" target="https://cr.yp.to/papers/qrcsp-20231124.pdf">
          <front>
            <title>Quantifying risks in cryptographic selection processes</title>
            <author initials="D." initials="D. J." surname="Bernstein" fullname="Daniel J. Bernstein">
              <organization/>
            </author>
            <date year="2023" month="November" day="24"/>
          </front>
        </reference>
        <reference anchor="RAINBOW" target="https://www.pqcrainbow.org/">
          <front>
            <title>PQC Rainbow</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
<!-- [rfced] This reference currently points to a paper made available via
Ronald L. Rivest's MIT faculty page. This paper is also available for
free on ACM Digital Library (which is likely more stable). Would you like
this reference to point to the version on ACM Digital Library or keep the
current version?

Current:
   [RSA]      Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems",
              <https://people.csail.mit.edu/rivest/Rsapaper.pdf>.

Perhaps:
   [RSA]    Rivest, R. L., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM, vol. 21, no. 2,
              pp. 120-126, DOI 10.1145/359340.359342,
              <https://doi.org/10.1145/359340.359342>.
-->
        <reference anchor="RSA" target="https://people.csail.mit.edu/rivest/Rsapaper.pdf">
          <front>
            <title>A Method for Obtaining Digital Signatures and Public-Key Cryptosystems</title>
            <author initials="R. L." surname="Rivest">
              <organization/>
            </author>
            <author initials="A." surname="Shamir">
              <organization/>
            </author>
            <author initials="L." surname="Adleman">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

<!-- Note to PE: Possible XML update for [RSA]
        <reference anchor="RSA">
          <front>
            <title>A Method for Obtaining Digital Signatures and Public-Key Cryptosystems</title>
            <author initials="R. L." surname="Rivest">
              <organization/>
            </author>
            <author initials="A." surname="Shamir">
              <organization/>
            </author>
            <author initials="L." surname="Adleman">
              <organization/>
            </author>
          </front>
          <refcontent>Communications of the ACM, vol. 21, no. 2, pp. 120-126</refcontent>
          <seriesInfo name="DOI" value="10.1145/359340.359342"/>
        </reference>
-->
      </references>
    </references>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>

<!-- [rfced] We do not see "template" in ietf-tls-hybrid-design (RFC-to-be
9954). Would another term be better here?

Original:
   This document is based on the template of
   [I-D.ietf-tls-hybrid-design].

Perhaps:
   This document is based on the hybrid key exchange
   defined in [RFC9954].
-->

      <t>This document is based on the template of <xref
      target="RFC9954"/>.</t>
      <t>We would like to acknowledge the following people in alphabetical
      order who have contributed to pushing this document forward, offered
      useful insights and perspectives, and/or stimulated work in the
      area:
      <contact fullname="D.J. Bernstein"/>, <contact fullname="Scott
      Fluhrer"/>, <contact fullname="John Gray"/>, <contact fullname="Felix Günther"/>,
      <contact fullname="Serge Mister"/>, <contact fullname="Mike Ounsworth"/>,
      <contact fullname="Max Pala"/>, <contact
      fullname="Douglas Stebila"/>, <contact fullname="Falko Strenzke"/>, and
      <contact fullname="Brendan Zember"/></t>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1963Ib17Xm//0UXVSdIqkCQJFWfFEqqdC62IwlWRbluDI6
KrMBbBB92OiGezdIwZJT8w5TNb/nQc6vmTc5TzLrui/dDco6TnJqqsaJEwlA
796Xtdf1W2uNx2PTFm1pH2Rfb6dNMc9ccVnl7aaxmVvbWdtsVs7k02ljrx9k
hW0X4/VPm2I9XtKvx+E383pW5SsYZ97ki3Y88FMdODw0vveZmeWtvaybLYxe
LWpjinXzIINvXXty794X907Mld3e1M38QXZWtbapbDt+hG8wxrV5Nf8xL+sK
3rq1zqyLB9nrtp6NMlc3bWMXDv60XeEf3sDPN9NV4VxRV6+2a3ji7PGrJ8bk
m3ZZNw9Mlo3h3wwm4R5kzyfZl0U1tyV9xMt6XlR5/GndXOZV8XPewoAPsnOY
yrR+e/odfWdXeVE+yCp4ZDKlR/7k+Af5T5NZvUrf9uUk+zovbfSuL5uibfPw
afqu5/l1XmYvatdeNvl8A/uXnc+WdV3G757SEJMlDPGnau0mdr5J3/pokj2s
q6ouy2305ke2aOZw9slXv2Kp8w2c5wxPbVNuVn+6xE/7K30yyR41hZvByNE7
n5R1Y6uZTb9LX/r9N7Bs/COs/OF2apvs3M42sMZt9tBWcNbxZBZlPZn/qZq5
2eSyvp5sroyp6mYFz19bPOmz8aMJ0WdbOqXOuUX6fGDg65dPHt7/4v4X+ucv
PvviPvwZqdOPAd88/v7Jw2enD+i9coP24LMxfJjBDmXn/Oc9/kHeXNr2QbZs
27V7cHQ0LevLyazZrtsaznC93NrqsqisbYrqErftyG4W49kqH8NIY8d/PqKR
Ar3iP2P5f9nfZ5Psq8bayn/KG/wsb9ulvZHv4Msnp08ffvs8nbt8lj3JXTt+
UsPewiY/hSeLmR1Pc2fnQBSrdT5rs3O9yS6rr+FXz1+9/H54nYu8nNUVXf0J
bqB8MFnPFzSP83QOX9c32as6e9HAsNlfYQ7OlosH8Hd4azGDoz+vyw1Sgcva
Ojubw8kXC/gCP+JN98wLxpiWduWG5zWviwkQ2NHxvcnxvXuf/cvJk0/Gv7t/
b3z/s89Ojsef/Xh8Qo/N4W49yI6/+PzTD+/96SR7UuRtZ+tPV7WLP+8/dL7M
V0XTfWxe6BfwzVePn513duorix9lp3imeZs925RAmHlTEDOASUaHNLwDNzc3
43Vduq2blMX608miOXpaVFfu6PnZ+asjGv5H5NN+f39s6k01P/nxLyd0emF7
Tu6d3Bvfuz8+/h3O9evvHv748C+Pk9k+rJsGOH5lncts09QNLB5/mM3tLF+7
TUkvGJxmdT2fVIVr8SIfXW/K6mhuW7jkR/COMbz5Phzb8SefpdOBuZyM731K
0/nrly/PHp2fffVgcHi7hhvXTop81hA9nNw7/uzo/qf3kr1+1eSVK3CKcDuR
8PLsu01etZvV+CVwDRRDbfZiMy2LWfaN3YKcWjRwiZrNLGz/raSTipvdIqf3
4PcgOWyTt8vOg9/Pt8A70+/6rOLZ7Jv8cmN3MIv0287TIDzOWzstyrzz9KN6
c1nmLvlWz+X4s/G93yWH8ugx/M/zX3s0J58c3T/5JDma0+x5DRQPt1+0l8AA
QCTalZX770njk/G9T/6BBxKL8vBYLM5j8VPmq7UDJWkMHH9dA4lZ5JTugf5o
amdXthlfwlSBG4+rugo/FLGFy6Dff/PXLx+/PH96ev71r97O+8D+7n+R7Oc3
KFrP4QCXD7LHb9dlDWQPNO/srAG9a27XtkKmm82L6wI1KXhwBT9weKHp2axY
rYHtwm/oTne3/z5cy/En93DCz54+Oj8dnmvEnT+9d/I5saTJk7MX55OTe/eT
+T6r55vSjlVMfUli6lFxWbQoLAItoKaYN/P+bD4fHw/RA7z9QVA4zioHL9wg
oS38WI4Ezis7W4KiVF9uswOc5iEuDf/w4wtghE9Ovxte4cw1s8DXQFb9G/BH
dwRn245/Et4SqwcgN39yycpR/RsLG8oeRj8F4f5dd9uBG9Ld+3sv9LuXD89f
7FhhM9muJ219tM7XtnFHPzUzt0aO/cnx8cl9L0J0ObSSYrFFagMt8IooKtoB
YK2gC8AmIdGtm3oGsmTgch8fj0/uf/h+A/v6EkwJ19qiqys9AsZpy+zP8S9Q
Dzw9e/7ltz8MrxVk6WT906zJi2pa3xDppmcFou4lf7lHg+0i/LWt4fZMZg61
51XRotZ+1IDG6dqjly6nrext3Wn2zMJa5xnop9m3U5COJKd6t4DPkeXUGOUU
Uw1oAK3Xk27dtZeTp5OXNJldykyiy3S+fTo5nQNnyGE7x+Nxlk9BQoJaZ8yr
ZeEysB43K+Is1s2aYgqznQEbckG9A4pkHT27rPOSF+PEBjCgU7pijuKOlEPc
CWaQwKl4GyKzlgXDCKY1Kzdz3CsgqHphmLnmILdgyFFWoeJq13kjn+AMQDJm
9LMK5+rC1l7CvoAKapYdI3qUTfPZ1Q1eoyOYFf2BRoCZ6ovkmUtbwQLoI0OL
K1ag1eWVrTcuAzXbb8WEd3BVzOcoUO6gYdwAI+TL8e5OEf31F2NelDnry63X
Y3DBYCeD+oefx1wnvnNbMKNXFji8xR2dwSxASYOdXhSkePNUZeW4MWsQxfQ5
3WDcLteCZUcnBZoeDpwBo4b9gM2/WVow2uDq5hnYfvgdcO62nufbbONIzwLb
thC+lJeXNZzzcoV7tynn2dTqiPBUQa83iw0d73QLL5T3gDy6gcdAYQMbCrav
gPmVW5jojW0WmzLzi4YDAa7XjOBNrjZXVX0DQwCNxZwVDZByCypfaa9R4/PM
Vx7ODh6+/O7hIZzOWZsBSYMkBD0cf4kqI4ybKZVGJ9E/ALyCuI181r83oGvk
xBbdZrZMnpyh6g9nQ/wSrA8gevs2R/k78ut32Qp2FLYrB2vIwLtmedMAKW9a
v3g5kiy/BM7hWuROwKfvf569hj+9ybY2h1GmdoFHScdMHMTACnMgZyvXwsHF
AAZFNF1YnM6mgY+bVY2XAP8Ec8B/1+tS1uaECPzpZnCA1ZhMyoJvSWnfgogC
PnmF7CsrayQMIMjOauH6tmZmG7EG8bc0MaDH7BrolHljPsVln9yTJcEnOB5w
1OxVmB6ef3+OmRAXsA7cKrxBoOGHs0L2sIZzgjk2Nc6IDit3Bt8wLuGKDHAi
Gqe0l/CZsj8H1HPeFmWpW7bMwRKegtmOI6LQQ7Ltnlh0PejumJ03eoRUfWPL
Ev+/o6rRhYVph/OAUzz3HMBfKth2Ugy7A8CZuQ3yVV3766CTvsELX8DH/llW
HDO2WfH1IzyQ12I+vun83HReNd1c7pjcTd1csQCA2zq0RGQVYtjCofi1TjKw
5YAu4KVL3JtqTpQEPGkJ9nU6zhgtAFGFjR4GXQu3ZH6EygiuBwYs0Y+yzIFn
NfUVnOP9z/9FJQlwYRQ4JSk7L9G8Nsf6HepY2W4lT5UzcZBlokKOspPf6fAm
DF/Vrb5e35Qdj4gxf/LpwHRY1YKlADPFiRjcT37sJHtNWt8bpFQ8aCKvHLj0
1hWpVEZ+N0Mlim9jZTNgWA6NhsAKzT5Lv/2OshdoUCkH2MG0gDGmdbtMhQNs
W0LwBzBZZDsqUUu8lvy4VyXamzqTnx1mMcGfgoTD2U5xO+He4o9FQEfXrGC+
DVIUfuXvYVecOANTL4GptLS/DhRM4l7Ak6+Q+Gcl0AcTGCkWyxzYEY6N59WA
7jfDy6zbCXODN9pV4WhSfpc9/43mN7UkQol0F/h+eBOobXgGcti4AUGTiR6V
71WRIWUpW9bl3BFP6ioAuIsJG6wXC2BcRDr0fhmhQEkEmgn8a+eT7Kw1bqmi
HJarFw1fjd7+zNMF3kbQGlEtQOYy3eCPYo0RPw9kVFdw3KQRIDV6yeJs5SyQ
7A9Li4wVZ42bzE/pJcJRQcXE2fP9Jg6NU9qQeHM21TrBLEfn26oGGT3Jvncq
bhs7qy+r4mf4eVZZ0mtAFcqbNpX0QZaPjEUliqmF2ahyUXh97axXi+coxa5F
VukFY2mIKx6ZdEWzHAXHGhWR6HW4/dng9idPG6HEyqLgyUFtULYqNsPvaaUr
OIW58tdKvsva7dqSjFXWYFZkpTBvpsXNLdyRlV5K4hFwuEjas3othBodNK8S
TwHvFQnH/unxiLzlqPXMUVXLL1GHBn6HSiP7LeC/y/oGfuU3zNJROXlwlc9B
yfgBlUcivnrNC8yvwTRDXWrUoUJYIFA3yoS5sIZruCV4Qq1929LGgLTytw/4
lx3DVWGOWQFFwB7jdJQxAq1+nSwP7Z+eBiF6dHJjvaHDmp8BGcrMHNXQFpQj
UkiJjTqRIjSJVGlQ1oB2EhLjFIxNnJ/YYPiAF4rZfGPJwEiMgCHbied4NN/k
pXGpYYpfq90wB/0bY1v2CIzEYr1GZiZydpJ1tDUwuhrim/BcY3/awPUlTYrX
BCIN1ULcW6RvUYbld6AWNvVKJmXSXUWRcwOKGJkahQPrx6mpkdDkeThVR5My
K1AVSejYt2BfOpAhOt6yuFyW8C+qP7BaNRBmNIAePK4V2M0YCV0VlVmysknX
ZibjjNVJVJjEAZD7AC7TDvHlqu3RiREOLScr8dhCjiU85wUO298LYjl2Rcwk
pn6ym2AX600DK8Of8cjIHROywQ+CdO3Oh27i0pZregvdXLhPN3iKyanaLWwE
T7UWwUlbRWcLLNoWjWffMNdKuEsJ+mermmcBJFxb5nZ4RVZruiNo2hKPbYCv
mC6vI2bIckkHb5kiaStYOym3YWTWr0iC0oj9Gys6DhsnqFKgU0xeR/ZAvQAt
wLFRi8KY7OdE/F5u4NLB++GdwoPmbBJv++xjxGqJirPo0d0UT/eusWWBhi1K
GI7t8MucxEhQJQO2CXyXHpHLf2W3qOle1yWYQ6PMTi4nGc4bZp0avSP8Kbzk
uua/G9vO6N7H8yBBr5cGONTMVmBL1M5b/DARYFlMeUQfuZHP2JmC5j4+T4Ea
NvWI3WMobe2fpKPQB1wkpQzREdzFO3eyVyR12Dv67k4b/vYLaBx4B8oShI19
WzhypyuQIZh9JI+YGqKnwQLn8PMb2lH5Ae6NraLAWbayqDoWDrS3g28ePzvM
Xu+OcL9BJg5bNcUV2rYtcUIofnkvHVJuVgJD3cDpgQS0zAVBY7Wir4LEEZpg
/QCVb1fAeHS7gOfDMcLMYHdv/NLx+Od2AYxJZdl+LG6Cybk/yvaHPT/7bK/s
6x3Zn2TPQFNHbwG9Ca8hXYn0NZFXYB/v9MqCSrTPPowxbmXyg9zxNInwzWtB
AqCtM47CCcygMPra9SqyEsIDXBc5rZu3ADX5LEONMVbUCXeSXXxjt1/Z6uAw
G/8xO1hfgQl9dXjxgPT9ekoiFAhnRifPNg1rTDrMiDytLGPke3KX8CqZesmF
hANcrK8u+DpIWIcWId/SQBfu6mLCE8M1HziY0IrnBj8dmljYhjA9EXri5yb/
Dd5+MIwG30xvlXmtUN0EiX6xuqBDZzzIpoVnHd1sfdsF/JGmmiHpMZ9CbJBn
bIMvQcMAdOyV1xJRIiH3pIEWbBpoSMTpl9uRV1P8ifof4phAgHP2nPO2xVsG
V4N5YLQ09XGB0gMzAVr1nAdYDZpbPNYKDPXVySibTCbwh+cXo/jukYfCv+4P
RKPZQfQIPIHToKFkKnyyfyGiYGIrLvWAp3S4sbM5ojKhMD1MgfXwge4ktVH/
wNJTllXySUenPAWhfDG9UE8MjnmRz2YWRPPB9A/HhxfImC8ai3Y6L2/6h3v4
KW90eCceaLTtdJf7WDe50k/80XreS9yFLzVMq6etZHr1mZb2cj7HcbA9d4Ug
yMjINuvgj4DByHERDPP+s4F57AF7ZouxFV/nio6GbF3DlOyVtvWmQeWDtCrV
kLzF3fElxCEO1sVgNCA4RgGJSbwEu4EQHYly2fHi4DVbq5IFDBmVGBiLjLjU
xQCWM2rGZHvViGVpVUcYof6CKhVpfcGggHHIeyji03tYZHOJyMSMJmOntygS
5romYs4ygl9amH92IFPBkVJ/fVgjefyuCX7FXiod0Gt80YBq379EYnv6w+ND
0HB+wONleVngnqM2j7yn3E5Y+0HpRd7CIGbFy1ORqYm4EzzhlHhRgsNoIiET
3xipG+ps6VHoPimhNp8H44rlGDqS0l3Au1vZ4ahNdlBMLGzei++OXu2+QO6Q
AyW4flKjhRJjt52D7cVZJ8pDljjwXqF5TYvyYAm/GvQlhZgWudWRa5PJgvPY
VnW1XdHF2U+oc1/2HwWMp3UyHoOK5i1xJCWcgMgENoi8JZeo9bH9I0TJYR48
0z0Oj2RBMOzykRIli2JEQg2hikEHRl5MzCU6X/8WsqDQTzTF07MkUXjG/HDe
1it4GTtExZUJQ2kEMSvhSMrJHuL28usaFoIOQg7hCenJ523/YPzZ7w9yZZRF
Pcos2HhmQdH1VvaIat8NKidkRclxY0BEmA/ekH10ToSH9lFeJsEm8syzPMBt
Sn+OW7cXOZc70R6kMrQiSWknkbSXvY7hIm/UlyecQzzmeCDk90u2lO40O3oH
aN6vAAilXdabyyUKikD++XpNcbDdxH/U2wo4pIeejR74bw69/HzYD44n7JaJ
ZycdEw8rpptWkHaDfi0ej28kDLYUal0VyA1FzrGyGW7nJNs/qy4bOy+GZ76P
riHk2za+s7wltOzn9m07HlK+XaI03GJ4ISuGN4gmUe0czysS4RNWvHD/0I+w
tajw3IDdi94Fuy7rLRr5cBv4d+jkQjEkbqip7f4WFAe+ajFL4PNZAWOFX3oR
jLJ33ZAnj6aJ1LHDiY1igV0tsPEU9ySSTH7NM0CTd5QtCfNNbj9LHHVGDsas
I1iifVk2RMUdD1z2dX1jyQok4Zb/W914BYHsTvZlkJbec2ZgpBeWDqKN9opC
o8g/OdwbRdtxsJoVmFvOjkjlRQ1Ce/sA6JPmW/ciFjeyZBwR7GD89b6gGILD
GKfPOkeuPnX+aRDEqaIuWmTsxgSuDheAiA7DB2u2yy43xZy8jjohsdfIy3Iu
9yh2QyBBMVgGCXg/ju8tisuN7AJ6ExALuE+R3MaWRD/rJegkiGpH5YbkC7tK
RUgS+8H1XOcluzIbARmIutqLAuAOn6LJns9aEBAYOOC/oGSw6PAShyorttXc
NvtOXHLkUvT+/jyRiCQMG8wgqBxdH4qcDaF98EXwQ2DH84mfiiO1lqSonBqr
1p42gNGRqFRNEp1NcuY9Jf9wxJdJxkhl7cAAkQ/jkHZf9WGiG7pSRDm7nhdZ
dBgtJ4oPgQgqKBOkEMA9OY8ovoeEPLMFITZkKrmEJwO7Vhc+e1E6Dn3yonQ+
49vhGGpNA7JuhVH+ObwLY1HGexW8cYc6aE9YrPNCvH/s16VRKRUIxEBOW6MB
i1U9j2/TIe89Ps8T6UdLgycRtTTQzX3UNbGqItMJeIycDZMahYE7hglqHKeq
JojagVua9zdKbuXwLsTkPUpdDWiQALFUfEW7inykxCcSYjRwDupu7ca+2XGy
lYviVGscjDHF6hPGV+l0WM078MeD3l4KkM8PabPDamObY2hMOr34R3pqXoVg
UJlsJi1P/dHp4OGaCVISTze8SBW86GdEDDc5moZwyTEUmkXpcMRACLpCSk+I
eRYcrxIJlmOwssLAnXizb2i+IZinskhUQT+jSbhuaCUJUkVuNoFCrKjrQAZ0
kGH/dIeBI19aOGeNv6U64I5f4a1OP9pxp3FaMTXFt5QGgF8fIBKTd+2ws9v+
/Yx7yiKAGlk9YG/Xs4KoXOh04BbTGfSuG1I+megRtEgYYt7BzsGJ0O0CQ8mr
4+nbSV+j9w8Ta+AoSNC4cI7gxWQeGzfIlUDzeTa8+xrmpIS1EkSdrB4jwU3B
AQcFaWUclhAWuKloKHWybFB6wrUDSVyN/Vx4Nw4k2e0we82pcG+QCTKEgYXa
QrU6BaRyOOmDJJbRnfRsFHcSXbbk+7MM5SP3isJyaG/YVvXbuMF4nEAQUf/x
OqD4igq1f2SN795pxh0wmRJUkUvrfvmFozvPWBlW9fd7FnC7Ek6yd3dW/oFf
jPmSkZOYMQFHCltRSzQkwjLfhlfm8CRsyU3dtOR9ZdIo6/oqI/SJviyOyZ4K
aEb0oLy5lEATInkwtqH+n+jVCebKMqopKKq3mTaGkT6b1SpvgNycRMNRm6ag
UD5nmqdx2anFzNFG08ep9PDTMGEgIjqHO8R2SiDXdmvMbntM3fSFnG1J/ugB
nx5ZPEY8p+p2RcQprKbagT/uAE8TbquB9GdPx4/OT7PXlOHyBrQMdGZ5TPHD
l389f3X69Hz86Ozp2auvz75/digBBRaSuGlj/jXmDY4ZU8+mCLl1Xj85f6MQ
OopddvzdPAtCShl6NUZr2f3A3nJS1nEBASPmZH4+6J3PaMw5o9IqW4b8V3SG
eo+C6OYS4S7RVUgcXpZLFxo9m0+LK3sD2gdjyHqe8CeUFgpLoyTUN4Tp8sfh
5zrfkNUTNjx26CR44y5CFneoa7WtopxJjzmQNI3stSR8UOQ1o3TI7DXlYb4R
X1GTIxDPQxyRePFEbHNNOcJA8/VaIQ5sNg5hGlGiLAtiQfQAw/tPmT+PGDN0
i6uA0dw5IUtgCMHPdNGyK8xRvBJAR2MldQvmhWb9ytIsKSehYe9hrP/Fk/Yu
6/PTCf4PsWW29GDF5ZZ1vpgNw2B0BwloRFkNAlAZoRdDDxSVPZFCM5Z14qpO
ANDqBfWIW14NelNWDFTS+SG7wTyiGA2Elh+c61q+w2cRj2DIc0oCbpSiU2JM
sx951tTOjb09pjNhi8oMyXOWbXD/DgnBgDA0Ni6r27fOMOSqVRzODPYh50hH
Z4q6X2h95g2hQ9EeY5j8V5idYTSmw8wTTx5pajCWzChPuvVsRjNUDxPzr2kd
Jp5NDJlDEqtYwIGsrjdkq3+7IHjhhymZzlmMybnHdZClqQjCEcGQPe8NUVhU
Gglvk13mRDVzpaxBJLX5EJIa4Y49t2xwM6FfAPYAcRBmwVwni7kj4S55f3ZT
1KzmkCHhwVTEA722FFghPAXzZkx61rAXEgO5fxu7BtlIlAYiFTeeYBwBFWwa
2gkWZXm22MBDe9MGfroHRgEeaXgMtUUSFFM88IWzDBpWKxL0pKbOBRfvYyYi
kl8BlRkDIr7EVDYFhsa5VZWPpOt3bp3Pop/yk0uLMmWGElkBq/4XRHGwKioB
UCTZ1fDlDHZN0poE8gdbQBtuCGwtXhkwz92mYRWUE0DIK+AvKmxpCfMiB53o
z6jCYpCtxegJ3dq1ViJAkPEqAF+eencn2hFFu+JYKOfnKI1sYJ3VjFC0wKFX
dk7Z+sPezpDtOMoiqmfwTWTu9TNfFBtWcHoL57/grYerMgclAyj5dK7svdzy
8Hg7EWje1g3s969MdnGS7aIOJVI4KZ8FbirYuhXYPiUc0GZOWcR8jpfIRiq6
Dp4kDhXcxeFNZvwkW5C/mDR1jRiJPNhLnhoKk8NBISQYM78mxl9iQvokmOpR
98UcKkcvTch08u6IkVkW8znl5Xg+DT/czeH2ERNJxQLIz+2xt8anxIWYLkPY
OUrOLhfiDxFB0tSIYBPvM+1iN9UBLwGyC6cOlkgUzCm7lDc1cuWzXo/7yxmL
CdKaraKvyHJ5d4csmF8QkqqoXNSpMGfR+79YQqlRySYP8Ta5msBcCntNGHTy
mKcgdg7pBm4vsEYK0JDFEaVA0NgjsUIplwukD4UiaXaSOdpYiZcvwBBB5kvR
aZqRTEVhixjSxocM7J962irS5oK24RM807xOYZBiJp4mAEeQizLwEADWB8yK
sIdk0QVoWhTgN7AXkuOyYyDWDHhhPq6dIi73BawlwVUB2EoGx0ESrjvsPMq2
uRygOIW7iGqdiEek8l5zVgpt8qAv0OtC6pbn0ANH4/E8FTIyQt2O7zWr2nzQ
4myAy0kTRc5oyGCBN/XPb5wcXzZm07eJIpF+W8QN2rNWVXCIg5H2g3y+ARe1
Y7HmwFkbh2lgGKD3Q43UDW06COIViPSyzDn4Sx5DSzUicsyOlwC0Ag/IVEHX
2iDJCZ2F7D0llNQltB9xTeR1TOWezL9PfqwpDF23UpEAIjBTJM6y6kCBA6wi
8JOAotF4kRq9BCoWz9QoTTrCsyaJiBZCawLt7QI9+WeFWw28H6NaBtUBNoSR
2cCkdmzd74WL71y7Sdc+4GsIfnvK7hEoLDEEX1TlDWqSvSmUeGvQK8Saciz0
igh7VVR6C1DZwAszfD3ixBOtetVFkfVAGeKIcKAzhDhI/NStpxGgSDiQXCby
BCpOjPxqCFlQx6LfIIZJoAudnXAm2i7eZrorXFuI3V/e8VVvmjiGTPcSyP57
gf2rhM5TII9H/+Am6gR7OyU4VDJsJDjUX3qUx4h2nseJz5ZV8dPGerdf0Zj9
xaaaib4dxPk+qBbt8gZ4k6jWkw6kpe91QzREgoWINbDWrumdXH6u7Kiw4sYQ
KQwMyYmV34XwkS7rg9s+lEW+3YC4p6uHe2OiRDbvmeskEXUeC86DzZryiVCn
8+MMa44Y4TgLaLqRz+/4NQednrPpnnPwXffJGx9HqMAalCe0dZxkOtv2xrIJ
vyJBvpsEaOBBAuikLYbPBZiXHC+QPJ1ZdDU1HF6wacSRIymTINiUYLj4uDFd
d2BBsNBD0YZeYKENDh85LyS+J/cX1eDIOjU4Uk6wC/BWKJrSII2zR5M4bbCk
OSPPMvScF0UJtixEEMiXpMJEGUb14hbNKlUMCuvTZ4GO1pxAbIZUGw+Jquaj
LApxqv4y3RQlWc/TsqaQnQhlMMHDETvOk8GcMfWgh28IzPEtDsZuV6AcfAly
TuCDN4a3O84jJlQD58V5qLuaQyVGfHAn0IhgC0bCMya2NmjaAY3b8az4sj1s
eWvKOOwc+k74bmItH04r6h86GwKws+gIRJd+91A0QIfuB2MXC0qI7yw8otR6
QZ5HIGIeeaUVLvzLexosEx4arxhvmo8CnrYsrvANTHes3g7ueLLL7XLDjvOV
ta0vRJNeArk5P9j8KnteV+PzKK3SmO4nHGsOYpQLELi2Q6JpsClOxWRfXsj/
SgTlGcey1Q7J2VrweWOsgSbxXOBYuD4BA+wxGmBvh6APsxBmaDyep7QL5Dno
Ku+rRZoN6rErYl6gNwk9X1uxZ20QEHFZFFyzQFu2hJ7hx5H2Y8ALotqAOhtD
Dg0niGDcD/qYdHB4w+BBZQc/PD8/jLQOrnwHW0r16+iF8IsQSYFNaJti1qbR
cUppTBAR6GLieCDXObktc4DYnOdleAQHeUzhHXDJISfbiyOR0mA0jZbZUf8V
hpyTKDrJaeLPw6OxFEc4EVd4x6qRYBRXayWb1rHPTgLRkmvYhb315nHgDkec
IXOTbJcPh0nyYvDeYlWr4tL7bxNkE4XBiLQJWfkW81wZKTi127oDQAn7mcwS
SDe/BsFOxGsYAz5T7RvFOmhHm0JiAVPcKo4RsOJBMigotZXW+MqNwgUrKYO4
w4jSKB9+mslVwKzQMgIhRKGeo1txt2eLlCoV4pPorhFhIRUhTRNsm30nNI9A
HykMDbmyLdHXVhBkj8IXXpSHQNGgHashILiUoKmjDGLf4x6lVOgbVhtH5k70
PMFiXyXGEKJFNqi1qvNY44mml5aO2hFO0/MXzrp3t+sOqJ+yR0JdC5MozNBm
5OBzXqHAoEjIp48oTVy86OxKMGZ6YTg2oddQNmEkGOl8mH6D8ur5u1bfIHfi
TMKfjKuU5GSWVedtg3Z2X1rt+CI7OAfuKKYx/cQ2akvDnIExjlIMyRAjhSHi
5GcVwT1RhGGqKBWx78M5QO1EEZFRUtoAj00fSlhNSBPxQzEWDDkku4P0eDC7
50ySo6j4iRuZwCp3WdMcaRuUngmvFh2tN2OayALM3ZRRHewWyxIkP/Rqjbjh
Fhxy7zmo4vzzAMYVndl49qqw7l3cfRAhSxyeTtEMc99guwTQk5QqIGYUapnW
mpcW17xQPhIzXYrpYEyEGErddHG5Oan88rDJXQxEI+sDQyKWvDDI8MtygyUQ
CSyg4Z05Z4hvCrdE5oIqAcn8c7wCoXxchLMdtI4wI3SV/3g8QXQS5Vsa+ehE
PrqlbIikpW58IlDidDIXmDzx4zGljf54cnihnqAL+phzUP27D3j00/Ly7BHm
mHLuJ/30JPuDiefU++kkJPXiYkcUlbmJUjn3YYSBF5CPj4zxNO/0x2N5u06Q
slN9KQWVnIomt6upnc99ecEgnEJGXIK7GfnShMbfa+8IZgMjutQeS5iomHoV
RC8xiV4SuO8OHUPE5o1Hd+LtFk3L+H1EA/3GEWkdkFtC4+TDWb9RRrvBsH6D
Zmm5PfRSHUgTS4FhAAlrr0U4sR3ljd9QIBnha0hgrehjMytCy0S3JkbSzpbs
ia2jrEhNplFnp/NWhRQphEFAxc5XttyKEhSfvooEdXSpC8bfFfiNYISVpa43
fDOjmxOrMcEfIAAR9Luwf0t4BNWhUOYzG/aCkiAYPg6XHVS0nIzrQhUC7uhu
1KHoMqrhis3Z82SrEY4apkmtwojM/NPx7xWbGVibRtKwKIRYfGKJseCMTlad
ZkhFiMtBQzwt5xTh2MMOR2ggKi/iQ4a1XA0WTbwHk+zxWyy0AQau3/AiqaxV
MFSWp9o7TjhwFP2i/ltflsqkdzC6KnQBWRXBcWN9wIc5OXlCs46TiWneQEQw
olF96YvIPtEisg9jd7wxXw5HISPY9VAEa7BolPlPRbBGnLrrMeiq5Ho38pTB
AZTAxKLfkd4j3m2NRBAEILytXSZJxbd40xJHWgZf1h4CNOzpNbEeE/QVks7s
w+5UzRUFJoAPzK5UNQ5AO6zkqT53rqOOoA7ZBhNtw/O6BbrYhtoOeXr/9dx+
HytSyEZVxzJ5tuv2BrnhjRMqjQeHhT4oqd1F3nncYEkVgut3VHfLuY8oHhLI
YZfJB1T7ZLDYMSdrMtbI+qIzWrgZRa2swteiNK8/ohI+x3LwvZ3Xsv/dmajI
3YA3Vut9EbkqLIbwE7qH8HTIrDRRKTx+NvWikzjSoM5BjO4Y+c8TCooqUZKW
qMRwjeB4TXBFB93wXR+ZQgpQBabWLcLmycS/6fchdg6Psw5DyAnh4Py/vrbv
lvOnBKHFCs2wE099PCjTyU9Nuu0sjmpEK5G8hyGa0WSYHctWVx5CduTchM/4
iypYE5T1cChGaFv80d4h1uyKCImKy+ayTtKkk4gY99JXbYwrIguKs0K0ae2k
klkUjRIQFYG9pFY1sUrM/3aHDArmSo0Y7b01z1gQISOd65HunOltrEducIQU
YyLVHL1jMaAR1bWixQKAeYipqK0fVyn/S8SzQCfc9RXY+385jIIFKC8JUQnD
L4rGtb/C2v9LR6Xxrg+BsIgi0ItByzYnnq+IFVjmdu5QyYnQrAydyaMazKbD
nhmMKaZClH3IXwhZxs8wR6GLxjDPjtXbiRLGBVpnoLy5jNQeBg77XUaEm2q7
e9TsrLrcS44yBux6K0/scy8eqPYG6m3BEauRpV7WcdB+5ILtIYh1r2dRGL1t
USXxHiPW3ZfUNnxZP2JqOmHA2MYShS6PAI4ZAZeZlVPzoXFRaRYEGsbKV9PK
9Luz0qgSWi4+A4ytSW6eCdt3VaxvyRZVcAeQ8ArePXOJ/20gJBO8WqMM42eq
4vjIuk+V2qUCGHI/cwmuUNgjzAt4NaWO99g59ti7RFZ+WpJ6IA5qSupG5YH9
8rAbsJgQBiq8l8V7bRHzOrBpgeZIBSlagsTGZWET71d66zCwHJdF716hVFEN
y9Xgks/LIXTCIvinY86AwyMjiCM1sNioqCMpBAakW7IkveVqbBCiOoo+oQVL
NzaoWFiHY7ZxWG/lZx+q6l0zdeX7kBZ5MHzJSUlvhodbE5FEV5ukq1gzrbpd
DoW8bOtLqpecghm/8p0qPMIrNK/wIF4y/DTNLLwhgJa8Y2HE9pAhDXDJXlPB
qa4IbyJgb5c6vPqpcmYvVC+d7FGcMIRagOxnNi3vmKp/qK/lJk66eqVJV6Me
6iOphRWSsxRsns+t0ZPSvflZg42kNyJdxMoSgfKjbSTQJserMOBtEORAXggy
yzqFK0U94Qh2XmBDRZ8L74tkaVzD0M9UyWCpRaUYKKjws6gqEpYnl6WcPjyf
vQgfk4QvGK6MAIvwjeAvWV0JGYZRKWO5ZzGwNPK/3l7AcqBsarwZmEIQ1zye
stqis2sTJUawX65vFbD6bSJqVrf4RjI5CFgtcBdSPYBpFSst/UsAclQGuP7u
Ljd8d8DIR6042XhjUYWvtgbP1IrqS5kkfnquDdsbYv6BD/WazcSHe06ZGY+9
+tk5YU7c6PTa+aA22gMD944r6x8Xvyo5tKjOKNfiUsCYeGYd+jNxF7ZC6QUW
XUOPJ/Je79VB8kAD73AU+aNcKO7YpQPByg19NaLrYnw+vSJI8moHKQSWg/VH
hirxm5glnEm2AwWBR4q+mtpErA45cWgbjcMJaA5QHz062AgggcEhXTzjhWSP
Npq1exbUSWP8x/NEzQwgMCpUZTlbys97xIqICgcO9NYLEwyfJBSrhRkau7a9
VwWfQZIGQ1F2vbKrTRXpBWG1yRNFFemNoVJMml1zkKSgRcZBv81TCpg9xBmh
44YyrlQIRRRI0jgqFibhBS4f2K9ZgH2fenHUcyn4zbigxPYXhYy1P6obGBXK
jXEepCHOclie8VlmVHxzbi8b0EEvGDQWDa2p1aPsunAbKTgAZtu7d4vi0jd7
Hnf7aVF6/d/+9jfzfvz3/Oe9eX/37vO6tzl375r3eEcDJyAkwT/i7YMQIHp/
5+Wd2NIoYS3kTBjFDZOSoCOM9nef+I74/K6p94zrf96Uspuj3a6HXzvfCDKs
3KGhoNmGk73Q7oSRIr1EbO/U5v67L/s//ue/08V49yC7c+sV4h6Af9g7jwr9
935DAWTK9uRiMYKwcO1k7xdjzCknQSCmSXmOjpbHuUiK9B2C7sXWqmjAjJDB
CB9icjXKGiwgjrsRgka0YmzeMWOjRTrhSBJvajafJjWR2kQT4CRq05NzfWQh
FcQPJEIZrdlz2BQbq4DmQOMkPvrrIvjULgNTVAkOZ8qT464F5GESYTwJBNbV
fGjYQ+MTdRfU24qjjRTWJaNnO0pRDTfS6waHLaqKu97UWJwpUsZwAnpU9WKx
Y398saoJV97wYcuYVJDGEOsaCDA2s0CfYaA3cscebpWyqj+ECo3916EGm+nh
DOUnkilNCZwHt3BaX2jNpIAOBlEfRn4lqZufELKn3E69uB17TNchRWL2IjV5
K0MqcEq7EVEDER8z1uQhD1kQs40cf6Bai+YaLGCcoOnACANUzg+zJ7m4KVQu
9jbkPaV+zxO8esH1OQk0ka6E0eOfbQKnEGCNM1JZkvVaf6RY4pqpeEDNpVZT
oJMhRR2xoDjsI6JZh6R7w/uo+zdQR0GCX6GBGpMDUkgQwzthMxtpmCE/URIx
aC6JgU8vKGwo0STx+RxYwuUGBZlEajnGN+pVlTP+1IeabsnDoSgfTKqitg2M
ppHkVa/BGnbgVV3Gl5K477mJkOQrWqNGDEFBFPwxQtx9iSgXn/ERM59hBuhF
sMSZyQmX8qgeECgwtGT78wAp5RY5jT9qUmg1NLBLpWDE4ciLOpOIUb6RwrMT
PtvDsQaFSBEB31eYH4DfD+qG3unsRxLykAHhI+yY5JlXB/Ix4nYxWp0U+W/i
X1BQW5SjyD6gWVk7wpIUVjvEDlTv9mgRfhQunDoTtASY9OOKU0mSHeID4wBz
VLeoC6EyqQhFTEgq+5UM8A6MOjQKpy8aRCQPKiKKXgnOQcWim1UQM3BGVrEI
mNWCB4mtUHF37sL6Fs6wivGYXxDqmtJ19vXasMNiksypAS8KqIckFDI6Fd1A
7qs5tlaeS7P2+LhGQu8DqSLIyncq0aNUMxZHuDN0S8map7DMbfI6DxEw1YlC
lASjpAFlUrepNzS0dqnq1Nx3mDV+xdlCCa+LSr4Me7u1S7HIGF8YY7d3Drln
W5RRSuKWuksm46vBgIdYU2KJEVCZ1nX0ft84Gbuv34miEe4HHqzRO7oqMHg1
GCxK9Fu8iaMsQvaJ3PAbT6ELWUzcmwMJWBrPis+ZKuoWIn0JbYH5bEP4XKov
EwlmfED3peg25JC2QbT/fO24AGXPA4te94t06IsI3IyvlUpWZme4NEplk7ij
XjrpuaaeSAnb24Dijt07tAI1nPo2loDVpWktZU+iPEKEyLhuxih1SUpqKR0Y
OQ0TNfYyb+al9NPQyGOBBbhmzJ5izhFFQBkAxCcdrSzUaGZzjFiL2cFa7kRl
f9/dAfbpLc5ful0Ip7ayC2TMPmeSL/gs0US5qnNai9kM1GLGHt7koSWa06bh
IaI30P3vFXe5VMiKasZ8NqwbizBCGeXngLVX0EKU8H+R2GadOn4kTtHxygMp
30jB3hEMWC5YT8zAhX6MibMcxqKcAM2qUxCO0EPcNTkxXke+6LsGxlhazxmI
ZfvnLQtEeG/dIG7cs5W8CvX5SNuUelJLniJQM9XY83kLYXIUJ0/qJlIn7YBZ
bThBtNUWdQz80WrrTvSmG8uxeC+gs7LWLttciwlU9Ju8vFJQpxS2G/OOyxwd
cx3gL6Bwquc39CxEBwcCSvHf3ntYS6AVavnrnBvY+ypXoQR2eArvlez5jpsv
7RkQnrdxjA/V+k08WXpJ1k+p4ZpI4gfvUAWZUEY6CrIHfEGR08uGC1qk79Bp
+zJWXKcnXG0M8ycKgNx1u/4FHcYa3e4tkV3CqVbRb7MU2u6Q+JsXAoHXQvBt
7Hr9j//+P/rKrofdBVUb2+x50Lyv8jLp2LVsxDAL6E1/FMFRDWPj+1kvxSIG
57OXT8sI4YzQtdEb2VBwpudnHBiK7PrkhR6kb7S7boEoGwHs92wvrBCJdheC
Wplb6mujPgpafzRoh6yrDc2d285iZi4rh93vNQwZysi1sX3Fa1VkneY9aC4D
zpRyBDt5lbgXlPfM/RzZHTQ4vZGJaSDeUKSVYMbjc2kzkaQnAYWB2CqKgdYI
Z3H1aBfFMBZt8MRZo+0m+/cuQUreysLjkxYBlLqiyb/HVYkjS9LOs92GX+ym
4PAAezAOPFWseu9mt2t0L4Ny06ODwb2gL7pWYdI8AJVgRj/zvUZhfpCX8OZO
5pU4i9JTO/QFJ7wf0XTMCl+CMLDrp16YMF/zwiUpTpZnGjuPeWYQRCFEiV2F
CYGGmk5oluCdHLpxA4kA3TSQkPshtT8JOo4HRZFQFFgUyHz3DmyFsc7Kr+CX
X7oFW1D0689MkG4+qShNWeKoOtOSlqKJs4jZAejFMrzsEZ2RlNiJ3F1seGMg
WnNk4xIbpK4xbALdnB2TerBqOk6YH8u5dkcK1jexsy9JRaManynMnYpppDEF
LiFPbrOhLMGR+JDpvR0vqFdwg1PLcEHr85phulTvMPILauXp0BQerQ+tNxv1
KUnpKKq95DYelONlWq/99an48D58/sOZVC6tfYj42g+mbDEWgbP+gw8uZXF0
343a+6GDSq9pBctEGhKLAKtPUpL8Eh4yDQ6E0P3HpvYi95WXYhorLo9OfA8R
9974iM1cmntXW48Bfqq5lgj81Jl5VKNJ4RcxUNRfgg+GMhqBm4Vv0+AF5vZS
/VDUdKU+PqM9BjsYoHM55pHafx6z84Jbwf60YROClcpOmnBSsCGtwcisc+rq
ErtUFOLvGnSDsGZDZ8xagIm2R1X0cO0QyfBYUioG8tK0TEc/UYRg9FQiRyok
0Sl2C7Sr82FHabKoaW8QSiZptyTFCjoty/z8MMqRCteowETo365+fykyHddR
Slio3ksCYWgDO61KROYKV9UpkcCo0WfPOy50KnPaaql4zRw2adcmYqtRN8lO
UEToFJV3rNwTJqPtfX3rlL4hv6mkCjyW/6xyilWsiXN3ahoj0iR2fyT3k7zq
2M7BfBxUIwrKZ+/N++zuXVUQ8BWnEakrrPWM/BJ372b0Y6Qm/PNHRfez7lvP
9Ur+7//1W/8DY596DeM3TuthlC/6gX/eY9EuVmPo0TCHHPFAVCn1CMjtstae
ljsf/Q0Tlk4nv30X+T/vpUkbzZJwFoOKl+IrTnu2NcsMt5chhGJIC+X8THZX
iOuu41sbC5NCH5ul8Lnn2onfI0I7xE4N9ugEc8E7bkxQZkkIe0cH4/5HCqsO
Ho8frO8mQtLVNyyP/CrIJ7xD6EHW8VJJZUXmbuyV1ZrOBSVK+moHVkMl7BHx
vg4PqI8cXZx6FrzmfetEnBGsd+VSh4S1kVCW2UdUxVsCtuWMWiAoJryX+ZtT
zrO3j3qvDRkZE5MW026lALMePUXsUcFzncMLlMQeWjGeucI5gTKDJ67nLQRe
CGcGH9oFZgBp35VYtPmNjc7wYMepmXBqh6RkzEASkOenSjsHSu4O2itUgA1W
ZHPBBKFAo3o2STg0LCJQpTd0NHNTpjoOUyVsIPaZiub7IGr3vOggyiXqQXMf
CAKYfkGMLC2IMdoZ1IcTQcmo1TA64KJuNYyose4HC2Jk79+bbkmMbFdJDPgx
FcXgXqR0bh/ckH/0fiBXMWW+JeiBJzjYpd27ouanbo65ZXN69UJu3ZyDFe4n
DXso+/QkMhP+yzcLmKDUhbchB6v3DC11eZHFKauYqlfavPLpvC0XxaeEEzI0
pHxttzyRD28NaMWEbeznwBDrDGaEfuxHChUXaM1RsoxpQ7LMTrPnJmm0JzWt
4PMGaIHaucAxowc5NOHKZvLV7McThUlEH9GEsSqmjarWcP8TqjGkVTijvgz0
w5UOgX884ZpPkbGPHQlOEzMzyV/ARZBO7dq+ledXNeouC7mHLiybZZoflFbb
oRKftAKNaeq8tbzGDK7N1/CrgwNZyPv3so5D/CN+dXKgC6GVaDuhWRCzWMaY
KpsbifDeZq1G+HCut9xDJXXcc/u+RCY2jf5ogGz2n0XUkq54J+tq+wlCUAGE
sbb/UBCU8Ndf/8/HqbS/fV2oUH/M9HBdkb/sV6/tn72uY5zrc2Rkv3Jdz2tx
1hVVcI3HqRTS4SHks4K54+hdJ/j8mX/sw+96+p94kezhJ/Iu/PDvui5f+JhH
xnfd76yLeNvu9/7KdXVe9F9AG9nHET3SPKO4P+om//PX9bt/Ih1++k+kw8/+
Px3yb+/eJe3zI8nwn76uz+W8gnbzgXW9+DVUN7yuL3rviiptDr3rN9D88b2h
d+2kxMF19alueF3Hx7etq/fe/0doXp1iu430nncsmPjzHfHDKEV1u7acfxRS
hqzVrhGdVNUoME7BA+nM4c0oQUEZrS0QVwXHkj04OYfIEW5WkeYY7Jh2t4nm
bFkXM8IOhGp0tlzH5ZAiiLiknnKRzn65YG0AGmWXR8Cr/sTIE2bCT2paS+l7
Z3SmmmZoS1K1glAZ0Wi4r6POGLT0hzjZ41AFDRegaWNRYd1Igxa4h2IYcxe2
3VQ1Re60wVpwrSVozCGsEaWpSlmitGFbQidp59mo2qClclmdLeH+4ClVYcTK
xSDPPghGgGzctmd+Xbhci5n48evGN8BEAxibqOIZEkKuf5LSXISqerNN+LtO
6A2rDga0gbKIiXemVjXjiQWt2kkDSSLWofEvgaJTvHMncs6D9aBvnfIHkXMD
Bt00VecdfjZGC+Z2pnQQL5a1DA9QlHaJuQ8gzYqGglJRvcykEk0MUfQdWmlr
Pxll90eg+ODCPsOGQ9eM/DU6ZBaV4JxyDUtyCeMdJS5ccHW6iAdLvAQrcUnE
up5Ku9/a9xBJvb++FUT/RnNgM1QfWqE1zoCy4Obt4NyInXwihcTgj5+qi4Cg
HKnjtYMUwiqocF5UkaClVnlW8cTkQQnhBnS/aFaSOt7FkCbOAsfUJmmhzOi8
UCC0E9fOYnexUT5QDGGt4pLdNXmTNQtOr3cBHJkCVcv6xjCD8UAHrReu1fFw
RK0tRxQReeozzsAKx+MM5aZJWJ1ZKax0lml8QFMH1O8U57f4fsm4XxHwjUAo
iFxKHGp8yLJZWBmjsfMIDVpz+UsbQhMuLENdcMz8fN2ZuCpIv82swWgskipC
RrHNYESqcpsTHLwnWc/+C45YSDNHL1qZciVBNwmt+5h4jBQuQoenbuuD5KaO
5KqiUMMauxFDHPcQ/DGcw3O1cSi/26uG26H+pEqsoRA+xfgJFUGwDH9koVqR
QFlyDOZIiYdo7c3lhjrOFioMsAKQNODR+h3Koj4fZV+MQEPlNYP2uI5EhYuh
Zt0MpL7jzWE53FxKgmOmiCMHpF1NS2k0miKftNIlt09UFTWWId3crZCdpVvN
tScQj4rs6RTZFXzli09k7+7g/R/DJrHWCF/GCQVnvo2uHWnJ5l2Fy1wkX7Sd
kMzeCPIqKgjj0haq8Ki9zkNZvriJl7z3ydmLc3PwxM5JNYwqm2gbaNxr7RB9
yKwZqyW6etFSS9hVPd+UdFtMaOtDlf3WDK6BD5nsakqpvtwUcy7k46GajJTW
i6mQEd/CoB3skpl0MYoUbKoJm1OOAfX0DVeBXoD3nRVswv7Sq7a9XukizDu1
0CaGOmkn+mHoyuoXdmBXa5gFKUxzLLNjzB+zU6q/6sFVefavr3nC//om1kPu
EqolDqBoyGQOg0jqMc5iHE6iB0B3KrY4QoVHnB1//qn2o/ujB5z5Rw/cobJX
/z4piBlUbrk6dyWCBeNguTeV77yhhG+m0HUyBdo3T76TyeTuhQQV/hiR+kVo
h0sR+nkutRll1OgCwJgXF7QwhBmOLi5wVUl/WF71feAxvgtDQkk9bz+j6BwM
RHB/BjnH1emQsHdtvafGuxMtlgQDrTfNupb2NTof5tdqMFTb2CJMyqXJ2nMY
B3UG/9Jec8RQ7n4aalPhcgNu6o++fKVG/HHt6WLCuFRZAOFIEpFxXGURRhnS
ouUkL+KCUWnreMNdmedNvmiDwSKV63PuzVKGbOokr04pp6Uj+H3Ie7phFlZQ
NbNV3WoHOCxbpJADViepuJLQaWy0GM92WaTfFG6ZYMUoMShc8IR7zevZhnlF
xLPE/jo+HAbFc4/LAdKLQq2+aIAeC0rIExkwj8sWh/oC3IopolNKP1TOZ7ua
kQgLVX0uLqjV94JT/ElYXVz4vogm4ouZJkFEu0jpqHV9JU2CebeEfHzCHwpH
0HxSVqxGWCpIevA7LxrxXa0zQ7vGzIs6efORl/Ul1lpGLInok47z4lBngHVH
+E7XXZBU7lIqYHuVlEUJpiZt0i8uOLNe0UG8e1LBAqwJZCKM5PVklZOGFNUm
2Qqgn90jEY/q380oQbyzUQcXF8djMLnH9WJc7ZTTFxeHmCRh9O3sKhiSqp3h
CzZDgJGyNNcXGHgvqqy3vJCxOgHZxRumfYuDfKk2eLMc02S0mWkBVK+Gq02y
pz/dSwtv+on0KSofoiIVPhTy3lQwfb48hIqgLnO9YqwRx/MVUqYJcOqmW7sj
Lv4pHRMRXwU3ECyfuRSSSy4K1wj729+5xhL9w6jQ5/YmYBqpchR+0uNe3u7K
07Q7LX4WWz2I+1SvtOcAbBP/A9dRiyoO0zzXw39GVEir+rpzAuK0dAMGnIJP
+DS5DDcYEu8HbmSSaZ10JlxK+kzK61NqxJ36vsLzxk7bW/GaKdW43h4Srvkf
u40RF7l1Ox/29vG2alBddoJkNMWc2fG0fpvd5FhDDK2G3g6Knt0tS7yLUYEm
ayh+R51OU9JTLHx4bxjvIB2Ge7Epj/uH7fUpcM5dm+wGiVZzy0HoNxgQAE2I
GnxSgqQ3WrvVyd4PFOTo0eHuTdthgvVFxD92x6QqXCgLF2q4evNaQzKhQnN2
xKb6IjbV9ed7nBonRffLgqoA7elu74UuVdx6KymXINaYV7JDO+U2wa4O8Eff
OypOnEAD2UvVumHsMqWZAhc57JdrloJKNLNRqGoZbgZ7DrCoNHlJk9o2mPxq
37a4hdhwu5phNU4nxc1GrNt4oiN2yFla1DywqNy6aCK3r87yyC+gD6wLuNAi
5rk9LttNV6Fk8qAOd5oh+zmC7B2FRh552QoCrkPnAQwmQY2Ncl/PdZNLoARg
5DZgIXPdi7SYVrii6J1m1uWPiLzVqAUmHXoE3T3UFyTPvFa+AL1zGSnSnM/l
NwJtd4LWpT/o88UJk3rE3/2UN46bLw2onrsYremzcDUatIIeq1Azb5cNqPvx
8dSVKIV5WhPmrO31koq9r+KhJ3PuYySFoz6unKVqV1iRXwV/VZuEBrzQxb4Q
BBrM3U6eGJigOLS1h41oe5GBHpId2cigSk1lYpFLMJfV9NuUc628lpvkSCbZ
aSeSHCugudSL9BkWWu0xLd3HqFqUA8M9Q6QLBf7q0Pc1pgZLO80VfiTsVJ71
7czUW2OCAt3vCBLtemDZDt7kqC8GumulUlf2MABr392xm8V4tsrHAW0L8uD7
itINNT4TZbuHQu4DxfOZqNEPRnYM5WNUVNSPY/TjqJ6YMHB8l7azjLmzzjUo
pl50jHotXWnnsP1GdB6UnKtFwfleFE1IGKSmfFLOSpSirSQ4UogcE+qRHfu+
dWG1HCryedXU0DWXRhCSbYpt36npemNkahO/oiiATSSyBg4oroNBkIQqK9zk
j2pBI6NBF+euTY26HUplsE7QwlADaxeZc7fu/WXufWxTzd2JjsBERzBQQv/j
TsJ0TyLrnkRvh3YfiOkfSOYPxKMKiD2h01zhIZTOQHNlQuZEbBNZsKIDIWJC
mJl0bQqJ7tyoAV0wvXQc9nPEeeyDPh3PnYeyCrSY6CjSKhQLM9hkAJ/ZTFdF
q4VYdjUXUQmUzMn3U40D+X6r0/K1PN24iJgJSmTlySvOaN6BOg9Bnamd5RSV
48o66W+JjEJrlzx0ZZH2KjPkbXP/Jp3/2HR2tz8QCRXYLZ+2kbg1w/yAz0U5
eoMJ2rpgII7J1SSfqE6Esdemdi5cZKNJ8o18E3qJ0heixtzyjqg0bQ4fRD5n
0qkEq4K6ISI0UK5jM+910ctBH6fVR3yJEtLMucoALl2aKMahEon30gbFub7b
XowOvY/A3S0DIExS36H2hUl3d+xjV6R3zUVGX0LhHjAQekiAXhW6FMTdNjgq
Z1EMSoYeiF9//5Nh/c7C1cIqN1IXkhYUlb2kTZZdNH6zH3QoX49vFiXQU26j
NrKTiw7sklpRJSULEbNCpEF4pUWfjwfh7TKpBiB6GBOE1FgsfVPdufZPCPKD
Yt4igAb7q++WBOY3yuQgCcxHS4IB0awTHXFj31nRphFQCi4s65LL+TbStpx6
WWBLvnJ8Uzclu3UKj+xSySsJNbuvKNcBYEYweMndyEdC0JLACkjUe1aZ2MYp
tnC4MYmAFbmA2NSG6nhJbW6BJ2A7rtGHZivJ/h39JQBIhlYBawSOMGPkmP5S
CNMkVZS4eDGZcVSiR/ABUiw2lH3g5sV8GaT/VeMM8yVsB9y4uPMIGVrwSgpk
idMWSY2gVr2cWkL1MVXq9k7SwkFwMZHHR49wLycQNXnrKzDS7ScLgJkKFYYD
u/vbyiI6pMZLggKcJ4O1WRqL5Q3QMP/IqiwU3F0W04KG6jb25ES6gWOVfYu6
H+DfyJPB2olXNgkJh4eOSFfDdS1V3QgjxzV4JQ6bFIpOm/nuCB6wlmCJYKTJ
3KbtcUcil+6NyI0/MNxliYPgN4M7zYauFBiU4uT4JXYGjbKdKcoel83BUuSI
nIj3PAzKHhz21gp+kSG2A0uQIiBSJLvwBdI++vjZh8OFtnKVXLEpKVXeQHx1
6pdgUJtae1GdglQACQ/qNRsqpCo6v0aQuhzyZGlduPDXopIESSk4QxyCTGhU
GFrFtxj2JUk52rjwrlAitkol4SblBOIGlgiU2PjumoiArLb9cMYkO6eYf7oD
5NygBgX6e6rYRBdJDAh4XQtXZsYRv+RdETFJdPQGHXCF1ym0AjDhXuYmYlwM
8PI+Q5mmWNBNPd1wl47AS0Tjk6JPakeE3mopBxrSKIgeC9Semer76lRarFJ7
d5M6pHCfnYUCM7Xi1Q1BGM5hsaQMwvhEZmYRu9iUr0aP0hypXAhlVjdcXnLE
iFCC8FIjRs+/osX54oEK0erbHSYlfi2Z5kvRootqh8I4XF+RIsZRPS/Sf+Sq
wzbikXTaGXr2QKJgoNXvTj5gzi1WbTs+nnxCVVcZ6BawA3Ep9zLCmvmotK8T
2TveUUTqvaZeJOWQz8CAKumwKZbx6rBfpjb0xeNR3bRTBShNwI+6vJID6xHX
ztXyPXME9qEueQRf5P5vWGLF/2U8j7+SUAerDZzwTTUSRwNVWd1htHs9q0Pg
6PB4fl2EdhyRRhO1ohb3ve8dEXdwYh7X05XZNrG+czUlRADtc1NFDxLjDAmT
9iKiwstvre8TiWneN1wo8UvfPvth0gWaysI+P1ddhxsp+D6cqw1V5rJvZyUX
2+637k76nJHWQVXHRFxiJWISs05UdPGphVvJpe5Ku2gp7d0jYUc0Lbr2onoM
FhwjZK6vAu9b9YYXfHj5EmZMXZ9R88MY8/JRe5M23B6xKppTGQXsXsuKgBDA
JnW8wkFKgRfTuWIq0JC0kCaoVdWO0yDfuCJQBe/e6Y4ed/zx8QkNMSSpQ2nD
9Mjjyv201QGAapDuBM5R3xebaqs8tAQYMuXw+4EOMmioUg1cBNlTFQnqeHDF
2VW90vSxjz5p7cdwaZDOZGREuqgvlVCgza+mBpr51NU5H/JURRzEOwTII1IL
ijsqPrcrhhBXHyRJ2qMtrppoJBEn7c3QUhIhl4/oJdoJrDL0Wth6SL7xSA/f
nTutox8nH6iwGCRX4+s9Crj2gE/90PexWwdAtbcv+g2QCMJuVDghP+UGpbv7
VNAFfgpk3Qtz++bEUahEXCic7xWzznRH0WdDgD6UewdgGPqCFvuH/f1PxHj0
suCdTTqh47IkDOSLjAbnWX/zQ6CViy3R/hbcG9RQlOthVNtReZWvnFhx6gOa
0pXthFm1UrTZvRVklROolILDHWA/3Riqztg2OSm0xvvBCbwagZk7oThSNQkX
PIQoxorzSkpx7BMVlOShGBow3LwMDIMB+HEHpeuj59q8aFekz/iLpDosxrL7
Hc8xm4l9iNl+vLsJk9on3eZcGcTDNHHz3R1gHeM0m/MXhRMLAtc3FXD97IkE
sCG0H9dah43xvEmVEqeVv0nQ+XwIhJLqG5EiAo5Z6rwb8fXg1vOxnVHDH9uO
HyHymfEKAfeQrpQLqW5Dpbd+GUo0KJt1HZetTKt4BvU09FmQPBqfCZImtHkU
M53C2enz084JdPeaLUP+Jffl4EdPZ1jpsrTzS/Efghra+ah3bhjYSHqIo9KG
twSWdltDZcaTsruEmkpRAqt/WZamZaxtjT4rdNWX62UOF58kHrk0zc2yppJt
fH2xUw1LWUzA8v4sP2GJH468v47remNGFxe4k/ZzWnKJ3RxHGAFukf7J2rup
myvf1aqx+QNjHk3+PMm+BFIBOVFgu6JZ3bbZk3KzbDC09gSM8rfZV//n3yuk
qlH253pZZV81aG6fW6zu/AydDM3IPMvfZi/yMh/BJ7At324qB2/DakWPwOoF
YZ+dtxakFfzgSV5e1dgXyVY/XwGn+hL+MAeC/292NYV9+b82hkrYFfEAAA== [rfced] Font styling

a) Use of <tt>

This file lists terms enclosed in <tt> in this document:
https://www.rfc-editor.org/authors/rfc9955-TT.txt

Some of these terms appear both with and without <tt>. For example, we see
"[hybrid] signatures" and "[hybrid]" enclosed in <tt>, but we also see
instances of "[hybrid]" and "hybrid" without <tt>. Please review to ensure
the usage of <tt> is correct and consistent. Let us know if any updates are
needed using OLD/NEW format.

  Note: In the HTML and PDF outputs, <tt> yields fixed-width font. In the
        TXT output, there is no change.

b) Use of <em>

This is only used in the direct quote in Section 4. The emphasis may be
difficult to see in the TXT output. Please review.

  Note: In the HTML and PDF outputs, <em> yields italics. In the TXT output,
        <em> yields an underscore before and after.
-->

<!-- [rfced] Terminology

a) Should the four instances of "scale" in the document be updated to
"spectrum"?

Current:
   Non-separability is not a singular definition but rather is a scale,
   representing degrees of separability hardness, visualized in
   Figure 1.
   ...
   Third on the scale is the Strong Non-Separability notion, in which
   separability detection is dependent on artifacts in the signature
   itself.
   ...
   In this respect, there is a scale of approval that developers may
   consider as to whether they are using at least one approved component
   algorithm implementation ...
   ...
   We provide a scale for the different nuances of approval of the
   hybrid combiners, where "approval" means that a software
   implementation of a component algorithm can be used unmodified for
   creation of the hybrid signature.

b) In Table 2, should instances of "cert" and "certs" be updates to
"certificate" and "certificates"?

c) The following terms are used in the document. Please review to ensure
consistent and correct usage. Let us know if any updates are needed.

component message forgery attack
component algorithm forgery (and component algorithm forgeries)
component forgery (and component forgeries)
component forgery attacks
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Great Multivariate Short Signature (GeMSS)
 Learning With Errors (LWE)
 Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
 Post-Quantum Traditional (PQ/T)

b) Both the expansion and the acronym for the following terms are used
throughout the document. Would you like to update to using the expansion upon
first usage and the acronym for the rest of the document?

 Simultaneous Verification (SV)
 Strong Non-Separability (SNS)
 Weak Non-Separability (WNS)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

For example, please consider whether "black-box" should be updated.

In addition, please consider whether "traditional" should be updated for
clarity.  While the NIST website indicates that this term is potentially
biased, it is also ambiguous.  "Traditional" is a subjective term, as it is
not the same for everyone.

Link to NIST website:
https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1
-->

</rfc>