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

[Aron Wussler <[e-mail]>]

Hi Stephen and dkg,

# Key material reuse
I agree with dkg and Simo that enforcing a MUST for key material reuse is impossible. It used to be a MUST in earlier versions of the draft, and this was lowered because of concerns with HW tokens and enforceability.

# Algorithm selection
We're working on a PR that describes the algorithm usages and provides non-normative guidance.

# := nit
Approved your PR @dkg, I think we should just merge it

# Test vectors
The test vectors we included in the editor's copy were run via the interop test suite on 3 different implementations

# Releasing the new draft
As soon as we got the algorithm guidance in, I would be in favor of releasing version 09 without further delay

Cheers,
Aron

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



On Wednesday, 14 May 2025 at 20:31, Daniel Kahn Gillmor <[e-mail]> wrote:

> On Tue 2025-05-13 23:11:33 +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?
> 

> 

> I have the impression that it's a RECOMMENDED because ⓐ some people
> might have hardware keys that they feel obliged to reuse (yet another
> reason why hardware keys are problematic), but also ⓑ it would be
> unenforceable as a MUST. It's not going to be an interoperability issue
> unless the keyholder's peers reject certificates that share public key
> material.
> 

> I don't think anyone is seriously contemplating asking OpenPGP
> implementations to reject a certificate with shared public key material.
> 

> I wouldn't object if the draft were to explicitly call out the ⓐ case as
> the exception to the SHOULD, though it makes me sad to justify bad
> protocol choices based on bad hardware/software choices. Are there any
> other plausible reasons why someone would want to re-use?
> 

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

> 

> I agree that 5 is a lot, but it's not much compared to the full zoo.
> Count yourself lucky, Stephen ☺
> 

> I'd welcome a simple MR that tries to describe the justifications.
> 

> > - I didn't check the appendices/examples, but I know others
> > have (thanks!). We should also get somoene to confirm on
> > the list that the set of examples in the version we forward
> > for publication are (still) ok, again in an email to the
> > list so we can point to that later.
> 

> 

> Agreed, this would be great to have in a reportback on-list from the
> interoperability test suite, as the test vectors stabilize.
> 

> > - nit: We use ":=" without definition, and I'd say just
> > "=" would be just as good?
> 

> 

> sounds reasonable:
> https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/186
> 

> --dkg
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]