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

Hi Falko,

On Tuesday, May 6th, 2025 at 08:08, Falko Strenzke <[email protected]> wrote:

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

But it is the responsibility of the PQC draft to enable post-quantum security, and make recommendations for actions that achieve that, no?

Currently, if you follow the second recommendation in Section 8.3, and then use implementations that implement the draft, you won't achieve post-quantum security in 2 out of 3 implementations, although the draft seems to imply it should (but nevertheless those implementations don't violate the draft). For me that's a bit of a contradiction.

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

I don't fully agree. For me the goal is to reach a consensus for a reasonable encryption subkey selection algorithm for senders, in order to achieve consistency and predictability for the certificate holder, and yes that in turn can help them craft their certificate in a way that causes their preferences to be honored.

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

If the OpenPGP implementations don't agree with the proposal, then we haven't achieved consensus, which is what I wanted to try to achieve. Maybe that's overly optimistic but let's not give up before we've tried :)

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

Section 3.5 says more than that, it says that "the keyholder of an existing v4 certificate [can] add such a subkey to defend against store-now, decrypt-later attacks from quantum computers without moving to a new primary key". But this is only true if the sender selects that subkey, which again is only true in 1 out of 3 implementations of the draft today. For me that means we should either change that text, or say that the other two implementations are not compliant with the draft (and give some guidance for what they should do instead).

---

All of that being said, there is kind of a third option which is: we leave draft-openpgp-pqc as-is, but we very quickly write up another draft for encryption subkey selection which makes the above statement in draft-openpgp-pqc true. I think that's a risky course of action if we don't manage to achieve consensus in the end, though, as we'll be left with an RFC for PQC in OpenPGP with a statement that's not true and a recommendation that doesn't work.

Best,
Daniel

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