search

lamps-wg / x509-slhdsa

Repository of draft-ietf-x509-slhdsa
Other
0 stars 0 forks source link

Hash-SLH-DSA OIDs #9

Closed danvangeest closed 1 day ago

danvangeest commented 5 months ago

Once NIST publishes FIPS205, decide what to do about pure vs predigest mode. If we only support pure mode, add this text to the introduction:

The final version of {{FIPS205}} is expected to define two signature modes: pure mode and predigest mode. This document only specifies the use of pure mode with X.509 certificates and CRLs.

fluppe2 commented 3 weeks ago

NIST assigned OIDs to the parameter sets of the "pure" version of SLH-DSA and specific "pre-hash" combinations. See https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration

Would it be better to include the "pre-hash" versions that have OIDs assigned for the sake of completeness?

danvangeest commented 3 weeks ago

The WG has been trying to curtail OID explosions.

That said, they may become necessary in X.509, see https://github.com/lamps-wg/dilithium-certificates/pull/31#issuecomment-2441892740

We can wait for that discussion to occur and the fallout from it. However, because CMS has the signedAttributes feature, predigest mode isn't really necessary because the signedAttributes encoding will be relatively small.

danvangeest commented 2 weeks ago

While the WG determined that they do not want HashML-DSA because ML-DSA can have the message representative calculated by a different module (outside an HSM for example), this is not possible for SLH-DSA because it does a dual-pass. The WG still thinks that HashSLH-DSA is not necessary for use by CA certificates, but we can't control what will be done by EE users, so during the presentation I said that we will add a section specifying HashSLH-DSA OIDs for use in SPKI of end-entity certificates.

There is also a desire to prune the OIDs, but I think we should just offer all them all first and then if people complain hard and offer suggestions, reduce the list.