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

[Stephen Farrell <[e-mail]>]

Hi Falko,

On 14/05/2025 07:39, Falko Strenzke wrote:
> 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)? 

The former.

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

Correct. Describing the unusual case for a SHOULD or RECOMMENDED
is generally useful if we can.

If the unusual case is really only "needs to re-use private key
from token" that may well be worth saying. If trying to add that
causes a bunch of discussion, then we're probably better off as
we are.

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

The closer we can get to "never do it unless <X>" the better
I think as it might affect where people put the keygen bit of
code and I'd guess the nearer we get to "keygen, use-key,
clean-up" all being close to one another, the less likely keys
might leak etc.

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

I do realise that people disagree with me about too-many, and
that's ok:-)

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

Yep. You can imagine what I think of that:-)

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

Indeed.

Nonetheless, if we can point at some text that justifies each
of the codepoints, that'll be better, because someone is likely
to ask (or to ask to add their fav other one).

Again though, all these comments are non-blocking, so if we
don't have that text, we can live without it and have the
discussion if/when someone asks later.

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

Yep, that's likely best.

Cheers,
S.

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