[openpgp] Re: OpenPGP PQC nit-picking (plus, SHA2-224 su bkey binding signatures and PKESK wire format)

Hi dkg,

First of all, a heartfelt thank you for all the work, PRs, and issues you've opened.

We'll take care next week of fixing/addressing them. Most of the issues seem to have a fairly straightforward way out, and we'll most likely go for it.

Regarding the two "hot topics", here are my 2c:

> - https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/198 interacts
> with the recent change in draft-10 to constain the digest algorithms
> usable with PQ(/T)

I agree with you it's just simpler to remove the requirements for key-binding sigs, and forbid everywhere sigs with <256 bits.

> - I observed a discrepancy in the documentation of the v3 PKESK wire
> format for PQ/T encryption: in one location in the draft, the length
> octet appears before the cipher algo ID octet. 


We'll fix the position of the octet, but at this point I'd prefer to keep it. Removing it probably means burning the codepoints.

If people on the list have strong feelings to remove it, we can still do it.
Alternatively, we can add a note to explain why it's there, so no other later specification makes the same mistake?

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Friday, 30 May 2025 at 01:29, Daniel Kahn Gillmor <[email protected]> wrote:

> Hey all--
> 

> As I was working to prepare the shepherd's writeup for
> draft-ietf-openpgp-pqc, i decided to do a top-to-bottom "clean read" of
> the document to look for nits i could clean up before we send the doc to
> WGLC.
> 

> This resulted in rather more than i'd hoped for, and i've inflicted some
> damage on the document's github tracker at
> https://github.com/openpgp-pqc/draft-openpgp-pqc as a set of PRs (where
> there was what seemed to me a single straightforward or trivial cleanup)
> and issues (where there was more than one way to clean up the nit, or
> where i just thought someone with more skill/knowledge than me should
> write down the clarification).
> 

> Please go take a look at those issues and PRs when you get a chance, if
> you're interested in getting this document out the door and over to IETF
> LC.
> 

> None of the nitpicking i've proposed has anything substantive in it that
> i'm aware of, with the following two subtle exceptions:
> 

> - https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/198 interacts
> with the recent change in draft-10 to constain the digest algorithms
> usable with PQ(/T) -- I think there's a question there about whether
> we should permit subkey binding signatures from traditional ("T")
> primary keys over a PQ(/T) subkey that use SHA2-224. We aren't
> allowing PQ(/T) sigs themselves to use SHA2-224, so i would argue
> that it's simpler to forbid them on subkey binding signatures over
> PQ(/T) subkeys as well.
> 

> - I observed a discrepancy in the documentation of the v3 PKESK wire
> format for PQ/T encryption: in one location in the draft, the length
> octet appears before the cipher algo ID octet. In the other, the
> length octet appears after. In the PKESKv3 test vector, it looks to
> me like it appears before. This led me to question why we have the
> length octet there at all -- and that led me to
> https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/45, an a old
> issue raised by Justus Winter where he also observes that it seems to
> be unnecessary. I've tried to make the document internally
> consistent (agreeing with the test vector) in
> https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/205 but i would
> also be willing to accept a wire format change that simply removes
> the length octet entirely from both PQ/T PKESKs.
> 

> I'd prefer to move on over bikeshedding here -- if folks want to just
> accept a fixed octet, that's OK with me. Aron argued in #45 that
> it's there in alignment with RFC 9580's PKESK framing for X25519 and
> X448, which seems to be correct to me, as they both also have the
> superfluous octet.
> 

> I have no strongly held feelings about any of the reports i've made
> here, so the authors (and anyone else interested) should also feel free
> to just close those issues/PRs with a short explanation, without making any
> changes.
> 

> Regards,
> 

> --dkg
> _______________________________________________
> 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]

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmg7TmwJkH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdL3WDMf6RaDzPmkerQSWHZfjH6ZTMCCvLorFjZ
WiW4NBYhBIuVslFfa7tqthSdVX5nYVY+/jkwAACIFQEA1sRnICL6gAPJFd+A
JPj9H2Aufapq313xmIq0G8x5TpQBAKPpzrjcj2Z21f+MwkZRsI5bvl6PisI0
4NUoJVwx+jYG
=mWpQ
-----END PGP SIGNATURE-----