[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 | <8i7juVt8s33E6MZVPdLn1AzVawtB6xCKnMO-i4ZZrqznqzLdGOmzICbxJF_3VY4EQ7muY5NwzyqBjFqGUdtwmpw5BwY_biJsYUEWWj0vk9M=@protonmail.com> |
Hi Aron & all, Thanks! I think this is a reasonable course of action for the PQC draft since it doesn't seem like we're very close to a consensus on the encryption subkey selection discussion, unfortunately. (Hopefully we can still make some progress on that in parallel, or soon after this draft becomes an RFC.) Best, Daniel On Thursday, May 8th, 2025 at 10:58, Aron Wussler wrote: > Hi everyone, > > After gathering all the feedback, we decided to simplify the guidance, and consistently remove the remaining statements regarding sub-key selection. > This is reflected in the editor copy [1]. > > The test vectors have also been accordingly updated as announced last week. > > We thank the people involved in this discussion and ask them to review this change. > > Cheers, > Aron > > [1] https://openpgp-pqc.github.io/draft-openpgp-pqc/draft-ietf-openpgp-pqc.html > > -- > Aron Wussler > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > > > > On Tuesday, 6 May 2025 at 11:12, Daniel Huigens [email protected] wrote: > > > 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]_______________________________________________ > > openpgp mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]