[openpgp] Re: WGLC for draft-ietf-openpgp-pqc [was: Re: I-D Action: draft-ietf-openpgp-pqc-08.txt]

[Daniel Huigens <[e-mail]>]

Hi all,

I've updated the PQC test vectors in the interoperability test suite to
those from draft-08, and we have interop between development versions of
rpgpie, gopenpgp and rnp: https://tests.sequoia-pgp.org/?impls=16420&q=pqc.
OpenPGP.js will follow soon(tm).

Although the tests are green, the behavior isn't fully consistent
between the implementations for the keys that have multiple subkeys,
due to the lack of consensus on encryption subkey selection [1]:
rpgpie encrypts to all subkeys, gopenpgp uses the PQC subkey, and
rnp uses the ECC subkey. Two out of the three of those options
obviously don't achieve post-quantum security.

In previous discussions, we said that encryption subkey selection should
be orthogonal to the PQC draft. However, there is still other text in
the draft suggesting that it should be possible to achieve post-quantum
security by adding a subkey, namely in Section 3.5 (Key version binding):

> ML-KEM-768+X25519 (...) is also allowed in v4 encryption-capable subkeys.
> This permits the keyholder of an existing v4 certificate to add such a
> subkey to defend against store-now, decrypt-later attacks from quantum
> computers without moving to a new primary key.

and Section 8.3 (Key generation strategies):

> Two migration strategies are recommended:
> (...)
> 2. Attach PQ(/T) encryption or signature subkeys to an existing
>    traditional v6 OpenPGP certificate. (...)

(also, if we want to keep this text, it should say "v6 or v4").

So, I see two options:

1. We remove or water down that text, and change the test vectors to
   only have one subkey. (We can make test vectors with multiple subkeys
   once we decide how implementations should behave in that case.)

   However, this would also weaken the justification for allowing
   ML-KEM-768+X25519 to be used in v4 certificates a bit, as it wouldn't
   be possible to add a PQC subkey to an existing certificate to
   (reliably) get post-quantum security, for now.

2. We try to, after all, get consensus that for the test vectors
   presented in the draft, implementations should select the PQC
   subkey, only, and revert some of the changes in draft-08 to make
   that more clear/explicit, perhaps qualified by saying that future
   drafts may amend this guidance. For example, we could say
   (adapted from draft-07):

       In the absence of other indications or guidance on which
       encryption key(s) to select, implementations SHOULD prefer PQ(/T)
       keys when multiple options are available.  When encrypting to a
       certificate that has both a valid PQ/T and a valid traditional
       encryption subkey, an implementation SHOULD use the PQ/T subkey
       only.  Furthermore, if an application has any means to determine
       that encrypting to a PQ/T certificate and a traditional
       certificate is redundant, it should omit encrypting to the
       traditional certificate.

   I'll also make a separate posting to the encryption subkey selection
   thread to try to justify this further.

I originally leaned towards the first option, because of previous
discussions here, but now lean more towards the second, as I think
it'll require fewer changes to this draft, and thus hopefully cause
less of a delay (if the text proposed above is acceptable to folks).
It'd also allow people to achieve post-quantum (encryption) security
sooner.

Apologies for catching / bringing this up a bit late, and on Labor Day
no less :)

Best,
Daniel


[1]: https://mailarchive.ietf.org/arch/msg/openpgp/FMzCI78v8fcRyGovPHpv8ZvxVnI/