[openpgp] Re: AD review of draft-ietf-openpgp-pqc-12

Aron Wussler <[email protected]> Tue, 23 Sep 2025 15:08:17 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<fKjhATw2qfjO1RtOy6wHYlt1AED_yR1O6Ap8oMearM_OBx8tqhUuBcOzHQvnxBwzuatpO4OE413obNOj-S3bxFUurqAh4uJIGvACrJ8EPCo=@wussler.it>
Hi everyone,

We collected and acted upon the feedback of Paul. Thank you DKG for leading many discussions.

Here's our state, please give feedback until October 12th.

> Section 3.2 / 3.3
> 

> Why are multiple signature packets not treated the same as composite signatures?
> That is, if both traditional and PQ signature packets by the same sender are
> availablle, why not require them both just like if they were send as a composite
> signature in the same signature packet? (eg the 3.2 MUST vs the 3.3 MAY). Especially
> if this is needed as claimed in 3.2 to support legacy clients. Otherwise, one would
> have to include a legacy signature packet, and a signature packet with legacy+PQ
> coposite to accomplish the same?

We outlined the difference between composite vs composable signatures, and the complexity introduced by the latter at the protocol level.
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/228


> with the single exception of ML-KEM-768+X25519 (algorithm ID 35),
> which is also allowed in v4 encryption-capable subkeys.
> 

> What is the reason / justification of this exception? (this also appears in 4.3.2)

This was agreed as a store-now-decrypt-later protection fallback without changing the primary key.
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/229


> Section 4.2.1
> 

> Should the symbol "||" be explained?

Addressed in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/225

> The value domSep is a constant set to the UTF-8 encoding of the string "OpenPGPCompositeKDFv1", that is:
> 

> domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31
> 

> 

> $ echo -n OpenPGPCompositeKDFv1| hexdump
> 0000000 704f 6e65 4750 4350 6d6f 6f70 6973 6574
> 0000010 444b 7646 0031
> 

> Should a note be added about the byte string being network/host order ?

This is a conversion artifact, discussed here
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/230


> Section 5.1.2. ML-DSA Signatures
> 

> Why is the context string empty and not set to "OpenPGP" or something? Wouldn't
> this strengthen against cross protocol attacks?

This was decided because of library support, that has since partly changed.
Full discussion here: https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/231

I personally oppose wire format changes at this stage if not necessary, especially given this would still give implementation headaches with Botan and delay adoption by months.

> Section 7
> 

> Why is AES-256 specifically bound to certificates that contains a PQ(/T) key ?
> Why that might be appropriate for a CCNSA profile, why would it be done in
> the generic PQ case? [I see this is answered in Section 8.5]

This was done because it doesn't increase the implementation footprint and improves the PQ security of the protocol.
It only mandates support, but not enforce the use of it.
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/233

> Section 8.1
> 

> An implementation should not abort the encryption process when
> encrypting a message to both PQ(/T) and traditional keys to
> allow for a smooth transition to post-quantum cryptography.
>
> I think this really depends on the usage/profile and I am not sure if
> this generic advise is best or even allowable in some cases. As with
> other migrations, people sometimes implement these separately, and in
> this case it might make sense to not allow a hybrid to fall back to
> encrypting to one participant with only classic encryption.
> 

> I am also confused by the lowercase "should not" for an "implementation".
> Usually we use strict RFC 2119 language for implementations and lower
> case guidance for (human) process/choices during operations.

We tried to reword the paragraph here: https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/234


> Section 8.2
> 

> Similar with the lowercase "may" here.

Change proposed here: https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/244

> Section 8.3
> 

> Why is the RECOMMENDED not a MUST? What is a possible valid exception case?

The MUST cannot be realistically be enforced
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/238


> Section 9.1
> 

> Furthermore, it is also not possible to craft a new signature
> for a message that was signed twice with a composite algorithm
> by interchanging (that is, remixing) the component signatures,
> which would classify as a weak existential forgery. This is due
> to the fact that each v6 signature also includes a random salt
> at the start of the hashed meta data, as also specified in the
> aforementioned reference.
> 

> Couldn't I simply choose to use the same "random salt" ?

The signer is assumed to be honest
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/239

> Section 11
> 

> The reference column only lists Section, but should list RFC-TBD plus Section.
> 

> 

> Appendix A
> 

> As I cannot verify these test vectors myself, did the WG have at least two
> independent implementations confirm these vectors are correct?

Multiple implementations verify them:
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/236
 

> Comments / NITS
> 

> Abstract:
> 

> advent of quantum computers
> 

> in the presence of quantum computers.
> 

> Can we use the same terminology as PQUIP recommends? eg here we should use
> cryptographically relevant quantum computer (CRQC) and "protect against CRQCs"
> 

> (see https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-engineers)
> 

> 

> Introduction:
> 

> Such cryptographic algorithms are referred to as post-quantum cryptography. Th
> 

> Perhaps introduce the acronym here, too eg post-quantum cryptography (PQC) to align it
> with PQUIP?
> 

> 

> For the two ML-* schemes, this document follows the conservative
> strategy to deploy post-quantum in combination with traditional
> schemes such that the security is retained even if all schemes
> but one in the combination are broken.
> 

> Maybe add a sentence that this is called a hybrid? (you do refer to I-D.ietf-pquip-pqt-hybrid-terminology
> later on int the document but not yet here)
> 

> 

> from the respective elliptic curve specification.
> 

> Can this get a normative reference appended?

All nits addressed: https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/242

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 343 B)