Document: draft-ietf-pquip-hybrid-signature-spectrums Title: Hybrid signature spectrums Reviewer: Ines Robles Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-pquip-hybrid-signature-spectrums-06 Reviewer: Ines Robles Review Date: 2025-04-07 IETF LC End Date: 2025-04-07 IESG Telechat date: Not scheduled for a telechat Summary: This Informational document describes classification of design goals and security considerations for hybrid digital signature schemes (e.g., combining post-quantum and non-post-quantum algorithms), including proof composability, non-separability of component signatures, backwards/forwards compatibility, hybrid generality, and simultaneous verification. The document is well written. I have the following comments and questions: 1- Related to "Hybrid Unforgeability": 1.1: What capabilities does the attacker have? Can the attacker ask for component signatures separately, or only the full hybrid signature? 1.2: What counts as a successful forgery? If the attacker takes a hybrid signature, strips one part (e.g., the post-quantum component), and reuses the other (e.g., the RSA part), is that considered a forgery? Or is a forgery only recognized if they produce a valid full hybrid signature? 1.3: What if the attacker forges just one component? Does that break the system? If the system accepts partial validation (e.g., verifying just the RSA part), is that considered a successful attack? 1.4: Does a successful stripping or key-reuse-based forgery count as a break? That is, under the intended definition of hybrid unforgeability, are these types of attacks considered in-scope and successful from the attacker point of view? 2- Related to role of artifacts and verifier behavior in non-separability: 2.1: The draft discusses how artifact placement affects whether a scheme achieves weak or strong non-separability. It appears to rely heavily on the presence of artifacts (e.g., in messages, certificates, or protocols) to ensure inseparability or prevent misuse. However, it is not clear to me whether the draft assumes that verifiers are always configured or implemented to correctly interpret and enforce those artifacts. For example: a certificate might indicate that a key is intended for hybrid use, but what if a verifier ignores that and accepts only the traditional component (e.g., the RSA part) of a hybrid signature? Similarly, a message may include protocol-level cues, but unless the verifier checks those cues, a stripping attack might still succeed. This raises the question: Is non-separability intended to be a cryptographic property of the signature structure itself, or is it assumed to rely on correct system configuration and verifier behavior? 3- Related to signature semantics: When a signer uses a hybrid signature, what exactly are they attesting to? Is the intent “I sign this message only if both components validate,” or “I sign this message as long as at least one component validates”? 4- I understand that the draft assumes a single signer controlling all signature components. What about the following cases: 4.1: Scenarios where different entities produce the two signature components (i.e., multi-signer hybrids). 4.2: Schemes where a hybrid signature is formed through cooperation among multiple parties, validated under a threshold-based model (e.g., "any 3 out of 5 signers"). Would it make sense to mention that these cases are out of scope, or at least acknowledge them as directions for future consideration? 5- Related to hybrid key lifecycle management: 5.1: What happens when one component key expires but the other is still valid? 5.2: How is key compromise handled if only one component key needs to be revoked? 5.3: How are key updates or rotations managed when the components may have different lifecycles? 6- Table 2: Which combinations provide WNS or SNS? Would it make sense to add a column indicating whether each case "Provides WNS", "May enable SNS", or is "Insecure (separable)"? 7- What about telemetry for hybrid signature validation?, for example, to know how many hybrid signatures failed due to component A vs. B. 8- Nits: becasue --> because Thanks for this document, Ines. _______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
