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

On Sat 2025-05-31 18:46:14 +0000, Aron Wussler wrote:
> 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.

Thanks, yes, i agree that there are straightforward ways to clean up.  I
think almost all of it should be non-controversial, it's just a matter
of doing the cleanup work.

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

To be clear: i think this draft still does need to say something
actively and specifically about *subkey* binding signatures, since those
can be made by a plain ol' T (traditional) primary key.  The cross-sigs
("primary key binding sigs) from the PQ(/T) subkey don't need any extra
guidance.

I suppose this does raise one more question for the completists among
us, which is whether this draft should bother making a declaration about
the cross sig from a T subkey of a PQ(/T) primary key.  I'm fine with
this draft remaining completely agnostic on that front, though.

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

I don't think anyone has actually released software with this, so (with
no hats on) i don't think we need to burn the codepoints.  But i also
don't object to keeping it at this point. It does certainly seem simpler
process-wise to keep it.

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

I wouldn't object to a brief note to discourage repeating this mistake
for future algorithms.

    --dkg

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