rfc9955.original.xml   rfc9955.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-pquip-hybrid-signature-spectrums-07" number="9955" updates="" obsoletes=""
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft consensus="true" xml:lang="en" category="info" submissionType="IETF" tocInclude
-ietf-pquip-hybrid-signature-spectrums-07" category="info" submissionType="IETF" ="true" sortRefs="true" symRefs="true" version="3">
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.29.0 -->
<front> <front>
<title abbrev="ietf-pquip-hybrid-spectrums">Hybrid signature spectrums</titl
e> <!--[rfced] Note that we have updated the short title, which appears in the runn
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signature-s ing header
pectrums-07"/> In the PDF output, as follows.
Original:
ietf-pquip-hybrid-spectrums
Current:
Hybrid Signature Spectrums
-->
<title abbrev="Hybrid Signature Spectrums">Hybrid Signature Spectrums</title
>
<seriesInfo name="RFC" value="9955"/>
<author initials="N." surname="Bindel" fullname="Nina Bindel"> <author initials="N." surname="Bindel" fullname="Nina Bindel">
<organization>SandboxAQ</organization> <organization>SandboxAQ</organization>
<address> <address>
<email>nina.bindel@sandboxaq.com</email> <email>nina.bindel@sandboxaq.com</email>
</address> </address>
</author> </author>
<author initials="B." surname="Hale" fullname="Britta Hale"> <author initials="B." surname="Hale" fullname="Britta Hale">
<organization>Naval Postgraduate School</organization> <organization>Naval Postgraduate School</organization>
<address> <address>
<email>britta.hale@nps.edu</email> <email>britta.hale@nps.edu</email>
skipping to change at line 39 skipping to change at line 49
<address> <address>
<email>durumcrustulum@gmail.com</email> <email>durumcrustulum@gmail.com</email>
</address> </address>
</author> </author>
<author initials="F." surname="Driscoll" fullname="Florence Driscoll"> <author initials="F." surname="Driscoll" fullname="Florence Driscoll">
<organization>UK National Cyber Security Centre</organization> <organization>UK National Cyber Security Centre</organization>
<address> <address>
<email>flo.d@ncsc.gov.uk</email> <email>flo.d@ncsc.gov.uk</email>
</address> </address>
</author> </author>
<date year="2025" month="June" day="20"/> <date year="2026" month="April"/>
<keyword>Internet-Draft</keyword>
<abstract> <area>SEC</area>
<?line 157?> <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>
<t>This document describes classification of design goals and security <t>This document describes classification of design goals and security
considerations for hybrid digital signature schemes, including proof considerations for hybrid digital signature schemes, including proof
composability, non-separability of the component signatures given a composability, non-separability of the component signatures given a
hybrid signature, backwards/forwards compatibility, hybrid generality, hybrid signature, backwards and forwards compatibility, hybrid generality,
and simultaneous verification.</t> and Simultaneous Verification (SV).</t>
</abstract> </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-signa
ture-spectrums"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 165?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Plans to transition protocols to post-quantum cryptography sometimes fo cus on <t>Plans to transition protocols to post-quantum cryptography sometimes fo cus on
confidentiality, given the potential risk of store and decrypt attacks, where confidentiality, given the potential risk of store and decrypt attacks, where
data encrypted today using traditional algorithms could be decrypted in the data encrypted today using traditional algorithms could be decrypted in the
future by an attacker with a sufficiently powerful quantum computer, also future by an attacker with a sufficiently powerful quantum computer, also
known as a Cryptographically-Relevant Quantum Computer (CRQC).</t> known as a Cryptographically Relevant Quantum Computer (CRQC).</t>
<t>It is important to also consider transitions to post-quantum authentica tion; <t>It is important to also consider transitions to post-quantum authentica tion;
delaying such transitions creates risks. For example, attackers may be able 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 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 is aware of these capabilities. Furthermore, there are applications where
algorithm turn-over is complex or takes a long time. For example, root algorithm turnover is complex or takes a long time. For example, root
certificates are often valid for about 20 years or longer. There are also 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 applications where future checks on past authenticity play a role, such as
long-lived digital signatures on legal documents.</t> 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 <t>Still, there have been successful attacks against algorithms using
post-quantum cryptography, as well as implementations of such post-quantum cryptography, as well as implementations of such
algorithms. Sometimes an attack exploits implementation issues, such as algorithms. Sometimes an attack exploits implementation issues, such as
<xref target="KYBERSLASH"/>, which exploits timing variations, or <xref target=" HQC_CVE"/> which exploits <xref target="KYBERSLASH"/>, which exploits timing variations, or <xref target=" HQC_CVE"/>, which exploits
implementation bugs. Sometimes an attack works for all implementations of the implementation bugs. Sometimes an attack works for all implementations of the
specified algorithm. Research has indicated that implementation-independent specified algorithm. Research indicates that implementation-independent
attacks published in 2023 or earlier had broken 48% of the proposals in Round 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 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 proposals not broken by the end of Round 1, and 36% of the proposals selected by
for Round 2 <xref target="QRCSP"/>.</t> NIST
for Round 2 <xref target="QRCSP"/>.</t>
<t>Such cryptanalysis and security concerns are one reason to consider <t>Such cryptanalysis and security concerns are one reason to consider
'hybrid' cryptographic algorithms, which combine both traditional and 'hybrid' cryptographic algorithms, which combine both traditional and
post-quantum (or more generally a combination of two or more) algorithms. A post-quantum (or more generally a combination of two or more) algorithms. A
core objective of hybrid algorithms is to protect against quantum computers core objective of hybrid algorithms is to protect against quantum computers
while at the same time making clear that the change is not reducing while at the same time making clear that the change is not reducing
security. A premise of security of these algorithms being that if at least security. A security premise for these algorithms is that if at least
one of the two component algorithms of the hybrid scheme holds, the one of the two component algorithms of the hybrid scheme holds, the
confidentiality or authenticity offered by that scheme is maintained. It confidentiality or authenticity offered by that scheme is maintained. It
should be noted that the word 'hybrid' has many uses, but this document uses should be noted that the word 'hybrid' has many uses, but this document uses
'hybrid' only in this algorithm sense.</t> 'hybrid' only in this algorithm sense.</t>
<t>Whether or not hybridization is desired depends on the use case and sec urity <t>Whether or not hybridization is desired depends on the use case and sec urity
threat model. Users may recognize a need to start post-quantum transition, 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, even while issues such as those described above are a concern. For this,
hybridization can support transition. It should be noted that hybridization hybridization can support transition. It should be noted that hybridization
is not necessary for all systems; recommendations on system types or analysis 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 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 where hybridization is determined to be advantageous, a decision on how to
hybridize needs to be made. With many options available, this document is 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 intended to provide context on some of the trade-offs and nuances to
consider.</t> consider.</t>
<t>Hybridization of digital signatures, where the hybrid signature may be <t>Hybridization of digital signatures, where the hybrid signature may be
expected to attest to both standard and post-quantum components, is subtle to 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 design and implement due to the potential separability of the hybrid/dual
signatures and the risk of downgrade/stripping attacks. There are also a signatures and the risk of downgrade/stripping attacks. There are also a
range of requirements and properties that may be required from hybrid range of requirements and properties that may be required from hybrid
signatures, which will be discussed in this document. Some of these are signatures, which will be discussed in this document. Some of these are
mutually exclusive, which highlights the importance of considering use-case mutually exclusive, which highlights the importance of considering use-case-spec
specific requirements.</t> ific requirements.</t>
<t>This document focuses on explaining a spectrum of different hybrid sign ature <t>This document focuses on explaining a spectrum of different hybrid sign ature
scheme design categories and different security goals for them. It is scheme design categories and different security goals for them. It is
intended as a resource for designers and implementers of hybrid signature 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 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 their use case. In scope limitations, it does not attempt to give concrete
recommendations for any use case. It also intentionally does not propose recommendations for any use case. It also intentionally does not propose
concrete hybrid signature combiners or instantiations thereof. As with the concrete hybrid signature combiners or instantiations thereof. As with the
data authenticity guarantees provided by any digital signature, the security data authenticity guarantees provided by any digital signature, the security
guarantees discussed in this document are reliant on correct provisioning and guarantees discussed in this document are reliant on correct provisioning and
management of the keys involved, e.g. entity authentication, key revocation management of the keys involved, e.g., entity authentication, key revocation,
etc. This document only considers scenarios with a single signer and a etc. This document only considers scenarios with a single signer and a
single verifier, constructions with multiple signers or verifiers are out of single verifier; constructions with multiple signers or verifiers are out of
scope.</t> scope.</t>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>We follow existing Internet documents on hybrid terminology <xref tar <t>We follow existing documents on hybrid terminology <xref target="RFC9
get="RFC9794"/> and 794"/> and
hybrid key encapsulation mechanisms (KEM) <xref target="I-D.ietf-tls-hybrid-desi hybrid key encapsulation mechanisms (KEMs) <xref target="RFC9954"/> to
gn"/> to
enable settling on a consistent language. We will make clear when this is not enable settling on a consistent language. We will make clear when this is not
possible. In particular, we follow the definition of 'post-quantum possible. In particular, we follow the definitions of 'post-quantum
algorithm', 'traditional algorithms', and 'combiner'. Moreover, we use the algorithm', 'traditional algorithm', and 'combiner'. Moreover, we use the
definition of 'certificate' to mean 'public-key certificate' as defined in definition of 'certificate' to mean 'public-key certificate' as defined in
<xref target="RFC4949"/>.</t> <xref target="RFC4949"/>.</t>
<ul spacing="normal">
<li> <dl spacing="normal" newline="false">
<t>Signature scheme: A signature scheme is defined via the following <dt>Signature scheme:</dt><dd><t>A signature scheme is defined via the
three algorithms: following three algorithms:</t>
</t> <dl spacing="normal" newline="true">
<ul spacing="normal"> <dt><tt>KeyGen() -&gt; (pk, sk)</tt>:</dt><dd>A probabilistic key
<li> generation algorithm, which generates a public verifying key <tt>pk</tt>
<t><tt>KeyGen() -&gt; (pk, sk)</tt>: A probabilistic key generat and a secret signing key <tt>sk</tt>.</dd>
ion algorithm, <dt><tt>Sign(sk, m) -&gt; (sig)</tt>:</dt><dd>A probabilistic signature
which generates a public verifying key <tt>pk</tt> and a secret signing key generation, which takes as input a secret signing key <tt>sk</tt> and a
<tt>sk</tt>.</t> message <tt>m</tt>, and outputs a signature <tt>sig</tt>. In this document,
</li> the secret signing key <tt>sk</tt> is assumed to be implicit for
<li> notational simplicity, and the following notation is used: <tt>Sign(m)
<t><tt>Sign(sk, m) -&gt; (sig)</tt>: A probabilistic signature g -&gt; (sig)</tt>. If the message <tt>m</tt> is comprised of multiple
eneration, which fields, <tt>m1, m2, ..., mN</tt>, this is notated as <tt>Sign(m) = Sign (m1,
takes as input a secret signing key <tt>sk</tt> and a message <tt>m</tt>, and m2, ... mN) -&gt; (sig)</tt>.</dd>
outputs a signature <tt>sig</tt>. <dt><tt>Verify(pk, sig, m) -&gt; b</tt>:</dt><dd>A verification algorithm,
In this draft, the secret signing key <tt>sk</tt> is assumed to be implicit which takes as input a public verifying key <tt>pk</tt>, a signature
for notational simplicity, and the following notation is used: <tt>sig</tt>, and a message <tt>m</tt>, and outputs a bit <tt>b</tt>
<tt>Sign(m) -&gt; (sig)</tt>. If the message <tt>m</tt> is comprised of multiple indicating <tt>accept (b=1)</tt> or <tt>reject (b=0)</tt> of the signature
fields, for the message <tt>m</tt>.</dd>
<tt>m1, m2, ..., mN</tt>, this is notated <tt>Sign(m) = Sign (m1, m2, ... mN) -& </dl>
gt; </dd>
(sig)</tt>.</t>
</li> <!-- [rfced] We were unable to find the quoted text below in [RFC9794].
<li> Is this quote from [RFC9794] or another reference?
<t><tt>Verify(pk, sig, m) -&gt; b</tt>: A verification algorithm
, which takes as Original:
input a public verifying key <tt>pk</tt>, a signature <tt>sig</tt> and a message This is different from [RFC9794] where the term
<tt>m</tt>, and outputs a bit <tt>b</tt> indicating <tt>accept (b=1)</tt> or <tt is used as a specific instantiation of hybrid schemes such that
>reject "where multiple cryptographic algorithms are combined to form a
(b=0)</tt> of the signature for message <tt>m</tt>.</t> single key or signature such that they can be treated as a single
</li> atomic object at the protocol level."
</ul> -->
</li>
<li> <!--[rfced] To improve readability, may we break up this long sentence
<t>Hybrid signature scheme: Following <xref target="RFC9794"/>, we d into two sentences and update as follows?
efine a hybrid signature
scheme to be "a multi-algorithm digital signature scheme made up of two or Original:
more component digital signature algorithms". While it often makes sense While it often makes sense for security purposes to require that
for security purposes to require that the security of the component schemes the security of the component schemes is based on the hardness of
is based on the hardness of different cryptographic assumptions, in other different cryptographic assumptions, in other cases hybrid schemes
cases hybrid schemes might be motivated, e.g., by interoperability of might be motivated, e.g., by interoperability of variants on the
variants on the same scheme and as such both component schemes are based on same scheme and as such both component schemes are based on the
the same hardness assumption (e.g., both post-quantum assumptions or even same hardness assumption (e.g., both post-quantum assumptions or
both the same concrete assumption such as Ring LWE). We allow this even both the same concrete assumption such as Ring LWE).
explicitly. This means in particular that in contrast to <xref target="RFC9794"/
>, we will Perhaps:
use the more general term 'hybrid signature scheme' instead of requiring For security purposes, it often makes sense to require that
one post-quantum and one traditional algorithm (i.e., PQ/T hybrid signature the security of the component schemes be based on the hardness of
schemes) to allow also the combination of several post-quantum different cryptographic assumptions, but in some cases, hybrid schemes
algorithms. The term 'composite scheme' has sometimes been used as a might be motivated, e.g., by interoperability of variants on the
synonym for 'hybrid scheme'. This is different from <xref target="RFC9794"/> whe same scheme. As such, both component schemes are based on the
re the same hardness assumption (e.g., both post-quantum assumptions or
term is used as a specific instantiation of hybrid schemes such that "where even both the same concrete assumption, such as Ring Learning With Errors (LW
multiple cryptographic algorithms are combined to form a single key or E)).
signature such that they can be treated as a single atomic object at the -->
protocol level." To avoid confusing we will avoid the term 'composite
scheme'.</t> <dt>Hybrid signature scheme:</dt><dd>Following <xref target="RFC9794"/>, we
</li> define a hybrid signature scheme to be "a multi-algorithm digital signature
<li> scheme made up of two or more component digital signature algorithms". While
<t>Hybrid signature: A hybrid signature is the output of the hybrid it often makes sense for security purposes to require that the security of
signature the component schemes is based on the hardness of different cryptographic
scheme's signature generation. As synonyms we might use 'dual signature'. assumptions, in other cases, hybrid schemes might be motivated, e.g., by
For example, NIST defines a dual signature as "two or more signatures on a interoperability of variants on the same scheme, and as such, both component
common message" <xref target="NIST_PQC_FAQ"/>. For the same reason as above we w schemes are based on the same hardness assumption (e.g., both post-quantum
ill avoid assumptions or even both the same concrete assumption, such as Ring Learning W
using the term 'composite signature' although it sometimes appears as a ith Errors (LWE)). We
synonym for 'hybrid/dual signature'.</t> allow this explicitly. In particular, this means that in contrast to <xref
</li> target="RFC9794"/>, we will use the more general term 'hybrid signature
<li> scheme' instead of requiring one post-quantum and one traditional algorithm
<t>Component (signature) scheme: Component signature schemes are the (i.e., Post-Quantum Traditional (PQ/T) hybrid signature schemes) to allow also
cryptographic algorithms contributing to the hybrid signature scheme. This the combination of
has a similar purpose as in <xref target="RFC9794"/>. 'Ingredient (signature) sc several post-quantum algorithms. The term 'composite scheme' has sometimes
heme' may been used as a synonym for 'hybrid scheme'. This is different from <xref
be used as a synonym.</t> target="RFC9794"/> where the term is used as a specific instantiation of
</li> hybrid schemes such that "where multiple cryptographic algorithms are
<li> combined to form a single key or signature such that they can be treated as
<t>Next-generation algorithms: Following <xref target="I-D.ietf-tls- a single atomic object at the protocol level". To avoid confusion, we will
hybrid-design"/>, we avoid the term 'composite scheme'.</dd>
define next-generation algorithms to be "algorithms which are not yet <dt>Hybrid signature:</dt><dd>A hybrid signature is the output of the hybrid
widely deployed but which may eventually be widely deployed". Hybrid signature scheme's signature generation. As a synonym, we might use 'dual
signatures are mostly motivated by preparation for post-quantum transition signature'. For example, NIST defines a dual signature as "two or more
or use in long-term post-quantum deployment, hence the reference to signatures on a common message" <xref target="NIST_PQC_FAQ"/>. For the same
post-quantum algorithms through this document. However, the majority of reason as above, we will avoid using the term 'composite signature', although
the discussion in this document applies equally well to future transitions it sometimes appears as a synonym for 'hybrid/dual signature'.</dd>
to other next-generation algorithms.</t> <dt>Component (signature) scheme:</dt><dd>Component signature schemes are
</li> the cryptographic algorithms contributing to the hybrid signature
<li> scheme. This has a similar purpose as in <xref
<t>Policy: Throughout this document we refer to 'policy' in the cont target="RFC9794"/>. 'Ingredient (signature) scheme' may be used as a
ext of synonym.</dd>
e.g., a system policy requiring verification of two signatures, an RFC <dt>Next-generation algorithms:</dt><dd>Following <xref
description, guidance documentation, etc. Similar terminology may include target="RFC9954"/>, we define next-generation algorithms
'security configuration settings', or related phrasing. We treat these to be "algorithms that are not yet widely deployed but may eventually
terms as equivalent for the purposes of this document.</t> be widely deployed". Hybrid signatures are mostly motivated by preparation
</li> for post-quantum transition or use in long-term post-quantum deployment,
<li> hence the reference to post-quantum algorithms in this document.
<t>Artifact: An artifact is evidence of the sender's intent to hybri However, the majority of the discussion in this document applies equally
dize a well to future transitions to other next-generation algorithms.</dd>
signature that remains even if a component signature is removed. Artifacts <dt>Policy:</dt><dd>Throughout this document, we refer to 'policy' in the
can be e.g., at the algorithmic level (e.g., within the digital signature), context of, e.g., a system policy requiring verification of two signatures,
or at the protocol level (e.g., within the certificate), or on the system an RFC description, guidance documentation, etc. Similar terminology may
policy level (e.g., within the message). Artifacts should be easily include 'security configuration settings' or related phrasing. We treat
identifiable by the receiver in the case of signature stripping.</t> these terms as equivalent for the purposes of this document.</dd>
</li> <dt>Artifact:</dt><dd>An artifact is evidence of the sender's intent to
<li> hybridize a signature that remains even if a component signature is
<t>Stripping attack: A stripping attack refers to a case where an ad removed. Artifacts can be, e.g., at the algorithmic level (e.g., within the
versary digital signature), at the protocol level (e.g., within the certificate),
takes a message and hybrid signature pair and attempts to submit (a or on the system policy level (e.g., within the message). Artifacts should
potential modification of) the pair to a component algorithm verifier, be easily identifiable by the receiver in the case of signature
meaning that the security is based only on the remaining component scheme. stripping.</dd>
A common example of a stripping attack includes a message and hybrid <dt>Stripping attack:</dt><dd>A stripping attack refers to a case where an
signature, comprised of concatenated post-quantum and traditional adversary takes a message and hybrid signature pair and attempts to submit
signatures, where an adversary with a quantum computer simply removes the (a potential modification of) the pair to a component algorithm verifier,
post-quantum component signature and submits the (potentially changed) meaning that the security is based only on the remaining component scheme.
message and traditional component signature to a traditional verifier. This A common example of a stripping attack includes a message and hybrid
could include an authentic traditional certificate authority signature on a signature, comprised of concatenated post-quantum and traditional
certificate that was originaly hybrid-signed. An attribute of this is that signatures, where an adversary with a quantum computer simply removes the
the an honest signer would attest to generating the signature. Stripping post-quantum component signature and submits the (potentially changed)
attacks should not be confused with component message forgery attacks.</t> message and traditional component signature to a traditional verifier. This
</li> could include an authentic traditional certificate authority signature on a
<li> certificate that was originally hybrid-signed. An attribute of this is that
<t>Component message forgery attacks: A forgery attack refers to a c an honest signer would attest to generating the signature. Stripping
ase where attacks should not be confused with component message forgery attacks.</dd>
an adversary attempts to forge a (non-hybrid) signature on a message using <dt>Component message forgery attacks:</dt><dd>A forgery attack refers to a
the public key associated with a component algorithm. An common example of case where an adversary attempts to forge a (non-hybrid) signature on a
such an attack would be a quantum attacker compromising the key associated message using the public key associated with a component algorithm. A
with a traditional component algorithm and forging a message and signature common example of such an attack would be a quantum attacker compromising
pair. Message forgery attacks may be formalized with experiments such as the key associated with a traditional component algorithm and forging a
existential unforgeability under chosen-message attack (EUF-CMA) <xref target="E message and signature pair. Message forgery attacks may be formalized with
UFCMA"/>, experiments such as the Existential Unforgeability under Chosen Message Attack
while the difference introduced in component message forgery attacks is (EUF-CMA) <xref target="EUFCMA"/>, while the difference introduced in
that the key is accepted for both hybrid and single algorithm use. Further component message forgery attacks is that the key is accepted for both
discussions on this appear under <xref target="euf-cma-challenges"/>.</t> hybrid and single algorithm use. Further discussion of this appears in
</li> <xref target="euf-cma-challenges"/>.</dd>
</ul> </dl>
</section> </section>
<section anchor="motivation"> <section anchor="motivation">
<name>Motivation for Use of Hybrid Signature Schemes</name> <name>Motivation for Use of Hybrid Signature Schemes</name>
<t>Before diving into the design goals for hybrid digital signatures, it is <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 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-hybr general for hybrid algorithms, we again refer to <xref target="RFC9954"/>,
id-design"/> which summarizes these well. In addition, we explicate the motivation for
that summarizes these well. In addition, we explicate the motivation for
hybrid signatures here.</t> hybrid signatures here.</t>
<section anchor="complexity"> <section anchor="complexity">
<name>Complexity</name> <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 clarifie
d.
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 assumption s are <t>Next-generation algorithms and their underlying hardness assumption s are
often more complex than traditional algorithms. For example, the signature often more complex than traditional algorithms. For example, the signature
scheme ML-DSA <xref target="MLDSA"/> (also known as CRYSTALS-DILITHIUM) follows scheme Module-Lattice-Based Digital Signature Algorithm (ML-DSA) <xref target="M
the LDSA"/> (also known as CRYSTALS-DILITHIUM) follows the
well-known Fiat-Shamir transform <xref target="FS"/> to construct the signature well-known Fiat-Shamir transform <xref target="FS"/> to construct the signature
scheme, but scheme but
also relies on rejection sampling that is known to give cache side channel 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 information (although this does not lead to a known attack). Likewise, the
signature scheme Falcon <xref target="FALCON"/> uses complex sampling during sig nature signature scheme FALCON <xref target="FALCON"/> uses complex sampling during sig nature
generation. Furthermore, attacks against the next-generation multivariate generation. Furthermore, attacks against the next-generation multivariate
schemes Rainbow <xref target="RAINBOW"/> and GeMSS <xref target="GEMSS"/> might raise concerns for schemes Rainbow <xref target="RAINBOW"/> and Great Multivariate Short Signature (GeMSS) <xref target="GEMSS"/> might raise concerns for
conservative adopters of other algorithms, which could hinder adoption.</t> conservative adopters of other algorithms, which could hinder adoption.</t>
<t>As such, some next-generation algorithms carry a higher risk of <t>As such, some next-generation algorithms carry a higher risk of
implementation mistakes and revision of parameters compared to traditional implementation mistakes and revision of parameters compared to traditional
algorithms, such as RSA. RSA is a relatively simple algorithm to understand algorithms, such as RSA. RSA is a relatively simple algorithm to understand
and explain, yet during its existence and use there have been multiple and explain, yet during its existence and use, there have been multiple
attacks and refinements, such as adding requirements to how padding and keys attacks and refinements, such as adding requirements to how padding and keys
are chosen, and implementation issues such as cross-protocol attacks (e.g., are chosen, and implementation issues, such as cross-protocol attacks (e.g.,
component algorithm forgeries). Thus, even in a relatively simple algorithm component algorithm forgeries). Thus, even in a relatively simple algorithm,
subtleties and caveats on implementation and use can arise over time. Given subtleties and caveats on implementation and use can arise over time. Given
the complexity of next generation algorithms, the chance of such discoveries the complexity of next-generation algorithms, the chance of such discoveries
and caveats needs to be taken into account.</t> and caveats needs to be taken into account.</t>
<t>Of note, some next-generation algorithms have received considerable analysis, <t>Of note, some next-generation algorithms have received considerable analysis,
for example, following attention gathered during the NIST Post-Quantum for example, following attention gathered during the NIST Post-Quantum
Cryptography Standardization Process <xref target="NIST_PQC_FAQ"/>. However, if and when Cryptography Standardization Process <xref target="NIST_PQC_FAQ"/>. However, if and when
further information on caveats and implementation issues come to light, it is further information on caveats and implementation issues come to light, it is
quite possible that vulnerabilities will represent a weakening of security quite possible that vulnerabilities will represent a weakening of security
rather than a full "break". Such weakening may also be offset if a hybrid rather than a full "break". Such weakening may also be offset if a hybrid
approach has been used.</t> approach has been used.</t>
</section> </section>
<section anchor="time"> <section anchor="time">
<name>Time</name> <name>Time</name>
<t>In large systems, including national systems, space systems, large healthcare <t>In large systems, including national systems, space systems, large healthcare
support systems, and critical infrastructure, acquisition and procurement support systems, and critical infrastructure, acquisition and procurement
time can be measured in years and algorithm replacement may be difficult or time can be measured in years, and algorithm replacement may be difficult or
even practically impossible. Long-term commitment creates further urgency for even practically impossible. Long-term commitment creates further urgency for
immediate post-quantum algorithm selection, for example when generating root immediate post-quantum algorithm selection, for example, when generating root
certificates with their long validity windows. Additionally, for some certificates with their long validity windows. Additionally, for some
sectors, future checks on past authenticity plays a role (e.g., many legal, sectors, future checks on past authenticity plays a role (e.g., many legal,
financial, auditing, and governmental systems). This means there is a need financial, auditing, and governmental systems). This means there is a need
to transition some systems to post-quantum signature algorithms imminently. to transition some systems to post-quantum signature algorithms imminently.
However, as described above, there is a need to remain aware of potential, However, as described above, there is a need to remain aware of potential,
hidden subtleties in next-generation algorithms' resistance to standard hidden subtleties in next-generation algorithms' resistance to standard
attacks, particularly in cases where it is difficult to replace algorithms. attacks, particularly in cases where it is difficult to replace algorithms.
This combination of time pressure and complexity drives some transition This combination of time pressure and complexity drives some transition
designs towards hybridization.</t> designs towards hybridization.</t>
</section> </section>
</section> </section>
<section anchor="goals"> <section anchor="goals">
<name>Goals</name> <name>Goals</name>
<t>There are various security and usability goals that can be achieved t hrough <t>There are various security and usability goals that can be achieved t hrough
hybridization. The following provides a summary of these goals, while also hybridization. The following provides a summary of these goals while also
noting where goals are in conflict, i.e., that achievement of one goal noting where goals are in conflict, i.e., that achievement of one goal
precludes another, such as backwards compatibility.</t> precludes another, such as backwards compatibility.</t>
<section anchor="hybrid-authentication"> <section anchor="hybrid-authentication">
<name>Hybrid Authentication</name> <name>Hybrid Authentication</name>
<t>One goal of hybrid signature schemes is security. As defined in <xr ef target="RFC9794"/>, <t>One goal of hybrid signature schemes is security. As defined in <xr ef target="RFC9794"/>,
ideally a hybrid signature scheme can achieve 'hybrid authentication' which ideally a hybrid signature scheme can achieve 'hybrid authentication', which
is the property that (cryptographic) authentication is achieved by the hybrid is the property that (cryptographic) authentication is achieved by the hybrid
signature scheme provided that a least one component signature algorithm signature scheme, provided that a least one component signature algorithm
remains 'secure'. There might be, however, other goals in competition with remains 'secure'. There might be, however, other goals in competition with
this one, such as backward-compatibility - referring to the property where a this one, such as backwards compatibility -- referring to the property where a
hybrid signature may be verified by only verifying one component signature hybrid signature may be verified by only verifying one component signature
(see description below). Hybrid authentication is an umbrella term that (see description below). Hybrid authentication is an umbrella term that
encompasses more specific concepts of hybrid signature security, such as encompasses more specific concepts of hybrid signature security, such as
'hybrid unforgeability' described next.</t> 'hybrid unforgeability' described next.</t>
<section anchor="hybrid-unforgeability"> <section anchor="hybrid-unforgeability">
<name>Hybrid Unforgeability</name> <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 securit
y
assumed for only one component scheme; these cases generally use hybrid techn
iques
for their 'functional transition' pathway support.
...
In contrast, in other use cases, a hybrid scheme is used with (for example) E
UF-
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 <t>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 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 least one of the component schemes maintains that security assumption. We
call this notion 'hybrid unforgeability'; it is a specific type of hybrid call this notion 'hybrid unforgeability'; it is a specific type of hybrid
authentication. For example, the concatenation combiner in <xref target="HYBRIDS IG"/> is authentication. For example, the concatenation combiner in <xref target="HYBRIDS IG"/> is
'hybrid unforgeable'. As mentioned above, this might be incompatible with 'hybrid unforgeable'. As mentioned above, this might be incompatible with
backward-compatibility, where the EUF-CMA security of the hybrid signature backwards compatibility, where the EUF-CMA security of the hybrid signature
relies solely on the security of one of the component schemes instead of 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 relying on both, e.g., the dual message combiner using nesting in
<xref target="HYBRIDSIG"/>. For more details, we refer to our discussion below.< /t> <xref target="HYBRIDSIG"/>. For more details, refer to the discussion below.</t>
<t>Use cases where a hybrid scheme is used with, e.g., EUF-CMA secur ity assumed <t>Use cases where a hybrid scheme is used with, e.g., EUF-CMA secur ity assumed
for only one component scheme generally use hybrid techniques for their for only one component scheme generally use hybrid techniques for their
'functional transition' pathway support. For example, hybrid signatures may 'functional transition' pathway support. For example, hybrid signatures may
be used as a transition step for gradual post-quantum adoption, while be used as a transition step for gradual post-quantum adoption while
ensuring interoperability when a system includes both verifiers that only ensuring interoperability when a system includes both verifiers that only
support traditional signatures and verifiers that have been upgraded to support traditional signatures and verifiers that have been upgraded to
support post-quantum signatures.</t> support post-quantum signatures.</t>
<t>In contrast, use cases where a hybrid scheme is used with e.g., E <t>In contrast, use cases where a hybrid scheme is used with, e.g.,
UF-CMA EUF-CMA
security assumed for both component schemes without prioritisation between security assumed for both component schemes without prioritization between
them can use hybrid techniques for both functional transition and security 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 transition (i.e., a transition to ensure security even if it may not be
known which algorithm should be relied upon).</t> known which algorithm should be relied upon).</t>
</section> </section>
</section> </section>
<section anchor="proof-composability"> <section anchor="proof-composability">
<name>Proof Composability</name> <name>Proof Composability</name>
<t>Under proof composability, the component algorithms are combined in such a <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 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 properties of a hybrid signature scheme to the properties of the respective
skipping to change at line 371 skipping to change at line 519
hash functions, key derivation functions, etc. Otherwise, an entirely new hash functions, key derivation functions, etc. Otherwise, an entirely new
proof of security is required, and there is a lack of assurance that the proof of security is required, and there is a lack of assurance that the
combination builds on the standardization processes and analysis performed to combination builds on the standardization processes and analysis performed to
date on component algorithms. The resulting hybrid signature would be, in date on component algorithms. The resulting hybrid signature would be, in
effect, an entirely new algorithm of its own. The more the component 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 signature schemes are entangled, the more likely it is that an entirely new
proof is required, thus not meeting proof composability.</t> proof is required, thus not meeting proof composability.</t>
</section> </section>
<section anchor="weak-non-separability"> <section anchor="weak-non-separability">
<name>Weak Non-Separability</name> <name>Weak Non-Separability</name>
<t>Non-Separability was one of the earliest properties of hybrid digit
al <!-- [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 digit
al
signatures to be discussed <xref target="HYBRIDSIG"/>. It was defined as the gua rantee that signatures to be discussed <xref target="HYBRIDSIG"/>. It was defined as the gua rantee that
an adversary cannot simply "remove" one of the component signatures without an adversary cannot simply "remove" one of the component signatures without
evidence left behind. For example, there are artifacts that a carefully evidence left behind. For example, there are artifacts that a carefully
designed verifier may be able to identify, or that are identifiable in later designed verifier may be able to identify or that are identifiable in later
audits. This was later termed Weak Non-Separability (WNS) audits. This was later termed Weak Non-Separability (WNS)
<xref target="HYBRIDSIGDESIGN"/>. Note that WNS does not restrict an adversary f rom <xref target="HYBRIDSIGDESIGN"/>. Note that WNS does not restrict an adversary f rom
potentially creating a valid component digital signature from a hybrid one (a potentially creating a valid component digital signature from a hybrid one (a
signature stripping attack), but rather implies that such a digital signature signature stripping attack) but rather implies that such a digital signature
will contain artifacts of the separation. Thus, authentication that is will contain artifacts of the separation. Thus, authentication that is
normally assured under correct verification of digital signature(s), is now normally assured under correct verification of digital signature(s) is now
potentially also reliant on further investigation on the receiver side that potentially also reliant on further investigation on the receiver side that
may extend well beyond traditional signature verification behavior. For may extend well beyond traditional signature verification behavior. For
instance, this can intuitively be seen in cases of a message containing a 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 context note on hybrid authentication that is then signed by all component
algorithms/the hybrid signature scheme. If an adversary removes one 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 signature but not the other, then artifacts in the message itself point to
the possible existence of hybrid signature such as a label stating, "this the possible existence of a hybrid signature such as a label stating "this
message must be hybrid signed". This might be a counter measure against message must be hybrid-signed". This might be a countermeasure against
stripping attacks if the verifier expects a hybrid signature scheme to have stripping attacks if the verifier expects a hybrid signature scheme to have
this property. However, it places the responsibility of signature validity this property. However, it places the responsibility of signature validity
not only on the correct format of the message, as in a traditional signature not only on the correct format of the message, as in a traditional signature
security guarantee, but the precise content thereof.</t> security guarantee, but the precise content thereof.</t>
</section> </section>
<section anchor="strong-non-separability"> <section anchor="strong-non-separability">
<name>Strong Non-Separability</name> <name>Strong Non-Separability</name>
<t>Strong Non-Separability (SNS) is a stronger notion of WNS, introduc <t>Strong Non-Separability (SNS) is a stronger notion of WNS, which is
ed in introduced in
<xref target="HYBRIDSIGDESIGN"/>. SNS guarantees that an adversary cannot take a <xref target="HYBRIDSIGDESIGN"/>. SNS guarantees that an adversary cannot take a
s input a hybrid signature (and message) as input and output a valid component signature (
hybrid signature (and message) and output a valid component signature (and and
potentially different message) that will verify correctly. In other words, potentially different message) that will verify correctly. In other words,
separation of the hybrid signature into component signatures implies that the separation of the hybrid signature into component signatures implies that the
component signature will fail verification (of the component signature component signature will fail verification (of the component signature
scheme) entirely. Therefore, authentication is provided by the sender to the scheme) entirely. Therefore, authentication is provided by the sender to the
receiver through correct verification of the digital signature(s), as in receiver through correct verification of the digital signature(s), as in
traditional signature security experiments. It is not dependent on other traditional signature security experiments. It is not dependent on other
components, such as message content checking, or protocol level aspects, such components, such as message content checking, or protocol-level aspects, such
as public key provenance. As an illustrative example distinguishing WNS from as public key provenance. As an illustrative example distinguishing WNS from
SNS, consider the case of component algorithms <tt>Sigma_1.Sign</tt> and 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>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 = <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' = 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 (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 hybrid artifact embedded in the message instead of the signature, could be
correctly verified. The separation would be identifiable through further correctly verified. The separation would be identifiable through further
investigation, but the signature verification itself would not fail. Thus, investigation, but the signature verification itself would not fail. Thus,
this case shows WNS (assuming the verification algorithm is defined this case shows WNS (assuming the verification algorithm is defined
accordingly) but not SNS.</t> accordingly) but not SNS.</t>
<t>Some work <xref target="I-D.ietf-lamps-pq-composite-sigs"/> has loo ked at reliance on the <t>Some work <xref target="I-D.ietf-lamps-pq-composite-sigs"/> has loo ked at reliance on the
public key certificate chains to explicitly define hybrid use of the public public key certificate chains to explicitly define hybrid use of the public
key. Namely, that <tt>Sigma_1.pk</tt> cannot be used without <tt>Sigma_2.pk</tt> . This 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 implies pushing the hybrid artifacts into the protocol and system level and a
dependency on the security of other verification algorithms (namely those in dependency on the security of other verification algorithms (namely those in
the certificate chain). This further requires that security analysis of a the certificate chain). This further requires that security analysis of a
hybrid digital signature requires analysis of the key provenance, i.e., not 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 simply that a valid public key is used but how its hybridization and hybrid
artifacts have been managed throughout the entire chain. External artifacts have been managed throughout the entire chain. External
dependencies such as this may imply hybrid artifacts lie outside the scope of dependencies such as this may imply hybrid artifacts lie outside the scope of
the signature algorithm itself. SNS may potentially be achievable based on the signature algorithm itself. SNS may potentially be achievable based on
dependencies at the system level.</t> dependencies at the system level.</t>
</section> </section>
<section anchor="backwardsforwards-compatibility"> <section anchor="backwardsforwards-compatibility">
<name>Backwards/Forwards Compatibility</name> <name>Backwards and Forwards Compatibility</name>
<t>Backwards compatibility refers to the property where a hybrid signa ture may <t>Backwards compatibility refers to the property where a hybrid signa ture may
be verified by only verifying one component signature, allowing the scheme to be verified by only verifying one component signature, allowing the scheme to
be used by legacy receivers. In general, this means verifying the traditional be used by legacy receivers. In general, this means verifying the traditional
component signature scheme, potentially ignoring the post-quantum signature component signature scheme, potentially ignoring the post-quantum signature
entirely. This provides an option to transition sender systems to entirely. This provides an option to transition sender systems to
post-quantum algorithms while still supporting select legacy post-quantum algorithms while still supporting select legacy
receivers. Notably, this is a verification property; the sender has provided receivers. Notably, this is a verification property; the sender has provided
a hybrid digital signature, but the verifier is allowed, due to internal a hybrid digital signature, but the verifier is allowed, due to internal
policy and/or implementation, to only verify one component policy and/or implementation, to only verify one component
signature.</t> signature.</t>
<t>Forwards compatibility has also been a consideration in hybrid prop osals <t>Forwards compatibility has also been a consideration in hybrid prop osals
<xref target="I-D.becker-guthrie-noncomposite-hybrid-auth"/>. Forward compatibil <xref target="I-D.becker-guthrie-noncomposite-hybrid-auth"/>. Forwards compatibi
ity assumes lity assumes
that hybrid signature schemes will be used for some time, but that eventually that hybrid signature schemes will be used for some time but that eventually
all systems will transition to use only one (particularly, only one all systems will transition to use only one (particularly, only one
post-quantum) algorithm. As this is very similar to backwards compatibility, post-quantum) algorithm. As this is very similar to backwards compatibility,
it also may imply separability of a hybrid algorithm; however, it could also it also may imply separability of a hybrid algorithm; however, it could also
simply imply capability to support separate component signatures. Thus, the simply imply capability to support separate component signatures. Thus, the
key distinction between backwards and forwards compatibility is that key distinction between backwards and forwards compatibility is that
backwards compatibility may be needed for legacy systems that cannot use backwards compatibility may be needed for legacy systems that cannot use
and/or process hybrid or post-quantum signatures, whereas in forwards and/or process hybrid or post-quantum signatures, whereas in forwards
compatibility the system has those capabilities and can choose what to compatibility, the system has those capabilities and can choose what to
support (e.g., for efficiency reasons).</t> support (e.g., for efficiency reasons).</t>
<t>As noted in <xref target="I-D.ietf-tls-hybrid-design"/>, ideally, f <t>Ideally, backwards and forwards
orward/backward compatibility is achieved using redundant information as little as possible, as
compatibility is achieved using redundant information as little as possible.</t> noted in <xref target="RFC9954"/>.</t>
</section> </section>
<section anchor="simultaneous-verification"> <section anchor="simultaneous-verification">
<name>Simultaneous Verification</name> <name>Simultaneous Verification</name>
<t>Simultaneous Verification (SV) builds on SNS and was first introduc ed in <t>Simultaneous Verification (SV) builds on SNS and was first introduc ed in
<xref target="HYBRIDSIGDESIGN"/>. SV requires that not only is the entire hybrid signature <xref target="HYBRIDSIGDESIGN"/>. SV requires that not only is the entire hybrid signature
(e.g., all component signature elements) needed to achieve a successful (e.g., all component signature elements) needed to achieve a successful
verification present in the signature presented for verification, but also verification present in the signature presented for verification but also
that verification of both component algorithms occurs roughly simultaneously. that verification of both component algorithms occurs roughly simultaneously.
Namely, "missing" information needs to be computed by the verifier so that a Namely, "missing" information needs to be computed by the verifier so that a
normally functioning verification algorithm cannot "quit" the verification normally functioning verification algorithm cannot "quit" the verification
process before the hybrid signature elements attesting for both component process before the hybrid signature elements attesting for both component
algorithms are verified. This may additionally cover some error-injection and algorithms are verified. This may additionally cover some error-injection and
similar attacks, where an adversary attempts to make an otherwise honest similar attacks, where an adversary attempts to make an otherwise honest
verifier skip component algorithm verification. SV mimics traditional digital verifier skip component algorithm verification. SV mimics traditional digital
signatures guarantees, essentially ensuring that the hybrid digital signature signatures guarantees, essentially ensuring that the hybrid digital signature
behaves as a single algorithm vs. two separate component behaves as a single algorithm vs. two separate component
stages. Alternatively phrased, under an SV guarantee it is not possible for stages. Alternatively phrased, under an SV guarantee, it is not possible for
an otherwise honest verifier to initiate termination of the hybrid an otherwise honest verifier to initiate termination of the hybrid
verification upon successful verification of one component algorithm without verification upon successful verification of one component algorithm without
also knowing if the other component succeeded. Note that SV does not prevent also knowing if the other component succeeded. Note that SV does not prevent
dishonest verification, such as if a verifier maliciously implements a dishonest verification, such as if a verifier maliciously implements a
customized verification algorithm that is designed with intention to subvert customized verification algorithm that is designed with intention to subvert
the hybrid verification process or skips signature verification altogether.</t> the hybrid verification process or skips signature verification altogether.</t>
</section> </section>
<section anchor="hybrid-generality"> <section anchor="hybrid-generality">
<name>Hybrid Generality</name> <name>Hybrid Generality</name>
<t>Hybrid generality means that a general signature combiner is define
d, based <!-- [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 digi
tal
signatures.
-->
<t>Hybrid generality means that a general signature combiner is define
d based
on inherent and common structures of component digital signatures on inherent and common structures of component digital signatures
"categories." For instance, since multiple signature schemes use a "categories". For instance, since multiple signature schemes use a
Fiat-Shamir Transform, a hybrid scheme based on the transform can be made Fiat-Shamir transform, a hybrid scheme based on the transform can be made
that is generalizable to all such signatures. Such generality can also result that is generalizable to all such signatures. Such generality can also result
in simplified constructions whereas more tailored hybrid variants might be in simplified constructions, whereas more tailored hybrid variants might be
more efficient in terms of sizes and performance.</t> more efficient in terms of sizes and performance.</t>
</section> </section>
<section anchor="high-performance"> <section anchor="high-performance">
<name>High Performance</name> <name>High Performance</name>
<t>Similarly to performance goals noted for hybridization of other cry <t>Similar to performance goals noted for hybridization of other crypt
ptographic ographic
components <xref target="I-D.ietf-tls-hybrid-design"/> hybrid signature construc components <xref target="RFC9954"/>, hybrid signature constructions are
tions are expected to be as performant as possible. For most hybrid signatures, this
expected to be as performant as possible. For most hybrid signatures this
means that the computation time should only minimally exceed the sum of the means that the computation time should only minimally exceed the sum of the
component signature computation time. It is noted that performance of any 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> variety may come at the cost of other properties, such as hybrid generality.</t>
</section> </section>
<section anchor="high-space-efficiency"> <section anchor="high-space-efficiency">
<name>High Space Efficiency</name> <name>High Space Efficiency</name>
<t>Similarly to space considerations in <xref target="I-D.ietf-tls-hyb <!-- [rfced] We could not find any mention of "space" in
rid-design"/>, hybrid 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="RFC9954"/>, hybrid
signature constructions are expected to be as space performant as signature constructions are expected to be as space performant as
possible. This includes messages (as they might increase if artifacts are possible. This includes messages (as they might increase if artifacts are
used), public keys, and the hybrid signature. For the hybrid signature, size 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 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 signatures. In some cases, it may be possible for a hybrid signature to be
smaller than the concatenation of the two component signatures.</t> smaller than the concatenation of the two component signatures.</t>
</section> </section>
<section anchor="minimal-duplicate-information"> <section anchor="minimal-duplicate-information">
<name>Minimal Duplicate Information</name> <name>Minimal Duplicate Information</name>
<t>Duplicated information should be avoided when possible, as a genera l point of <t>Duplicated information should be avoided when possible, as a genera l point of
efficiency. This might include repeated information in hybrid certificates or efficiency. This might include repeated information in hybrid certificates or
in the communication of component certificates in additional to hybrid in the communication of component certificates in addition to hybrid
certificates (for example, to achieve backwards/forwards-compatibility) or certificates (for example, to achieve backwards and forwards compatibility) or
sending multiple public keys or signatures of the same component algorithm.</t> sending multiple public keys or signatures of the same component algorithm.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="non-separability-spectrum"> <section anchor="non-separability-spectrum">
<name>Non-Separability Spectrum</name> <name>Non-Separability Spectrum</name>
<t>Non-separability is not a singular definition but rather is a scale, <t>Non-separability is not a singular definition but rather is a scale
representing <tt>degrees</tt> of separability hardness, visualized in representing <tt>degrees</tt> of separability hardness, visualized in
<xref target="fig-spectrum-non-separability"/>.</t> <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"> <figure anchor="fig-spectrum-non-separability">
<name>Spectrum of non-separability from weakest to strongest.</name> <name>Spectrum of Non-Separability from Weakest to Strongest</name>
<artwork><![CDATA[ <artwork><![CDATA[
|-----------------------------------------------------------------------------| | ----------------------------------------------------------|
|**No Non-Separability** | *No Non-Separability*
| no artifacts exist |
|-----------------------------------------------------------------------------| | No artifacts exist.
|**Weak Non-Separability** | ----------------------------------------------------------|
| artifacts exist in the message, signature, system, application, or protocol | *Weak Non-Separability*
| ----------------------------------------------------------------------------| |
|**Strong Non-Separability** | Artifacts exist in the message, signature, system,
| artifacts exist in hybrid signature | application, or protocol.
| ----------------------------------------------------------------------------| | ----------------------------------------------------------|
|**Strong Non-Separability w/ Simultaneous Verification** | *Strong Non-Separability*
| artifacts exist in hybrid signature and verification or failure of both |
| components occurs simultaneously | Artifacts exist in the hybrid signature.
| ----------------------------------------------------------------------------| | ----------------------------------------------------------|
â–¼ | *Strong Non-Separability with Simultaneous Verification*
]]></artwork> |
| Artifacts exist in the hybrid signature, and verification
| or failure of both components occurs simultaneously.
| ----------------------------------------------------------|
â–¼]]></artwork>
</figure> </figure>
<t>At one end of the spectrum are schemes in which one of the component <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 signatures can be stripped away with the verifier not being able to detect
the change during verification. An example of this includes simple the change during verification. An example of this includes simple
concatenation of signatures without any artifacts used. Nested signatures concatenation of signatures without any artifacts used. Nested signatures
(where a message is signed by one component algorithm and then the (where a message is signed by one component algorithm and then the
message-signature combination is signed by the second component algorithm) message-signature combination is signed by the second component algorithm)
may also fall into this category, dependent on whether the inner or outer may also fall into this category, dependent on whether the inner or outer
signature is stripped off without any artifacts remaining.</t> 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 <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 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 artifacts of the hybrid will remain (in the message, in the signature, at the
protocol level, etc.). This may enable the verifier to detect if a component protocol level, etc.). This may enable the verifier to detect if a component
signature is stripped away from a hybrid signature, but that detectability signature is stripped away from a hybrid signature, but that detectability
depends highly on the type of artifact and permissions. For instance, if a 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 message contains a label artifact "This message must be signed with a hybrid
signature" then the system must be allowed to analyze the message contents signature", then the system must be allowed to analyze the message contents
for possible artifacts. Whether a hybrid signature offers (Weak/Strong) for possible artifacts. Whether a hybrid signature offers (Weak/Strong)
Non-Separability might also depend on the implementation and policy of the Non-Separability might also depend on the implementation and policy of the
protocol or application the hybrid signature is used in on the verifier 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 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, type of authenticity offered to the receiver is unclear. In another example,
under nested signatures the verifier could be tricked into interpreting a new under nested signatures, the verifier could be tricked into interpreting a new
message as the message/inner signature combination and verify only the outer message as the message/inner signature combination and verify only the outer
signature. In this case, the inner signature is an artifact.</t> signature. In this case, the inner signature is an artifact.</t>
<t>Third on the scale is the Strong Non-Separability notion, in which <t>Third on the scale is the Strong Non-Separability notion, in which
separability detection is dependent on artifacts in the signature separability detection is dependent on artifacts in the signature
itself. Unlike in Weak Non-Separability, where artifacts may be in the actual itself. Unlike in Weak Non-Separability, where artifacts may be in the actual
message, the certificate, or in other non-signature components, this notion message, the certificate, or other non-signature components, this notion
more closely ties to traditional algorithm security notions (such as EUF-CMA) more closely ties to traditional algorithm security notions (such as EUF-CMA)
where security is dependent on the internal construct of the signature where security is dependent on the internal construct of the signature
algorithm and its verification. In this type, the verifier can detect algorithm and its verification. In this type, the verifier can detect
artifacts on an algorithmic level during verification. For example, the artifacts on an algorithmic level during verification. For example, the
signature itself may encode the information that a hybrid signature scheme is 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 > used. Examples of this type may be found in <xref target="HYBRIDSIGDESIGN"/>.</t >
<t>For schemes achieving the most demanding security notion, Strong <t>For schemes achieving the most demanding security notion, Strong
Non-Separability with Simultaneous Verification, verification succeeds Non-Separability with Simultaneous Verification, verification succeeds
only when both of the component signatures are present and the only when both of the component signatures are present and the
verifier has verified both signatures. Moreover, no information is leaked to verifier has verified both signatures. Moreover, no information is leaked to
the receiver during the verification process on the possible validity of the the receiver during the verification process on the possible validity of the
component signatures until both verify (or verification failure may or may component signatures until both verify (or verification failure may or may
not be attributable to a specific component algorithm). This construct most not be attributable to a specific component algorithm). This construct most
closely mirrors traditional digital signatures where, assuming that the closely mirrors traditional digital signatures where, assuming that the
verifier does verify a signature at all, the result is either a positive 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 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 valid. For fused hybrid signatures, a <tt>full signature</tt> implies the fusion of
both component algorithms, and therefore this type of construction has the both component algorithms; therefore, this type of construction has the
potential to achieve the strongest non-separability notion which ensures an potential to achieve the strongest non-separability notion, which ensures an
all-or-nothing approach to verification, regardless of adversarial all-or-nothing approach to verification, regardless of adversarial
action. Examples of algorithms providing this type of security can be found action. Examples of algorithms providing this type of security can be found
in <xref target="HYBRIDSIGDESIGN"/>.</t> in <xref target="HYBRIDSIGDESIGN"/>.</t>
</section> </section>
<section anchor="art-spectrum"> <section anchor="art-spectrum">
<name>Artifacts</name> <name>Artifacts</name>
<t>Hybridization benefits from the presence of artifacts as evidence of th e <t>Hybridization benefits from the presence of artifacts as evidence of th e
sender's intent to decrease the risk of successful stripping attacks. This, sender's intent to decrease the risk of successful stripping attacks. This,
however, depends strongly on where such evidence resides (e.g., in the however, depends strongly on where such evidence resides (e.g., in the
message, the signature, or somewhere on the protocol level instead of at the message, in the signature, or somewhere on the protocol level instead of at the
algorithmic level). Even commonly discussed hybrid approaches, such as algorithmic level). Even commonly discussed hybrid approaches, such as
concatenation, are not inherently tied to one type of security (e.g., WNS or 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 SNS). This can lead to ambiguities when comparing different approaches and
assumptions about security or lack thereof. Thus, in this section we cover assumptions about security or lack thereof. Thus, in this section, we cover
artifact locations and also walk through a high-level comparison of a few 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 hybrid categories to show how artifact location can differ within a given
approach. Artifact location is tied to non-separability notions above; thus approach. Artifact location is tied to non-separability notions as described abo ve; thus,
the selection of a given security guarantee and general hybrid approach must the selection of a given security guarantee and general hybrid approach must
also include finer grained selection of artifact placement.</t> also include a finer-grained selection of artifact placement.</t>
<section anchor="art-sep"> <section anchor="art-sep">
<name>Artifacts vs. Separability</name> <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 sche me and <t>Note that non-separability is a security notion of the signature sche me and
not directly related to artifacts – artifacts may be used for detection of not directly related to artifacts -- however, artifacts may be used for detectio
separation, however. For instance, under strong non-separability, the scheme n of
would fail verification if separation occurs, while for weak non-separability separation. For instance, under strong non-separability, the scheme
would fail verification if separation occurs, while for weak non-separability,
some artifacts exist if separation occurs but verification would not some artifacts exist if separation occurs but verification would not
necessarily fail. The verifier could indeed ignore the artifact, hence the necessarily fail. The verifier could indeed ignore the artifact, resulting in th e
scheme achieving only weak non-separability and not strong scheme achieving only weak non-separability and not strong
non-separability. It is rather that an artifact exists that could be non-separability. It is rather that an artifact exists that could be
identified if an investigation occurred, etc. Under weak non-separability, identified if an investigation occurred, etc. Under weak non-separability,
detection of separation may depend on non-cryptographic configurations or detection of separation may depend on non-cryptographic configurations or
other dependencies. Also, strong non-separability and weak non-separability other dependencies. Also, strong non-separability and weak non-separability
are properties of the signature scheme – artifacts are not necessarily in the are properties of the signature scheme -- artifacts are not necessarily in the
signature and may appear in the signed message, the certificate, the signature and may appear in the signed message, certificate,
protocol, or policy (hence them not necessarily being related to the strong protocol, or policy (hence them not necessarily being related to the strong
non-separability and weak non-separablity security notions). Artifacts may non-separability and weak non-separability security notions). Artifacts may
still be useful (albeit dependent on system configurations) even if separable still be useful (albeit dependent on system configurations) even if separable
signatures are used.</t> signatures are used.</t>
</section> </section>
<section anchor="art-locations"> <section anchor="art-locations">
<name>Artifact Locations</name> <name>Artifact Locations</name>
<t>There are a variety of artifact locations possible, ranging from with in the <t>There are a variety of artifact locations possible, ranging from with in the
message to the signature algorithm to the protocol level and even into message to the signature algorithm to the protocol level and even into
policy, as shown in <xref target="tab-artifact-location"/>. For example, one ar tifact policy, as shown in <xref target="tab-artifact-location"/>. For example, one ar tifact
location could be in the message to be signed, e.g., containing a label 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 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 away. For example, a quantum attacker could strip away the post-quantum
signature of a concatenated dual signature, and, being able to forge the signature of a concatenated dual signature, and, being able to forge the
traditional signature, remove the label artifact from the message as 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 well. So, for many applications and threat models, adding an artifact in the
message might be insufficient under stripping attacks. Another artifact message might be insufficient under stripping attacks. Another artifact
location could be in the public key certificates as described in 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 <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 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 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 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 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 component of the hybrid to create a forgery for a component algorithm. Such
signatures provide SNS. This consequently also implies that the artifacts of signatures provide SNS. Consequently, this also implies that the artifacts of
hybridization are absolute in that verification failure would occur if an hybridization are absolute in that verification failure would occur if an
adversary tries to remove them.</t> adversary tries to remove them.</t>
<t>Eventual security analysis may be a consideration in choosing between <t>Eventual security analysis may be a consideration in choosing between
levels. For example, if the security of the hybrid scheme is dependent on levels. For example, if the security of the hybrid scheme is dependent on
system policy, then cryptographic analysis must necessarily be reliant 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 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 in a standalone sense. In this case, it is necessary to consider the
configuration of a particular implementation or use to assess security, which configuration of a particular implementation or use to assess security, which
could increase the risk of unknown and unanticipated vulnerabilities, could increase the risk of unknown and unanticipated vulnerabilities,
regardless of the algorithms in use.</t> regardless of the algorithms in use.</t>
<table anchor="tab-artifact-location"> <table anchor="tab-artifact-location">
<name>Artifact placement levels</name> <name>Artifact Placement Levels</name>
<thead> <thead>
<tr> <tr>
<th align="left">Location of Artifacts of Hybrid Intent</th> <th align="left">Location of Artifacts of Hybrid Intent</th>
<th align="left">Level</th> <th align="left">Level</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Signature                                 </td> <td align="left">Signature</td>
<td align="left">Algorithm</td> <td align="left">Algorithm</td>
</tr> </tr>
<tr> <tr>
<td align="left">Certificate</td> <td align="left">Certificate</td>
<td align="left">Protocol</td> <td align="left">Protocol</td>
</tr> </tr>
<tr> <tr>
<td align="left">Algorithm agreement / negotiation</td> <td align="left">Algorithm agreement / negotiation</td>
<td align="left">Protocol</td> <td align="left">Protocol</td>
</tr> </tr>
<tr> <tr>
<td align="left">Message                                    </td> <td align="left">Message</td>
<td align="left">Policy</td> <td align="left">Policy</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="art-spectrum-example"> <section anchor="art-spectrum-example">
<name>Artifact Location Comparison Example</name> <name>Artifact Location Comparison Example</name>
<t>Here we provide a high-level example of how artifacts can appear in d ifferent <t>Here we provide a high-level example of how artifacts can appear in d ifferent
locations even within a single, common approach. We look at the following locations even within a single, common approach. We look at the following
categories of approaches: concatenation, nesting, and fusion. This is to categories of approaches: concatenation, nesting, and fusion. This is to
illustrate that a given approach does not inherently imply a specific illustrate that a given approach does not inherently imply a specific
non-separability notion and that there are subtleties to the selection non-separability notion and that there are subtleties to the selection
decision, since hybrid artifacts are related to non-separability guarantees. decision, since hybrid artifacts are related to non-separability guarantees.
Additionally, this comparison highlights how artifacts placement can be Additionally, this comparison highlights how artifact placement can be
identical in two different hybrid approaches.</t> identical in two different hybrid approaches.</t>
<t>We briefly summarize the hybrid approach categories (concatenation, n esting, <t>We briefly summarize the hybrid approach categories (concatenation, n esting,
and fusion) for clarity in description, before showing how each one may have and fusion) for clarity in description before showing how each one may have
artifacts in different locations in <xref target="tab-hybrid-approach-categories "/>.</t> artifacts in different locations in <xref target="tab-hybrid-approach-categories "/>.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Concatenation: variants of hybridization where, for component alg orithms <t>Concatenation: Variants of hybridization where, for component alg orithms
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted as a <tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted as a
concatenation <tt>(sig_1, sig_2)</tt> such that <tt>sig_1 = Sigma_1.Sign(hybridA lgID || concatenation <tt>(sig_1, sig_2)</tt> such that <tt>sig_1 = Sigma_1.Sign(hybridA lgID ||
m)</tt> and <tt>sig_2 = Sigma_2.Sign(hybridAlgID || m)</tt>.</t> m)</tt> and <tt>sig_2 = Sigma_2.Sign(hybridAlgID || m)</tt>.</t>
</li> </li>
<li> <li>
<t>Nesting: variants of hybridization where for component algorithms <t>Nesting: Variants of hybridization where, for component algorithm s
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted in a <tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted in a
layered approach as <tt>(sig_1, sig_2)</tt> such that, e.g., <tt>sig_1 = 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 || Sigma_1.Sign(hybridAlgID || m)</tt> and <tt>sig_2 = Sigma_2.Sign(hybridAlgID || (m ||
sig_1))</tt>.</t> sig_1))</tt>.</t>
</li> </li>
<li> <li>
<t>Fused hybrid: variants of hybridization where for component algor ithms <t>Fused hybrid: Variants of hybridization, where for component algo rithms
<tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted to <tt>Sigma_1.Sign</tt> and <tt>Sigma_2.Sign</tt>, the hybrid signature is calcula ted to
generate a single hybrid signature <tt>sig_h</tt> that cannot be cleanly separat ed generate a single hybrid signature <tt>sig_h</tt> that cannot be cleanly separat ed
to form one or more valid component constructs. For example, if both to form one or more valid component constructs. For example, if both
signature schemes are signatures schemes constructed through the Fiat-Shamir signature schemes are constructed through the Fiat-Shamir
transform, the component signatures would include responses r_1 and r_2 and 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 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 respective commitments comm_1 and comm_2 (and the message). A fused hybrid
signature could consist of the component responses, r_1 and r_2 and a signature could consist of the component responses r_1 and r_2 and a
challenge c that is computed as a hash over both commitments, i.e., c = 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 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 either of the component signatures but rather both, meaning that the
signatures are 'entangled'.</t> signatures are 'entangled'.</t>
</li> </li>
</ul> </ul>
<table anchor="tab-hybrid-approach-categories"> <table anchor="tab-hybrid-approach-categories">
<name>Artifact locations depending on the hybrid signature type</name> <name>Artifact Locations Depending on the Hybrid Signature Type</name>
<thead> <thead>
<tr> <tr>
<th align="left">#</th> <th align="left">#</th>
<th align="left">Location of artifacts of hybrid intent</th> <th align="left">Location of Artifacts of Hybrid Intent</th>
<th align="left">Category</th> <th align="left">Category</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
<td align="left"> <th align="left">
<strong>Concatenated</strong></td> <strong>Concatenated</strong></th>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">None</td> <td align="left">None</td>
<td align="left">No label in message, public keys are in separate certs</td> <td align="left">No label in message, public keys are in separate certs</td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">In message</td> <td align="left">In message</td>
<td align="left">Label in message, public keys are in separate cer ts</td> <td align="left">Label in message, public keys are in separate cer ts</td>
skipping to change at line 769 skipping to change at line 1048
<td align="left">3</td> <td align="left">3</td>
<td align="left">In cert</td> <td align="left">In cert</td>
<td align="left">No label in message, public keys are in combined cert</td> <td align="left">No label in message, public keys are in combined cert</td>
</tr> </tr>
<tr> <tr>
<td align="left">4</td> <td align="left">4</td>
<td align="left">In message and cert</td> <td align="left">In message and cert</td>
<td align="left">Label in message, public keys are in combined cer t</td> <td align="left">Label in message, public keys are in combined cer t</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
<td align="left"> <th align="left">
<strong>Nested</strong></td> <strong>Nested</strong></th>
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">In message</td> <td align="left">In message</td>
<td align="left">Label in message, public keys are in separate cer ts</td> <td align="left">Label in message, public keys are in separate cer ts</td>
</tr> </tr>
<tr> <tr>
<td align="left">6</td> <td align="left">6</td>
<td align="left">In cert</td> <td align="left">In cert</td>
<td align="left">No label in message, public keys are in combined cert</td> <td align="left">No label in message, public keys are in combined cert</td>
</tr> </tr>
<tr> <tr>
<td align="left">7</td> <td align="left">7</td>
<td align="left">In message and cert</td> <td align="left">In message and cert</td>
<td align="left">Label in message, public keys are in combined cer t</td> <td align="left">Label in message, public keys are in combined cer t</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
<td align="left"> <th align="left">
<strong>Fused</strong></td> <strong>Fused</strong></th>
</tr> </tr>
<tr> <tr>
<td align="left">8</td> <td align="left">8</td>
<td align="left">In signature</td> <td align="left">In signature</td>
<td align="left">Public keys are in separate certs</td> <td align="left">Public keys are in separate certs</td>
</tr> </tr>
<tr> <tr>
<td align="left">9</td> <td align="left">9</td>
<td align="left">In signature and message</td> <td align="left">In signature and message</td>
<td align="left">Label in message, public keys are in separate cer ts</td> <td align="left">Label in message, public keys are in separate cer ts</td>
skipping to change at line 817 skipping to change at line 1096
<td align="left">In signature and cert</td> <td align="left">In signature and cert</td>
<td align="left">Public keys are in combined cert</td> <td align="left">Public keys are in combined cert</td>
</tr> </tr>
<tr> <tr>
<td align="left">11</td> <td align="left">11</td>
<td align="left">In signature and message and cert</td> <td align="left">In signature and message and cert</td>
<td align="left">Label in message, public keys are in combined cer t</td> <td align="left">Label in message, public keys are in combined cer t</td>
</tr> </tr>
</tbody> </tbody>
</table> </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 t ype of <t>As can be seen, while concatenation may appear to refer to a single t ype of
combiner, there are in fact several possible artifact locations depending on combiner, there are in fact several possible artifact locations depending on
implementation choices. Artifacts help to support detection in the case of implementation choices. Artifacts help to support detection in the case of
stripping attacks, which means that different artifact locations imply stripping attacks, which means that different artifact locations imply
different overall system implementation considerations to be able to achieve different overall system implementation considerations to be able to achieve
such detection.</t> such detection.</t>
<t>Case 1 provides the weakest guarantees of hybrid identification, as t here are <t>Case 1 provides the weakest guarantees of hybrid identification, as t here are
no prescribed artifacts and therefore non-separability is not achieved. no prescribed artifacts and therefore non-separability is not achieved.
However, as can be seen, this does not imply that every implementation using However, as can be seen, this does not imply that every implementation using
concatenation fails to achieve non-separability. Thus, it is advisable for concatenation fails to achieve non-separability. Thus, it is advisable for
implementors to be transparent about artifact locations.</t> implementers to be transparent about artifact locations.</t>
<t>In cases 2 and 5 the artifacts lie within the message. This is notabl <t>In cases 2 and 5, the artifacts lie within the message. This is notab
e as the le as the
authenticity of the message relies on the validity of the signature, and 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 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 content of the message (the artifact label). This creates a risk of circular
dependency. Alternative approaches such as cases 3, 4, 6 and 7 solve this dependency. Alternative approaches, such as cases 3, 4, 6, and 7, solve this
circular dependency by provisioning keys in a combined certificate.</t> circular dependency by provisioning keys in a combined certificate.</t>
<t>Another observation from this comparison is that artifact locations m ay be <t>Another observation from this comparison is that artifact locations m ay be
similar among some approaches. For instance, case 3 and case 6 both contain similar among some approaches. For instance, cases 3 and 6 both contain
artifacts in the certificate. Naturally these examples are high-level and artifacts in the certificate. Naturally, these are high-level examples and
further specification on concrete schemes in the categories are needed before further specification on concrete schemes in the categories are needed before
prescribing non-separability guarantees to each, but this does indicate how prescribing non-separability guarantees to each, but this does indicate how
there could be a strong similarity between such guarantees. Such comparisons there could be a strong similarity between such guarantees. Such comparisons
allow for a systematic decision process, where security is compared and allow for a systematic decision process, where security is compared and
identified and, if schemes are similar in the desired security goal, then identified, and if schemes are similar in the desired security goal, then
decisions between schemes can be based on performance and implementation decisions between schemes can be based on performance and implementation
ease.</t> ease.</t>
<t>A final observation that this type of comparison provides is how vari ous <t>A final observation that this type of comparison provides is how vari ous
combiners may change the security analysis assumptions in a system. For combiners may change the security analysis assumptions in a system. For
instance, cases 3, 4, 6, and 7 all push artifacts - and therefore the instance, cases 3, 4, 6, and 7 all push artifacts -- and therefore the
signature validity - into the certificate chain. Naturally the entire chain signature validity -- into the certificate chain. Naturally, the entire chain
must then also use a similar combiner if a straightforward security argument 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 put artifacts within the is to be made. Other cases, such as 8, 9, 10, and 11, put artifacts within the
signature itself, meaning that these bear the closest resemblance to signature itself, meaning that these bear the closest resemblance to
traditional schemes where message authenticity is dependent on signature traditional schemes where message authenticity is dependent on signature
validity.</t> validity.</t>
</section> </section>
</section> </section>
<section anchor="need-for-approval-spectrum"> <section anchor="need-for-approval-spectrum">
<name>Need For Approval Spectrum</name> <name>Need for Approval Spectrum</name>
<t>In practice, use of hybrid digital signatures relies on standards where <t>In practice, use of hybrid digital signatures relies on standards where
applicable. This is particularly relevant in the cases where use of FIPS applicable. This is particularly relevant in the cases where use of FIPS-a
(Federal Information Processing Standard) approved software modules is pproved software modules
required, but applies equally to any guidance or policy direction that is
required but applies equally to any guidance or policy direction that
specifies that at least one component algorithm of the hybrid has passed some specifies that at least one component algorithm of the hybrid has passed some
certification type while not specifying requirements on the other component. certification type while not specifying requirements on the other component.
NIST provides the following guidance (emphasis added),</t> NIST provides the following guidance in <xref target="NIST_PQC_FAQ"/> (emphasis
<ul empty="true"> added):</t>
<li>
<t>Assume that in a [hybrid] signature, <em>one signature is generated <!-- [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 with a NIST-approved signature scheme as specified in FIPS 186, while
another signature(s) can be generated using different schemes</em>, e.g., another signature(s) can be generated using different schemes</em>, e.g.,
ones that are not currently specified in NIST standards...<em><tt>hybrid ones that are not currently specified in NIST standards ... <em><tt>[hybrid] sig
signatures</tt> can be accommodated by current standards in <tt>FIPS mode,</tt> natures</tt> can be accommodated by current standards in <tt>"FIPS mode"</tt>,
as defined in FIPS 140, provided at least one of the component methods as defined in FIPS 140, provided at least one of the component methods
is a properly implemented, NIST-approved signature algorithm</em>. For the is a properly implemented, NIST-approved signature algorithm</em>. For the
purposes of FIPS 140 validation, any signature that is generated by a purposes of FIPS 140 validation, any signature that is generated by a
non-approved component scheme would not be considered a security non-approved component scheme would not be considered a security
function, since the NIST-approved component is regarded as assuring function, since the NIST-approved component is regarded as assuring
the validity of the <tt>hybrid</tt> signature. <xref target="NIST_PQC_FAQ"/></t> the validity of the <tt>[hybrid]</tt> signature.
</li> </blockquote>
</ul> <t>This document does not define a formal interpretation of the NIST state
<t>This draft does not define a formal interpretation of the NIST statemen ment;
t; however, we use it as motivation to highlight some points that implementers
however, we use it as motivation to highlight some points that implementors
of hybrids may wish to consider when following any guidance documents that of hybrids may wish to consider when following any guidance documents that
specify that 1) the signature scheme for one of the component algorithms 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 or a must be approved and 2) the said algorithm must be a well-implemented or
certified implementation. This type of <tt>need for approval</tt> (i.e., a certified implementation. This type of <tt>need for approval</tt> (i.e., a
requirement that an implementor is looking to follow regarding approval or requirement that an implementer is looking to follow regarding approval or
certification of the software module implementation of hybrid or its certification of the software module implementation of a hybrid or its
component algorithms) can drive some logistical decisios on what types of component algorithms) can drive some logistical decisions on what types of
hybrids an implementor should consider.</t> hybrids an implementer should consider.</t>
<t>In this respect, there is a <tt>scale of approval</tt> that developers may <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 consider as to whether they are using at least one approved component
algorithm implementation (<tt>1-out-of-n approved software module</tt>), or algorithm implementation (<tt>1-out-of-n approved software module</tt>) or
whether every component algorithm implementation is individually approved whether every component algorithm implementation is individually approved
(<tt>all approved software module</tt>).</t> (<tt>all approved software module</tt>).</t>
<t>We provide a scale for the different nuances of <tt>approval</tt> of th e hybrid <t>We provide a scale for the different nuances of <tt>approval</tt> of th e hybrid
combiners, where "approval" means that a software implementation of a combiners, where "approval" means that a software implementation of a
component algorithm can be used unmodified for creation of the hybrid 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 signature. This may be related to whether a hybrid combiner is likely to need
dedicated certification.</t> 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"> <figure anchor="fig-generality-spectrum">
<name>Generality / Need for Approval spectrum</name> <name>Generality / Need for Approval Spectrum</name>
<artwork><![CDATA[ <artwork><![CDATA[
| ------------------------------------------------------------------------------ | ---------------------------------------------------------|
---| | *New Algorithm*
| **New Algorithm** |
| New signature scheme based on a selection of hardness assumptions | New signature scheme based on a selection of hardness
| Separate approval needed | assumptions.
| ------------------------------------------------------------------------------ |
---| | Separate approval needed.
| **No Approved Software Module** | ---------------------------------------------------------|
| Hybrid combiner supports security analysis that can be reduced to | *No Approved Software Module*
| approved component algorithms, potentially changing the component implementati |
ons | Hybrid combiner supports security analysis that can be
| Uncertainty about whether separate approval is needed | reduced to approved component algorithms, potentially
| ------------------------------------------------------------------------------ | changing the component implementations.
---| |
| **1-out-of-n Approved Software Module** | Uncertainty about whether separate approval is needed.
| Combiner supports one component algorithm and implementation in a black-box wa | ---------------------------------------------------------|
y | *1-out-of-n Approved Software Module*
| but potentially changes the other component algorithm implementation(s) |
| No new approval needed if the black-box component (implementation) is approved | Combiner supports one component algorithm and
| ------------------------------------------------------------------------------ | implementation in a black-box way but potentially
---| | changes the other component algorithm implementation(s).
| **All Approved Software Modules** |
| Hybrid combiner acts as a wrapper, fully independent of the component | No new approval needed if the black-box component
| signature scheme implementations | (implementation) is approved.
| No new approval needed if at least one component implementation is approved | ---------------------------------------------------------|
| ------------------------------------------------------------------------------ | *All Approved Software Modules*
---| |
â–¼ | Hybrid combiner acts as a wrapper, fully independent of
]]></artwork> | the component signature scheme implementations.
|
| No new approval needed if at least one component
| implementation is approved.
| ---------------------------------------------------------|
â–¼]]></artwork>
</figure> </figure>
<t>The first listed "combiner" would be a new construction with a security <t>The first listed "combiner" would be a new construction with a security
reduction to different hardness assumptions but not necessarily to approved reduction to different hardness assumptions but not necessarily to approved
(or even existing) signature schemes. Such a new, singular algorithm relies (or even existing) signature schemes. Such a new, singular algorithm relies
on both traditional and next-gen principles.</t> on both traditional and next-generation principles.</t>
<t>Next, is a combiner that might take inspiration from existing/approved <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 signature schemes such that its security can be reduced to the security of
the approved algorithms. The combiner may, however, alter the the approved algorithms. The combiner may, however, alter the
implementations. As such it is uncertain whether new approval would be implementations. As such, it is uncertain whether new approval would be
needed as it might depend on the combiner and changes. Such a case may 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 potentially imply a distinction between a need for fresh approval of the
algorithm(s) and approval of the implementation(s).</t> algorithm(s) and approval of the implementation(s).</t>
<t>The 1-out-of-n combiner uses at least one approved algorithm implementa tion <t>The 1-out-of-n combiner uses at least one approved algorithm implementa tion
in a black-box way (i.e., without modification to the software module in a black-box way (i.e., without modification to the software module
implementaton for that algorithm). It may potentially change the specifics implementation for that algorithm). It may potentially change the specifics
of the other component algorithm implementations. If the premise is that no 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 new approval is needed so long as at least one component is approved, then
this is likely considered sufficient.</t> this is likely considered sufficient.</t>
<t>In an all-approved combiner, every algorithm implementation is used in a <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 black-box way. A concatenation combiner is a simple example (where a
signature is valid if all component signatures are valid). Thus, as all signature is valid if all component signatures are valid). Thus, as all
algorithm implementations are approved, a requirement that at least one of algorithm implementations are approved, a requirement that at least one of
hybrid component algorithms is approved would be satisfied.</t> hybrid component algorithms is approved would be satisfied.</t>
</section> </section>
<section anchor="euf-cma-challenges"> <section anchor="euf-cma-challenges">
<name>EUF-CMA Challenges</name> <name>EUF-CMA Challenges</name>
<t>Unforgeability properties for hybrid signature schemes are more nuanced than <t>Unforgeability properties for hybrid signature schemes are more nuanced than
for single-algorithm schemes.</t> for single-algorithm schemes.</t>
<t>Under the traditional EUF-CMA security assumption, an adversary can req
uest <!-- [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 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 request
s
signatures for messages of their choosing and succeeds if they are able to 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 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 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 the same way as single-algorithm schemes. Namely, the most straightforward
extension of the traditional EUF-CMA security game would be that an adversary extension of the traditional EUF-CMA security game would be that an adversary
can request hybrid signatures for messages of their choosing and succeeds if 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 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 part of an earlier request. However, this has several layers of nuance under
a hybrid construct.</t> a hybrid construct.</t>
<t>Consider, for example, a simplistic hybrid approach using concatenated <t>Consider, for example, a simplistic hybrid approach using concatenated
component algorithms. If the hybrid signature is stripped, such that a single component algorithms. If the hybrid signature is stripped, such that a single
component signature is submitted to a verification algorithm for that component signature is submitted to a verification algorithm for that
component along with the message that was signed by the hybrid, the result 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 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 - the component signing algorithm was not previously called for the message,
the hybrid signing algorithm was used to generate the signature. This is an 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 example of a component algorithm forgery, a.k.a. a case of cross-algorithm
attack or cross-protocol attack.</t> attack or cross-protocol attack.</t>
<t>The component algorithm forgery verifier target does not need to be the <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 intended recipient of the hybrid-signed message and may even be in an
entirely different system. This vulnerability is particularly an issue among entirely different system. This vulnerability is particularly an issue among
concatenated or nested hybrid signature schemes where individual component concatenated or nested hybrid signature schemes where individual component
verification could be possible. It should be noted that policy enforcement of verification could be possible. It should be noted that policy enforcement of
a hybrid verification does not mitigate the issue on the intended message a hybrid verification does not mitigate the issue on the intended message
recipient: the component forgery could occur on any system that accepts the recipient: The component forgery could occur on any system that accepts the
component keys.</t> component keys.</t>
<t>Thus, if EUF-CMA security for hybrids is considered to be informally de
fined <!--[rfced] We are having difficulty parsing this sentence, particularly "is
in the straightfoward way as that an adversary can request hybrid signatures 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 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, 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. implicit requirements must hold in order to avoid real-world implications.
Namely, either component algorithm forgeries, a.k.a. cross-protocol attacks, 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 must be out of scope for the use case or the hybrid signature choice must
be strongly non-separable. Otherwise, component algorithm forgeries, which 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 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 properties offered and are a practical consideration that system designers
and managers should be aware of when selecting among hybrid approaches for and managers should be aware of when selecting among hybrid approaches for
their use case.</t> their use case.</t>
skipping to change at line 1014 skipping to change at line 1441
any security analysis. Since cryptographic provable security modeling has not any security analysis. Since cryptographic provable security modeling has not
historically accounted for key reuse in this way, it should not be assumed historically accounted for key reuse in this way, it should not be assumed
that systems with existing analyses are robust to this issue.</t> that systems with existing analyses are robust to this issue.</t>
<t>The other approach noted for alleviating the component forgery risk is <t>The other approach noted for alleviating the component forgery risk is
through hybrid signature selection of a scheme that provides strong through hybrid signature selection of a scheme that provides strong
non-separability. Under this approach, the hybrid signature cannot be non-separability. Under this approach, the hybrid signature cannot be
separated into component algorithm signatures that will verify correctly, separated into component algorithm signatures that will verify correctly,
thereby preventing the signature separation required for the component thereby preventing the signature separation required for the component
forgery attack to be successful.</t> forgery attack to be successful.</t>
<t>It should be noted that weak non-separability is insufficient for mitig ating <t>It should be noted that weak non-separability is insufficient for mitig ating
risks of component forgeries. As noted in <xref target="I-D.ietf-lamps-pq-compos risks of component forgeries. As noted in <xref section="9.3"
ite-sigs"/>, sectionFormat="of" target="I-D.ietf-lamps-pq-composite-sigs"/>, in cases of hybr
Sect. 11.3, in cases of hybrid algorithm selection that provide only weak id algorithm selection that provide only weak
non-separability, key reuse should be avoided, as mentioned above, to non-separability, key reuse should be avoided, as mentioned above, to
mitigate risks of introducing EUF-CMA vulnerabilities for component mitigate risks of introducing EUF-CMA vulnerabilities for component
algorithms.</t> algorithms.</t>
</section> </section>
<section anchor="advantages-disadvantages"> <section anchor="advantages-disadvantages">
<name>Discussion of Advantages/Disadvantages</name> <name>Discussion of Advantages and Disadvantages</name>
<t>The design (and hence, security guarantees) of hybrid signature schemes <t>The design (and hence security guarantees) of hybrid signature schemes
depend heavily on the properties needed for the application or protocol depend heavily on the properties needed for the application or protocol
using hybrid signatures. It seems that not all goals can be achieved using hybrid signatures. It seems that not all goals can be achieved
simultaneously as exemplified below.</t> simultaneously as exemplified below.</t>
<section anchor="backwards-compatibility-vs-sns"> <section anchor="backwards-compatibility-vs-sns">
<name>Backwards Compatibility vs. SNS</name> <name>Backwards Compatibility vs. SNS</name>
<t>There is an inherent mutual exclusion between backwards compatibility and <t>There is an inherent mutual exclusion between backwards compatibility and
SNS. While WNS allows for a valid separation under leftover artifacts, SNS SNS. While WNS allows for a valid separation under leftover artifacts, SNS
will ensure verification failure if a receiver attempts separation.</t> will ensure verification failure if a receiver attempts separation.</t>
</section> </section>
<section anchor="backwards-compatibility-vs-hybrid-unforgeability"> <section anchor="backwards-compatibility-vs-hybrid-unforgeability">
<name>Backwards Compatibility vs. Hybrid Unforgeability</name> <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 <t>Similarly, there is an inherent mutual exclusion between backwards
compatibility, when acted upon, and hybrid unforgeability as briefly compatibility, when acted upon, and hybrid unforgeability, as briefly
mentioned above. Since the goal of backwards compatibility is usually to mentioned above. Since the goal of backwards compatibility is usually to
allow legacy systems without any software change to be able to process hybrid allow legacy systems without any software change to be able to process hybrid
signatures, all differences between the legacy signature format and the signatures, all differences between the legacy signature format and the
hybrid signature format must be allowed to be ignored, including skipping hybrid signature format must be allowed to be ignored, including skipping
verification of signatures additional to the classical signature. As such, if verification of signatures additional to the classical signature. As such, if
a system does skip a component signature, security does not rely on the a system does skip a component signature, security does not rely on the
security of all component signatures. Note that this mutual exclusion occurs 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 at the verification stage, as a hybrid signature that is verified by a system
that can process both component schemes can provide hybrid unforgeability that can process both component schemes can provide hybrid unforgeability
even if another (legacy) system, processing the same hybrid signature, loses even if another (legacy) system, processing the same hybrid signature, loses
that property.</t> that property.</t>
</section> </section>
<section anchor="simultaneous-verification-vs-low-need-for-approval"> <section anchor="simultaneous-verification-vs-low-need-for-approval">
<name>Simultaneous Verification vs. Low Need for Approval</name> <name>Simultaneous Verification vs. Low Need for Approval</name>
<t>Hybrid algorithms that achieve simultaneous verification tend to fuse (or <t>Hybrid algorithms that achieve simultaneous verification tend to fuse (or
'entangle') the verification of component algorithms such that verification 'entangle') the verification of component algorithms such that verification
operations from the different component schemes depend on each other in some operations from the different component schemes depend on each other in some
way. Consequently, there may be a natural connection between achieving way. Consequently, there may be a natural connection between achieving
simultaneous verification and a higher need-for-approval. As a contrasting simultaneous verification and a higher need for approval. As a contrasting
example, NIST accommodate concatenation of a FIPS approved signature and example, NIST accommodates concatenation of a FIPS-approved signature and
another (potentially non-FIPS approved) signature without any artifacts in another (potentially non-FIPS approved) signature without any artifacts in
FIPS 140 validation <xref target="NIST_PQC_FAQ"/>, however as the component sign FIPS 140 validation <xref target="NIST_PQC_FAQ"/>; however, as the component sig
atures are natures are
verified separately it is not possible to enforce 'simultaneous verified separately, it is not possible to enforce 'simultaneous
verification'.</t> verification'.</t>
</section> </section>
</section> </section>
<section anchor="sec-considerations"> <section anchor="sec-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document discusses digital signature constructions that may be use d in <t>This document discusses digital signature constructions that may be use d in
security protocols. It is an informational document and does not directly security protocols. It is an Informational document and does not directly
affect any other Internet-Draft. The security considerations for any specific affect any other documents. The security considerations for any specific
implementation or incorporation of a hybrid scheme should be discussed in the implementation or incorporation of a hybrid scheme should be discussed in the
relevant specification documents.</t> relevant specification documents.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>This document is based on the template of <xref target="I-D.ietf-tls-hy
brid-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> </middle>
<back> <back>
<displayreference target="I-D.ietf-lamps-pq-composite-sigs" to="COMP-MLDSA"/
>
<displayreference target="I-D.becker-guthrie-noncomposite-hybrid-auth" to="N
C-HYBRID-AUTH"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="I-D.ietf-tls-hybrid-design">
<front>
<title>Hybrid key exchange in TLS 1.3</title>
<author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization>University of Waterloo</organization>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Shay Gueron" initials="S." surname="Gueron">
<organization>University of Haifa and Meta</organization>
</author>
<date day="17" month="June" year="2025"/>
<abstract>
<t> Hybrid key exchange refers to using multiple key exchange al
gorithms
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 draft-ietf-tls-hybrid-design-16
the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. companion doc RFC 9954
-->
<reference anchor="RFC9954" target="https://www.rfc-editor.org/info/rfc9954">
<front>
<title>Hybrid Key Exchange in TLS 1.3</title>
<author initials="D." surname="Stebila" fullname="Douglas Stebila">
<organization>University of Waterloo</organization>
</author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization>University of Haifa and Meta</organization>
</author>
<date month='April' year='2026'/>
</front>
<seriesInfo name="RFC" value="9954"/>
<seriesInfo name="DOI" value="10.17487/RFC9954"/>
</reference>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</abstract> 949.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design- 794.xml"/>
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 explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low 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, diction
ary 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</titl
e>
<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 cryp
tographic protocols is the development of hybrid schemes that incorporate both p
ost-quantum and traditional asymmetric algorithms. This document defines termino
logy for such schemes. It is intended to be used as a reference and, hopefully,
to ensure consistency and clarity across different protocols, standards, and org
anisations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9794"/>
<seriesInfo name="DOI" value="10.17487/RFC9794"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="EUFCMA" target="https://blog.cryptographyengineering. com/euf-cma-and-suf-cma/"> <reference anchor="EUFCMA" target="https://blog.cryptographyengineering. com/euf-cma-and-suf-cma/">
<front> <front>
<title>EUF-CMA and SUF-CMA</title> <title>EUF-CMA and SUF-CMA</title>
<author initials="M." surname="Green" fullname="Matthew Green"> <author initials="M." surname="Green" fullname="Matthew Green">
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="FALCON" target="https://falcon-sign.info/falcon.pdf"> <reference anchor="FALCON" target="https://falcon-sign.info/falcon.pdf">
<front> <front>
<title>FALCON: Fast-Fourier Lattice-based Compact Signatures over NT RU</title> <title>FALCON: Fast-Fourier Lattice-based Compact Signatures over NT RU</title>
<author> <author fullname="Pierre-Alain Fouque"/>
<organization/> <author fullname="Jeffrey Hoffstein"/>
</author> <author fullname="Paul Kirchner"/>
<date>n.d.</date> <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> </front>
<refcontent>Specification v1.2</refcontent>
</reference> </reference>
<reference anchor="FS" target="https://doi.org/10.1007%2F3-540-47721-7_1 2"> <reference anchor="FS" target="https://doi.org/10.1007%2F3-540-47721-7_1 2">
<front> <front>
<title>How To Prove Yourself: Practical Solutions to Identification and Signature Problems</title> <title>How To Prove Yourself: Practical Solutions to Identification and Signature Problems</title>
<author initials="A." surname="Fiat" fullname="Amos Fiat"> <author initials="A." surname="Fiat" fullname="Amos Fiat">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Shamir" fullname="Adi Shamir"> <author initials="A." surname="Shamir" fullname="Adi Shamir">
<organization/> <organization/>
</author> </author>
<date year="1986"/> <date year="1986"/>
</front> </front>
<refcontent>Advances in Cryptology -- CRYPTO' 86, Lecture Notes in Com
puter Science, vol. 263, pp. 186-194</refcontent>
<seriesInfo name="DOI" value="10.1007/3-540-47721-7_12"/>
</reference> </reference>
<reference anchor="GEMSS" target="https://www-polsys.lip6.fr/Links/NIST/ GeMSS_specification_round2_V2.pdf"> <reference anchor="GEMSS" target="https://www-polsys.lip6.fr/Links/NIST/ GeMSS_specification_round2_V2.pdf">
<front> <front>
<title>GeMSS: A Great Multivariate Short Signature</title> <title>GeMSS: A Great Multivariate Short Signature</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="April" day="15"/> <date year="2020" month="April" day="15"/>
</front> </front>
</reference> </reference>
skipping to change at line 1188 skipping to change at line 1605
</reference> </reference>
<reference anchor="GEMSS" target="https://www-polsys.lip6.fr/Links/NIST/ GeMSS_specification_round2_V2.pdf"> <reference anchor="GEMSS" target="https://www-polsys.lip6.fr/Links/NIST/ GeMSS_specification_round2_V2.pdf">
<front> <front>
<title>GeMSS: A Great Multivariate Short Signature</title> <title>GeMSS: A Great Multivariate Short Signature</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="April" day="15"/> <date year="2020" month="April" day="15"/>
</front> </front>
</reference> </reference>
<reference anchor="HQC_CVE" target="https://nvd.nist.gov/vuln/detail/CVE -2024-54137"> <reference anchor="HQC_CVE" target="https://nvd.nist.gov/vuln/detail/CVE -2024-54137">
<front> <front>
<title>Correctness error in HQC decapsulation</title> <title>CVE-2024-54137: liboqs has a correctness error in HQC decapsu lation</title>
<author> <author>
<organization/> <organization abbrev="NIST">National Institute of Standards and Te chnology</organization>
</author> </author>
<date year="2024" month="December" day="06"/> <date year="2024" month="December" day="06"/>
</front> </front>
</reference> </reference>
<reference anchor="HYBRIDSIG" target="https://eprint.iacr.org/2017/460"> <reference anchor="HYBRIDSIG" target="https://eprint.iacr.org/2017/460">
<front> <front>
<title>Transitioning to a Quantum-Resistant Public Key Infrastructur e</title> <title>Transitioning to a Quantum-Resistant Public Key Infrastructur e</title>
<author initials="N." surname="Bindel" fullname="Nina Bindel"> <author initials="N." surname="Bindel" fullname="Nina Bindel">
<organization/> <organization/>
</author> </author>
skipping to change at line 1214 skipping to change at line 1632
<organization/> <organization/>
</author> </author>
<author initials="M." surname="McKague" fullname="Matthew McKague"> <author initials="M." surname="McKague" fullname="Matthew McKague">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Stebila" fullname="Douglas Stebila"> <author initials="D." surname="Stebila" fullname="Douglas Stebila">
<organization/> <organization/>
</author> </author>
<date year="2017" month="May"/> <date year="2017" month="May"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2017/460</refcontent>
</reference> </reference>
<reference anchor="HYBRIDSIGDESIGN" target="https://eprint.iacr.org/2023 /423"> <reference anchor="HYBRIDSIGDESIGN" target="https://eprint.iacr.org/2023 /423">
<front> <front>
<title>A Note on Hybrid Signature Schemes</title> <title>A Note on Hybrid Signature Schemes</title>
<author initials="N." surname="Bindel" fullname="Nina Bindel"> <author initials="N." surname="Bindel" fullname="Nina Bindel">
<organization/> <organization/>
</author> </author>
<author initials="B." surname="Hale" fullname="Britta Hale"> <author initials="B." surname="Hale" fullname="Britta Hale">
<organization/> <organization/>
</author> </author>
<date year="2023" month="March"/> <date year="2023" month="March"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2023/423</refcontent>
</reference> </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 h
ybrid
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> <!-- [I-D.ietf-lamps-pq-composite-sigs]
</abstract> draft-ietf-lamps-pq-composite-sigs-13
</front> IESG State: IESG Eval as of 3/27/2026
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite -->
-sigs-06"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> ietf-lamps-pq-composite-sigs.xml"/>
<reference anchor="I-D.becker-guthrie-noncomposite-hybrid-auth">
<front> <!-- [I-D.becker-guthrie-noncomposite-hybrid-auth]
<title>Non-Composite Hybrid Authentication in PKIX and Applications draft-becker-guthrie-noncomposite-hybrid-auth-00
to Internet Protocols</title> IESG State: Expired as of 11/24/25
<author fullname="Alison Becker" initials="A." surname="Becker"> -->
<organization>National Security Agency</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</author> becker-guthrie-noncomposite-hybrid-auth.xml"/>
<author fullname="Rebecca Guthrie" initials="R." surname="Guthrie">
<organization>National Security Agency</organization>
</author>
<author fullname="Michael J. Jenkins" initials="M. J." surname="Jenk
ins">
<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 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 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-noncompo
site-hybrid-auth-00"/>
</reference>
<reference anchor="KYBERSLASH" target="https://eprint.iacr.org/2024/1049 "> <reference anchor="KYBERSLASH" target="https://eprint.iacr.org/2024/1049 ">
<front> <front>
<title>KyberSlash: Exploiting secret-dependent division timings in K yber implementations</title> <title>KyberSlash: Exploiting secret-dependent division timings in K yber implementations</title>
<author> <author fullname="Daniel J. Bernstein"/>
<organization/> <author fullname="Karthikeyan Bhargavan"/>
</author> <author fullname="Shivam Bhasin"/>
<date year="2024" month="June" day="30"/> <author fullname="Anupam Chattopadhyay"/>
</front> <author fullname="Tee Kiah Chia"/>
</reference> <author fullname="Matthias J. Kannwischer"/>
<reference anchor="MLDSA" target="https://doi.org/10.6028/NIST.FIPS.204" <author fullname="Franziskus Kiefer"/>
> <author fullname="Prasanna Ravi"/>
<front> <author fullname="Goutam Tamvada"/>
<title>Module-Lattice-Based Digital Signature Standard</title> <date year="2024" month="June"/>
<author>
<organization>National Institute of Standards and Technology (NIST
)</organization>
</author>
<date year="2024" month="August" day="13"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2024/1049</refcontent>
</reference> </reference>
<reference anchor="MLDSA" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FI
PS.204.pdf">
<front>
<title>Module-Lattice-Based Digital Signature Standard</title>
<author>
<organization abbrev="NIST">National Institute of Standards and Technology
</organization>
</author>
<date month="August" 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"> <reference anchor="NIST_PQC_FAQ" target="https://csrc.nist.gov/Projects/ post-quantum-cryptography/faqs">
<front> <front>
<title>Post-Quantum Cryptography FAQs</title> <title>Post-Quantum Cryptography FAQs</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization abbrev="NIST">National Institute of Standards and Te chnology</organization>
</author> </author>
<date year="2022" month="July" day="05"/> <date year="2022" month="July" day="05"/>
</front> </front>
</reference> </reference>
<reference anchor="QRCSP" target="https://cr.yp.to/papers/qrcsp-20231124 .pdf"> <reference anchor="QRCSP" target="https://cr.yp.to/papers/qrcsp-20231124 .pdf">
<front> <front>
<title>Quantifying risks in cryptographic selection processes</title > <title>Quantifying risks in cryptographic selection processes</title >
<author initials="D." surname="Bernstein" fullname="Daniel J. Bernst ein"> <author initials="D. J." surname="Bernstein" fullname="Daniel J. Ber nstein">
<organization/> <organization/>
</author> </author>
<date year="2023" month="November" day="24"/> <date year="2023" month="November" day="24"/>
</front> </front>
</reference> </reference>
<reference anchor="RAINBOW" target="https://www.pqcrainbow.org/"> <reference anchor="RAINBOW" target="https://www.pqcrainbow.org/">
<front> <front>
<title>PQC Rainbow</title> <title>PQC Rainbow</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </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/Rsap aper.pdf"> <reference anchor="RSA" target="https://people.csail.mit.edu/rivest/Rsap aper.pdf">
<front> <front>
<title>A Method for Obtaining Digital Signatures and Public-Key Cryp tosystems</title> <title>A Method for Obtaining Digital Signatures and Public-Key Cryp tosystems</title>
<author initials="R. L." surname="Rivest"> <author initials="R. L." surname="Rivest">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Shamir"> <author initials="A." surname="Shamir">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Adleman"> <author initials="L." surname="Adleman">
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<!-- Note to PE: Possible XML update for [RSA]
<reference anchor="RSA">
<front>
<title>A Method for Obtaining Digital Signatures and Public-Key Cryp
tosystems</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</re
fcontent>
<seriesInfo name="DOI" value="10.1145/359340.359342"/>
</reference>
-->
</references> </references>
</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ünt
her"/>,
<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> </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-li
brary/nist-technical-series-publications-author-instructions#table1
--> -->
</rfc> </rfc>
 End of changes. 165 change blocks. 
1016 lines changed or deleted 1092 lines changed or added

This html diff was produced by rfcdiff 1.48.