To what extent should our COSE post-quantum work be aligning with what's
happening in LAMPS? And what would that entail?
With curiosity,
-- Mike
From: 'Kampanakis, Panos' via pqc-forum <[email protected]>
Sent: Monday, July 29, 2024 7:25 PM
To: David A. Cooper <[email protected]>
Cc: pqc-forum <[email protected]>
Subject: RE: [pqc-forum] Pure and pre-hash object identifiers for ML-DSA and
SLH-DSA
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
<[email protected]<mailto:[email protected]>>
Sent: Monday, July 29, 2024 11:57 AM
To: pqc-forum <[email protected]<mailto:[email protected]>>
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.
Hi all,
As was previously announced on the
pqc-forum<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/JKMh0D0pa30/m/vbflXolxAQAJ>,
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
--
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
[email protected]<mailto:[email protected]>.
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<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0ec37c8d-a78e-4630-af5e-0ac1ad1177d4%40nist.gov?utm_medium=email&utm_source=footer>.
--
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
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/bc01337638364bf9a01ba1cabdd8a8aa%40amazon.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/bc01337638364bf9a01ba1cabdd8a8aa%40amazon.com?utm_medium=email&utm_source=footer>.
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
