[openpgp] OpenPGP PQC nit-picking (plus, SHA2-224 subkey b inding signatures and PKESK wire format)

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]