[lamps] Re: PKCS#11 and signature context (and seeds askeys)

[Tomas Gustavsson <[e-mail]>]

For some reason 2 doesn’t make me feel comfortable. Redesigning standards we have today for signing just doesn’t sound like the fastest path to wide spread migration. And making a fetch of the public key will  severely affect performance, at least says the testing I have done with p11 for the past 10 years.

Cheers,
Tomas

________________________________
From: Mike Ounsworth <[e-mail]>
Sent: Tuesday, November 19, 2024 7:04 PM
To: Tomas Gustavsson <[e-mail]>; Kampanakis, Panos <[e-mail]>; Sophie Schmieg <[e-mail]>; Alicja Kario <[e-mail]>
Cc: [e-mail] <[e-mail]>; John Gray <[e-mail]>
Subject: RE: [lamps] Re: PKCS#11 and signature context (and seeds askeys)

I largely agree with where this thread landed: It’s *probably fine* if P11 allows HSM vendors to implement the ML-DSA.sign as either an internal-mu or external-mu.

Two additional thoughts:

1. Does “burying” it like this rob the application of the ability to control whether it wants internal-mu or external-mu? Maybe this is not desirable? Maybe if your P11 driver does external-mu with CPU-local hashing, then there is really never a reason to want internal-mu (HSM-internal hashing)?
2. Computing mu requires knowledge of the public key hash (tr). If the P11 client needs to make a network call to the HSM to retrieve tr, then doesn’t that completely negate the performance gain of CPU-local hashing? Shouldn’t P11 provide an interface whereby the application can pass in the public key tr, if it has it locally available? (this makes my security alarms go off due to the risks of passing in the wrong tr, but I’ll suppress that alarm for now).

---
Mike Ounsworth

From: Tomas Gustavsson <[e-mail]>
Sent: Tuesday, November 12, 2024 12:42 PM
To: Kampanakis, Panos <[e-mail]>; Sophie Schmieg <[e-mail]>; Alicja Kario <[e-mail]>
Cc: [e-mail]; John Gray <[e-mail]>; Mike Ounsworth <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Re: PKCS#11 and signature context (and seeds askeys)

I'd like to add though that in my experience the P11 client doesn't have to be CPU-local though. We have a normal case where the P11 client is in a side-car container to the main application container, so the payload still goes in i. e. a Kubernetes
I'd like to add though that in my experience the P11 client doesn't have to be CPU-local though. We have a normal case where the P11 client is in a side-car container to the main application container, so the payload still goes in i.e. a Kubernetes local network. But that should be able to handle more data. Rest based HSMs will have to implement a µ based API if that is the road chosen.

The Java Provider API have a initSign/Update/Sign architecture. I don't think there is an API taking a ctx currently though (please correct me if I'm wrong).
Tomas

________________________________
From: Tomas Gustavsson <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 12, 2024 5:36 PM
To: Kampanakis, Panos <kpanos=[e-mail]<mailto:kpanos=[e-mail]>>; Sophie Schmieg <sschmieg=[e-mail]<mailto:sschmieg=[e-mail]>>; Alicja Kario <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; John Gray <[e-mail]<mailto:[e-mail]>>; Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]> <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>
Subject: [lamps] Re: PKCS#11 and signature context (and seeds askeys)

I interpreted the Oasis answer as that the HSM vendor could divide it between module and pkcs11 client. Implementing the calculation of µ in the PKCS11 client, which is local (see attached picture). If I understood that wrong, it's bad. From: 

I interpreted the Oasis answer as that the HSM vendor could divide it between module and pkcs11 client. Implementing the calculation of µ in the PKCS11 client, which is local (see attached picture). If I understood that wrong, it's bad.

________________________________
From: Kampanakis, Panos <kpanos=[e-mail]<mailto:kpanos=[e-mail]>>
Sent: Tuesday, November 12, 2024 5:18 PM
To: Sophie Schmieg <sschmieg=[e-mail]<mailto:sschmieg=[e-mail]>>; Alicja Kario <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; John Gray <[e-mail]<mailto:[e-mail]>>; Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]> <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>
Subject: [lamps] Re: PKCS#11 and signature context (and seeds askeys)

OK, but until either OASIS or this group change their mind, we have a problem with use-cases where your HSM sits somewhere far away and your 100MB to-be-signed image or CRL sits somewhere else. Today, you can get away with just sending the digest

OK, but until either OASIS or this group change their mind, we have a problem with use-cases where your HSM sits somewhere far away and your 100MB to-be-signed image or CRL sits somewhere else. Today, you can get away with just sending the digest of the message over the network to the HSM for ECDSA signing (PKCS11 supports it). But it sounds like they don’t want to support this with mu.



Who is going to convince OASIS to change?









From: Sophie Schmieg <sschmieg=[e-mail]<mailto:sschmieg=[e-mail]>>
Sent: Monday, November 11, 2024 1:42 PM
To: Alicja Kario <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; John Gray <[e-mail]<mailto:[e-mail]>>; Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>
Subject: [lamps] Re: [EXTERNAL] PKCS#11 and signature context (and seeds askeys)



I would highly encourage OASIS to reconsider their position with respect to µ. Note that with PKCS11 in particular, there is another way of implementing ML-DSA without external computation of µ or resorting to HashML-DSA: PKCS11 has a stateful streaming API for signing, i.e. using a init/update/finalize paradigm. The init function involves indicating the key handle, i.e. specifying the private key already, which would allow the HSM to create a pure ML-DSA signature without even needing the external µ or prehashing. If they want an externally computed message identifier, I would highly suggest to using an externally computed µ. If they want to compute the message identifier internally, I would suggest using this streaming API and not use HashML-DSA, if only for CNSA2 compliance.



On Mon, Nov 11, 2024 at 10:05 AM Alicja Kario <[e-mail]<mailto:[e-mail]>> wrote:

I've talked with Bob some more and to summarise the three things raised
previously:

1. What about use of context in ML-DSA and SLH-DSA?
   A: It will be there in v3.2
2. Will PKCS#11 include external computation of `mu` for signing?
   A: No. And that's a strong position, already discussed in OASIS.
3. Will PKCS#11 allow import/export of keys by specifying seed only?
   A: Yes, there will be a new attribute (CKA_SEED) that will allow that,
   but it won't be mandatory to support it. Again, will be part of v3.2

the PKCS#11 v3.2 will also include the HashML-DSA together with
most SHA-2 (no SHA512-256 or SHA512-224) and all SHA-3 variants.

On Friday, 8 November 2024 13:45:43 CET, John Gray wrote:
> Thanks Alicja,
>
> This came up briefly at PQUIP yesterday.   I can also confirm
> what you said as I talked to Robert about this at ICMC back in
> September.  From my understanding, they are planning to use a
> PKCS11 mechanism parameter to convey the context to ML-DSA and
> SLH-DSA.
>
> Cheers,
>
> John Gray
>
> From: Alicja Kario <[e-mail]<mailto:[e-mail]>>
> Sent: Wednesday, November 6, 2024 1:14 PM
> To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> Subject: [EXTERNAL] [lamps] PKCS#11 and signature context
>
> I've talked with Robert Relya (co-chair on the OASIS technical comitte),
> and he said that they are aware of signature context for ML-DSA and
> SLH-DSA.
> Those, together with the encapsulation/decapsulation API will be part of
> the PKCS#11 v3.2.
>
> That version hopefully should be released by the end of this year.

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com<https://urldefense.com/v3/__http:/www.cz.redhat.com__;!!BjbSd3t9V7AnTp3tuV-82YaK!1VmjdTi2RMEh2PPR-m_ZtimUuuY3RAKYvFymyFQwkFzZ2KR-u3t53DxmldqWz01zdrNhQRSkT6ZGbRUIG_n3BtUCWLSlkrjq_TOkWnYx$>
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

_______________________________________________
Spasm mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>




--

Sophie Schmieg | Information Security Engineer | ISE Crypto | [e-mail]<mailto:[e-mail]>



Cheers,
Tomas