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

[Falko Strenzke <[e-mail]>]

Hi Stephen,

see my comments inline.

Am 14.05.25 um 00:11 schrieb Stephen Farrell:
>
> I have a few personal comments below, none of which should delay us
> in publication. (Unless they resonate much more widely than I expect.)
>
> It looks to me (and dkg, based on off-list mail) like we do have
> consensus to proceed with this, but in chair-mode, we should look back
> over the  WGLC comments and send a mail to the list to confirm that etc.
> I think we may want a -09 draft too based on the earlier comments, but
> should then be good to push ahead.
>
> My non-blocking personal comments/queries are below - it is ok to ignore
> 'em, honest:-)
>
> Cheers,
> S.
>
> - 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.
>
I don't fully understand what you are referring to by "secret or private 
values" here. For instance, what do you mean by "KEM private values"? Do 
you mean the key shares from the individual KEMs (e.g. "mlkemKeyShare" 
in the draft) that are created by the KEM encapsulations or the result 
of the KEM combiner ("KEK" in the draft)? These values are never reused. 
For the encryption / encapsulation only the public keys are input values 
to the operation. Or do you mean that the corresponding private keys 
should not share key material?

In my understanding the only question that needs to be addressed is 
whether private key material can be reused – for instance a private 
ML-KEM+X25519 key could in principle share the EC key material with a 
standalone X25519 key. See my comment below on how the draft deals with 
that and why.

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

Do I understand you correctly that you are OK with keeping the current 
statement that generating fresh keys is RECOMMENDED but you propose to 
include an example for the case where keys might be reused?

For the background: Initially, we had precluded key reuse entirely. 
Based on issue #71 
<https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/71> raised by 
Justus we weakened the statement to the current form in PR #88 
<https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/88/files>. The 
concrete use case from Justus was the reuse of an ECC key on a hardware 
token that is already used as a standalone key and should be reusable in 
a newly generated PQC-composite key. (So that the user doesn't have to 
buy or handle to hardware tokens).

What statement I could imagine to add is to explicitly say that only 
such reuse of private key material is allowed as in Justus' example, but 
not the reuse of the private key seeds across algorithm IDs (as you 
mention for the two SLH-DSA 128bit algorithms, or between any other PQC 
algorithm where the seed lengths match). Such key reuse seems a bit 
far-fetched to me, though. Would you prefer that we include such a 
statement anyhow?

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

First of all, I respectfully disagree that the draft is defining many 
new algorithms. In comparison with LAMPS (as per current draft versions) 
, this is only a very small subset. Just to give a rough overview: LAMPS 
defines all 12 SLH-DSA parameters, where OpenPGP defines 3. LAMPS 
defines ML-DSA and ML-KEM combinations not only with the Edwards curves, 
but also with NIST and Brainpool curves. Not to mention combinations 
with RSA.

Second, we need to keep in mind that due to the decision of defining 
each security parameter set as a distinct code point, we naturally 
arrive a more code points than this is the case for the historic 
algorithms. We only introduce 3 new algorithms, but due to the parameter 
multiplicity (which is already very restricted in my view) we end up 
with 2+2+3 = 7 code points.

Third, I want to remind us that we reduced the number of new algorithms 
already significantly from the initial proposal (less SLH-DSA code 
points, removal of Brainpool curves).

>
> - 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.
As posted on the list by Aron, in the draft repository the test vectors 
have already changed again, so it makes sense for people to wait for the 
09 version for the final check.
>
> - nit: We use ":=" without definition, and I'd say just
> "=" would be just as good?

I personally agree to this proposed change. RFC 9580 also uses "=".

Best regards,
Falko

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

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>