[openpgp] Re: WGLC for draft-ietf-openpgp-pqc

[Simo Sorce <[e-mail]>]

Some counter-comment inline.

Also adding that while I do not really like exactly every single choice
in these documents I think they are a good WG compromise and should be
moved forward w/o delay.

On Tue, 2025-05-13 at 23:11 +0100, Stephen Farrell wrote:
> 
> - I think (but am not 100% sure) we want it to be true that
>    no implementation makes unexpected multiple uses of any
> secret or private value at any time. For example, KEM
> private values when sending a mail to multiple recipients
> or signature private keys when signing twice with algs
> 32/33. Is that the case?  If so, should we say it (more)
> explicitly? We almost do say this in a few places, some of
> which RECOMMEND not re-using, others of which call for
> "independent" generation. Is this something we could
> tighten up on without breaking any use-cases? If we do have
> some real use-case that needs to re-use a secret or private
> value, (basically other than multiple alg-specific signing
> private key use), can we describe that as the
> counter-example to just saying RECOMMENDED rather than MUST
> NOT?

When using HW tokens with small storage it may be required to be able
to use the same private key for multiple signature schemes, I think
RECOMMENDs is strong enough and MUST NOT would be excessive (also
difficult to enforce, so kinda toothless).

> - 2.1: Five is IMO too many signature options. Can we not
>    reduce that number?  If not (as I suspect, I always lose
> this argument;-) then it'll help with later document
> processing if we can document why we need five in e.g. an
> email, in case someone asks, which they probably will.  (I
> forget if we covered this specifically in earlier debates
> sorry, if a reference provides a good answer, that's just
> fine.)

We ultimately want more than five, because the hybrids explode the
matrix, so I think this is something you just will have to make peace
with :-D

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc