This came up briefly during the meeting at 120. Basically for now we align with FIPS204 without pre-hashing per comment from NIST at 120.
We can add separate support for pre-hashing but need to approach this carefully. Mike Prorock On Tue, Jul 30, 2024 at 7:52 AM Orie Steele <[email protected]> wrote: > The intention is to register the same algorithms. > > Pre-hash algorithms should be treated the same way, but because COSE and > JOSE has algorithm as optional, unless there is domain separation in the > public keys, that would be application later alignment. > > Pre-hash seems like a good idea, especially if folks are moving from ES256 > with SHA-256. > > Any application interfaces that JOSE or COSE have built around pre-hashing > are probably easier to preserve. > > Imo, it would be good to have the domain separation in the keys as > signatures and not rely on application layer signaling. > > OS > > On Mon, Jul 29, 2024, 10:48 PM Michael Jones <[email protected]> > wrote: > >> 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]> >> *Sent:* Monday, July 29, 2024 11:57 AM >> *To:* pqc-forum <[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]. >> 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]. >> 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]
