As was previously announced on the pqc-forum, ML-DSA and SLH-DSA will specify separate "pure" and "pre-hash" versions, with domain separation to prevent pre-hash signatures verifying as pure signatures and vice versa.
The IETF LAMPS working group is developing drafts that will specify semantics for OIDs associated with ML-DSA and SLH-DSA: https://www.ietf.org/archive/id/draft-ietf-lamps-dilithium-certificates-04.html and https://www.ietf.org/archive/id/draft-ietf-lamps-x509-slhdsa-01.html. In these drafts, for each parameter set, the same OID is used to identify both a public key and a signature. However, the IETF drafts do not account for the separate pure and pre-hash options.
For the digital signature algorithms in FIPS 186-5 the public
key and the signature algorithm identifiers are separate. For
example, with ECDSA the public key is just identified as an
elliptic curve key (ecPublicKey) and only the signature
algorithm identifier indicates what hash function to use to
verify the signature (e.g. ecdsaWithSHA256, ecdsaWithSHA512).
Using SLH-DSA-SHA2-128s as an example, if NIST were to follow
this approach with ML-DSA and SLH-DSA, then any public key using
the SLH-DSA-SHA2-128s parameter set could be identified using
the OID id-alg-slh-dsa-sha2-128s. A pure signature would also be
identified using id-alg-slh-dsa-sha2-128s. A pre-hash signature
would be identified with an OID that also indicated how
pre-hashing was performed (e.g.,
id-alg-slh-dsa-sha2-128s-with-sha256-prehash).
A second option (as suggested in https://mailarchive.ietf.org/arch/msg/spasm/Ssk0hTwLm2ao0Fkvxa7jyfdMREg/) would be for the public key identifier to indicate how signatures are generated. In this case, if a public key were identified as id-alg-slh-dsa-sha2-128s, then it could only be used to verify pure signatures. A public key identified as id-alg-slh-dsa-sha2-128s-with-sha256-prehash could only be used to verify signatures created by pre-hashing with SHA-256.
While we believe that it is generally best not to use the same key for both pure and pre-hash signatures, we are currently inclined to use a single identifier for the public key (e.g., id-alg-slh-dsa-sha2-128s) regardless of whether the key will be used to generate pure or pre-hash signatures. An example of where this flexibility could be helpful would be in a PKI. A CA might use pure signatures to sign certificates, but use pre-hash signatures to sign CRLs. While certificates may be small enough to sign in a pure mode, CRLs can become very large. Also, if there is a concern about needing to depend on the collision resistance of the hash function when using the pre-hash option, this is less of a concern with CRLs. An attacker may provide a certificate request message that will be used in the generation of the certificate, but it would be much more difficult for an attacker to have any impact on the contents of a CRL (in a way that could create a collision).
We would appreciate any feedback you may have on this issue.
Thank you,
David
Hi David,
The ML-DSA and SLH-DSA X.509 drafts (and the SLH-DSA CMS draft) all had pure PQ signatures in the back of their minds like RFC8410 did for EdDSA. But the CRL use-case is an interesting one. Maybe prehash signing makes sense there if the signing frequency and message size justify it.
I would advocate for distinct identifiers for the pure and prehash variants of both the Sig and PK for the same reasons David B. lays out in his https://mailarchive.ietf.org/arch/msg/spasm/Ssk0hTwLm2ao0Fkvxa7jyfdMREg/ Maybe CRL signing does not have the same risk regarding collision resistance as you are suggesting and one PK identifier would make sense there, but these OIDs could be used in many places. We can’t predict they will go only in CRL signing.
Rgs
From: 'David A. Cooper' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, July 29, 2024 11:57 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] Pure and pre-hash object identifiers for ML-DSA and SLH-DSA
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. |
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0ec37c8d-a78e-4630-af5e-0ac1ad1177d4%40nist.gov.