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

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <tjL4ynTE9NJFn8rNxUVyb2s-NxorQ_1GKD4SHCl6DgFRSsb9A05B4Oq9PZMqTUYc7jTxb3pf-d_CkcrrAIDoFwv1QJIIbGfMjhj7Md6fyQo=@protonmail.com>
Hi Heiko,

On Friday, May 2nd, 2025 at 16:23, Heiko Schäfer wrote:
> I'll note that while this is not ideal for all scenarios, migrating to
> post quantum encryption is possible without further clarifying subkey
> selection, as follows:
> 
> 1. Adding a PQC subkey
> 2. Observing that this subkey is being (either exclusively or
> additionally) encrypted to by all relevant peers, and then
> 3. Decomissioning any pre-PQC encryption subkeys (by expiration or
> revocation).

Section 8.3, option 2 seems to imply that it should be possible to
achieve post-quantum encryption security from new implementations
_while_ being backwards-compatible with implementations that don't
support PQC:

> Implementations understanding PQ(/T) will be able to parse and use the
> subkeys, while PQ(/T)-incapable implementations can gracefully ignore
> them.

Revoking or expiring the old subkeys obviously makes the certificate
backwards-incompatible. So, I still think there's a contradiction
between what the draft says and what's actually possible when using
(2 out of 3 of) the current implementations of the draft.

Best,
Daniel

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.