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

Hi,

I have reviewed draft-ietf-openpgp-pqc-12 and have a few questions that
may or may not lead to text changes. Note that in general, the document
is well written, clear and to the point.


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?



 	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)


Section 4.2.1

Should the symbol "||" be explained?


 	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 ?


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?

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]

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.


Section 8.2

Similar with the lowercase "may" here.

Section 8.3

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

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" ?


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?




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?



Paul

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]