OASIS PKCS 11 TC

Β View Only
  • 1.  [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-05-2025 10:52

    Hi Mike,

     

    thank you for pointing to the recent posting on the NIST FAQ page. I had not seen this yet as I have been on PTO for a few days.

     

    This is indeed good news: it confirms that what is quite straightforward to implement as HSM interface will also be accepted by NIST when validating such HSM implementation. I have forwarded the hint to this new FAQ to my colleagues steering the implementation and certification of our HSM firmware.

     

    I copy the OASIS TC PKCS11 mailing list to have this discussion in a public forum, and use it as starting point for a TC discussion and eventually a new work item.

     

    P.S.: I have contacted our IT team to understand why your initial mail has been rejected. I will come back to you in a separate thread once I have their feedback.

     

    Best regards,

    Dieter

     



  • 2.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-05-2025 12:30

    Dieter,

    fwiw I can't reach your company email address either,

    all my messages get bounced, feel free to contact me with an alternative email address privately.



    ------------------------------
    Simo Sorce
    Red Hat
    ------------------------------



  • 3.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-05-2025 12:36

    Adding the remainder of the email thread with Francois Rousseau and Mike Ounsworth, which has been cut off by the OASIS system:

    From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
    Sent: Sunday, March 2, 2025 5:39 PM
    To: Francois Rousseau <frousse@icloud.com>; Dieter Bong <dieter.bong@utimaco.com>
    Subject: RE: [EXTERNAL] PKCS#11 mechanism with hash value
    πœ‡ for calculating an ML-DSA signature

    (I am trying to send again with my S/MIME signature removed since this seems to have been rejected by Dieter's email server. Why would an email server reject a signed email when it is happy to accept the same email in plaintext? This is a ridiculous example of "Error: Content is Secure")

    Thank you FranΓ§ois!

    Dieter, yes, my understanding also is that ML-DSA external Β΅ is actually closer to how HSM interfaces work today with RSA and ECDSA, and therefore should be easy to integrate.

    For FIPS compliance, Tim Hudson had private discussions with the NIST PQC (Dustin Moody) and CMVP (Chris Celi) teams around this, and this lead to NIST posting the following FAQ on the FIPS 204 page last week. We believe this is clear, but if you still have reservations, I would be happy to forward those to NIST on your behalf.

    https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs#Rdc7

    ---

    Mike Ounsworth

    From: Francois Rousseau <frousse@icloud.com>
    Sent: Sunday, March 2, 2025 7:45 AM
    To: Dieter Bong <dieter.bong@utimaco.com>; Mike Ounsworth <Mike.Ounsworth@entrust.com>
    Subject: [EXTERNAL] PKCS#11 mechanism with hash value
    πœ‡ for calculating an ML-DSA signature

    Hi Dieter, Please note that I am also copying Mike Ounsworth on this new e-mail since as I had indicated to you before, Mike and the IETF LAMPS working group previously discussed and concluded that PKCS #11 v3.β€Š2 should support a mechanism that

    Hi Dieter,

    Please note that I am also copying Mike Ounsworth on this new e-mail since as I had indicated to you before, Mike and the IETF LAMPS working group previously discussed and concluded that PKCS #11 v3.2 should support a mechanism that allows to input the hash value πœ‡ for calculating an ML-DSA signature.

    You had previously suggested that from a technical perspective, you believed it would be quite straightforward to define an additional ML-DSA mechanism that takes πœ‡ as an input.  However you had to be sure that such mechanism could also be FIPS validated, otherwise applications would not work when operated (using a crypto module) in FIPS mode.

    For your consideration,

    Francois

    Sent from my iPad

    Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.



    ------------------------------
    Best regards,
    Dieter
    ------------------------------



  • 4.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-05-2025 19:08
    I think if we support mu, it will be in 3.3. It's a little late to add it to 3.2 now.

    bob


    On 3/5/25 9:36 AM, Dieter Bong via OASIS wrote:
    010001956760fffc-0843d3e8-4b5a-4191-9bb9-583faa1005f9-000000@email.amazonses.com">
    Adding the remainder of the email thread with Francois Rousseau and Mike Ounsworth, which has been cut off by the OASIS system: From: Mike... -posted to the "OASIS PKCS 11 TC" community





  • 5.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-06-2025 10:26

    I'd prefer to delay 3.2 and add mu.

     

    Jonathan

     






  • 6.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-06-2025 10:32
    Handling of 'mu' is not something that we should hold up the 3.2 release for IMHO.
    We need to get a finalised version out for usage as a lot of capability has gone into 3.2. 

    Tim.






  • 7.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 03-06-2025 11:17

    THALES GROUP LIMITED DISTRIBUTION to email recipients

     

    There will most likely be instances of vendor specific ExternalMU mechanisms showing up if v3.2 doesn't include it.  I know we are strongly considering that on our side.

     

    What is the real urgency with v3.2?  Getting it promoted as a public draft is one thing, so I would prefer not to delay that too far. But what is the timeline for the public review period before it becomes final and what is the scope of work that we are willing to accept based on that feedback?  If we push v3.2 as a public draft as planned, we will mostly likely get many comments related to MU.  Is that not something that can be added as feedback based on public review?  Or is that too much of a stretch.  Its been more than a few years since I was involved in this process.

     

    I guess the challenge here is that ExternalMu wouldn't be an editorial change, so it would need to be a proposal that we vote on and get in to the spec and reviewed.  Is that an accurate assessment?  "If" we were to avoid delaying the move to public draft, we would need a proposal prewritten and shared on the group and informally accepted, and would need an updated spec including that, all ready for the next meeting so that we can have the required motions ready for approving.  And we need people that can commit to make these happen.

    Or is this all too much of a stretch/violation of our rules and processes?

     






  • 8.  RE: [EXTERNAL] PKCS#11 mechanism with hash value πœ‡ for calculating an ML-DSA signature

    Posted 04-01-2025 03:22

    NIST has recently updated their FAQ and confirmed that a mu computed externally and then signed by a function ML-DSA.Sign_internal_mu(sk, mu, rnd) is an acceptable implementation. Cf. 2. question on Post-Quantum Cryptography | CSRC .



    ------------------------------
    Best regards,
    Dieter
    ------------------------------