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

[Falko Strenzke <[e-mail]>]

Hi Daniel,

I don't see a problem in different implementations selecting different 
subkeys from the test vectors. While I understand that this is not an 
ideal situation, I also don't think that it is in the responsibility of 
the PQC draft to present test vectors that only allow an unanimous 
subkey selection. As you say yourself, we had agreed that this draft 
will not make a prescription on the subkey selection process. The 
natural effect of this is that different implementations may arrive at 
different sets of encryption subkeys.

We should also not forget that the actual purpose of the so-called 
encryption subkey selection process is to allow the certificate holder 
to express their preference regarding encryption subkey selection. But 
certainly there is always the possibility that the sender also enforces 
their own policy regarding the encryption key selection. One such policy 
might be, for example, to only use PQC keys. Moreover, the 
implementation of the encryption subkey selection mechanisms to be 
defined by the WG will remain a the discretion of the relevant OpenPGP 
implementation / mail client / user (sender) in any case. Accordingly, 
varying results for the encryption subkey selection process will remain 
normal.

Thus I don't see the need for either alternative 1. & 2. you give below. 
I also think the current statements in the draft saying that adding a 
PQC encryption subkey enables their use by senders that can parse them 
is valid and doesn't require to be changed. In my view, these statements 
do not trespass into the domain of an encryption subkey selection 
mechanism. They are simply stating the fact that, given that PQC 
encryption subkeys are present, these keys *can* be used by the sender. 
Whether the sender decides to do that in a specific case is another 
question – which is outside the domain of the PQC draft, as I think 
there is currently general agreement.

Best regards,
Falko

Am 01.05.25 um 19:07 schrieb Daniel Huigens:
> 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/
>
> _______________________________________________
> openpgp mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>