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

Daniel Kahn Gillmor <[email protected]> Mon, 15 Sep 2025 13:56:06 -0400
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Hi Paul, OpenPGP, and PQC folks--

Paul, thanks for the close read and your feedback here!

My comments are inline below.  I hope other folks from the WG (including
editors of the draft) will also weigh in.

On Fri 2025-09-12 16:22:55 -0400, Paul Wouters wrote:
> 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?

The presence or absence of a signature isn't something that the
recipient can rely on.  For instance, an attacker might completely
remove one of the signatures, and leave no trace.

If you wanted to require the two always be present together, you'd need
some signalling in each signature packet to indicate that it expects its
twin to also be present, and then all verifiers would need to understand
that signalling in order to not fail open.

Another approach would be to ensure that an OpenPGP certificate that has
multiple signing-capable subkeys could indication that signatures from
certain subkeys needed to be coupled with signatures from each
subkey. This would also prevent an attacker from stripping one of the
signatures on a signed object, but it would introduce novel subkey
semantics into an OpenPGP certificate, which again would require
widespread adoption before such subkeys could be safely deployed.

The working group elected to not build out any of this potentially
delicate machinery, and simply tie the underlying cryptographic objects
together in a single OpenPGP signature for the hybrid signature formats.

This retains the traditional OpenPGP semantics where multiple OpenPGP
signatures may be present in any signing scenario, and at least one of
them needs to be valid, from an expected signer, in order for the object
to be considered correctly signed.

>  	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)

As noted in on 2025-04-15 in

    https://mailarchive.ietf.org/arch/msg/openpgp/02A6UOphJwk0npU_qOZ6IppwaTc

this decision was made "to allow for a pq-upgrade path without rotating the primary key".

Prior to the exception, PQC was only available in v6 certificates.

> Section 4.2.1
>
> Should the symbol "||" be explained?

I think "||" is widely understood in wireframe specifications to be the
concatenation operator, but i have no objection to writing it down.

I've offered 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 ?

I don't think there is a "network host order" for text strings in
US-ASCII (or in its superset UTF-8).  As falko noted, the view you're
seeing is an artifact of your hexdump implementation:

```
0 dkg@bob:~$ echo -n OpenPGPCompositeKDFv1| hd
00000000  4f 70 65 6e 50 47 50 43  6f 6d 70 6f 73 69 74 65  |OpenPGPComposite|
00000010  4b 44 46 76 31                                    |KDFv1|
00000015
0 dkg@bob:~$ echo -n OpenPGPCompositeKDFv1| hexdump
0000000 704f 6e65 4750 4350 6d6f 6f70 6973 6574
0000010 444b 7646 0031                         
0000015
0 dkg@bob:~$ 
```

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

OpenPGP has used the empty context string for other algorithms (see
https://www.rfc-editor.org/rfc/rfc9580.html#section-12.7-3 for example),
so this is in line with other OpenPGP behavior.

I don't know how many implementations of these primitves actually
support the signing context string.  If there are some that only support
an empty context string during either signing or verification, then
those wouldn't be usable with OpenPGP if we require a non-empty string.

With no hats on, i would have no objection to requiring a uniform
context string like "OpenPGP" for both ML-DSA and SLH-DSA assuming all
significant cryptographic implementations of those algorithms make it
easy to support. It would mean requiring every OpenPGP implementation to
adjust their signing and verification code, but i don't think that would
be a particularly complex change.

Note that for within-OpenPGP uses, the objects being signed are already
clearly distinguished from one another by means of including the
signature type, algorithm ID, etc. in the octet stream representation of
the signed message.

> 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]

I think it's answered in section 9.5, not 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.

The working group has discussed this primarily in the context of the
e-mail ecosystem, and we reached the conclusion that "cannot encrypt
this message" when doing "reply all" would be actively harmful today.

This is under "Migration considerations" after all.

In the future, when support is more widely deployed, this guidance might
change.

What if we phrased it like:

   During the transition to post-quantum cryptography, an implementation
   attempting to encrypt a message to both PQ(/T) and traditional keys
   should generally proceed by default (perhaps logging a warning) to
   avoid disruption to communications.  A future revision of this
   specification may prohibit encrypting a given message to both PQ(/T)
   and traditional keys.

> 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.

I could see this using RFC 2119 SHOULD instead of "should", since we are
concerned it will effect interoperability.  The document uses 2119
RECOMMENDED in section 8.3.

> Section 8.2
>
> Similar with the lowercase "may" here.

Sure, i wouldn't object to MAY here.

Re-reading these sections in the migration considerations section, it
occurs to me that verification nuance is subtly different from signing
nuance during the transition period.  I've proposed some text that might
account for that nuance here:

  https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/227

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

The working group could see no way to critically enforce the MUST here
-- it certainly wouldn't break interoperability unless each
implementation were to keep track of all asymmetric public keys (as
cryptographic objects) used in OpenPGP, and prepared some sort of
blocklist based on objects that showed up more than once.  And the WG
didn't want a MUST NOT BUT WE KNOW SOME OF YOU WILL 😉

Apparently some users might find key generation expensive; for
example, those who are in need of using a key stored in some sort of
hardware module that can't be cheaply re-generated.

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

Upon re-read, i'm also not sure I understand this paragraph.  The prior
section (which describes the protections offered by the algorithm ID
field) makes more sense to me.  Perhaps the editors can clarify?


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

I've proposed this in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/226

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


Yes, you can see interoperability testing of 5 different implementations
at:

https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?q=pqc&impls=16970

(search for draft-ietf-openpgp-pqc to find the explicit test vectors)

They are indicated as being from draft-ietf-openpgp-pqc-09, but the test
vectors haven't changed between that draft and -12, as you can see here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-openpgp-pqc-09&url2=draft-ietf-openpgp-pqc-12&difftype=--html


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

I agree it would be good to resolve all of these nits.

Regards,

        --dkg

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