Re: [lamps] [EXTERNAL] SLH-DSA in CMS/X.509

[Mike Ounsworth <[e-mail]>]

I support that we need to sort this out.

 

I have no preference for how it is sorted out (any of the options outlined
by Dan seem fine to me).

 

---

Mike Ounsworth

 

From: Daniel Van Geest <[e-mail]> 
Sent: Thursday, February 15, 2024 6:41 AM
To: 'Kampanakis, Panos' <[e-mail]>; Mike Ounsworth
<[e-mail]>;
[e-mail]
Cc: 'LAMPS' <[e-mail]>
Subject: [EXTERNAL] SLH-DSA in CMS/X.509

 

Forking from "Can ML-DSA be used in CMS" because it's the same problem with
a different subject. The question of separate drafts also applies to
SLH-DSA. One line in draft-ietf-lamps-cms-sphincs-plus shouldn't be
sufficient 



Forking from "Can ML-DSA be used in CMS" because it's the same problem with
a different subject.

 

The question of separate drafts also applies to SLH-DSA. One line in
draft-ietf-lamps-cms-sphincs-plus shouldn't be sufficient to say to the IETF
world "And now you can use SLH-DSA in X.509!".

 

draft-gazdag-x509-hash-sigs would do that work.  At 118, Stefan kindly asked
for adoption and there weren't any objections in the queue. But I haven't
seen a call for adoption on the list. There was also no opinion on splitting
the draft (SLH-DSA and XMSS/HSS).  Since draft-ietf-lamps-cms-sphincs-plus
is adopted, we should have something adopted at the X.509 level, whether
it's draft-gazdag-x509-hash-sigs or a split draft for just SLH-DSA.

 

Question for the chairs: Was there sufficient interest for adoption of
draft-gazdag-x509-hash-sigs at 118, and it was just missed?

 

Question for the WG: Should draft-gazdag-x509-hash-sigs be split into
SLH-DSA and Stateful HBS drafts? My opinion:
draft-ietf-lamps-cms-sphincs-plus shows demand for SLH-DSA in IETF
protocols. A separate SLH-DSA in X.509 draft would progress faster because
it's not weighed down by the concerns around stateful algorithms. If somehow
draft-ietf-lamps-cms-sphincs-plus can progress without an associated X.509
draft I guess that's okay too. If they should be split, I can spin up the
SLH-DSA draft. It'll be a lot of copy-paste, so if you think I'll be copying
your text and can help with that, let me know.

 

Daniel

 

 

 

From: Spasm <[e-mail] <mailto:[e-mail]> > On
Behalf Of Kampanakis, Panos
Sent: Wednesday, February 14, 2024 3:08 AM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail]
<mailto:Mike.Ounsworth=[e-mail]> >;
[e-mail]
<mailto:[e-mail]> 
Cc: 'LAMPS' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] Can ML-DSA be used in CMS?

 

Hi Mike,

 

We could consider doing all ML-DSA in CMS and X.509 in one draft, but
personally I would rather we kept them separate like we did with SHAKEs in
CMS (rfc8702) and X.509 (rfc8692) or with EdDSA in CMS and X.509. They are
more straightforward for implementers that way. 

 

We could change that if there was WG consensus. 

 

Note that draft-ietf-lamps-cms-sphincs-plus mentions about SLH-DSA in CMS 

 

"When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of
an X.509 certificate [.]" 

 

So, it includes how the SLH-DSA OID can be used in X.509 cert public keys as
well, but it does not mention how to use the signatures. 

 

 

From: Spasm < <mailto:[e-mail]> [e-mail]> On
Behalf Of Mike Ounsworth
Sent: Tuesday, February 13, 2024 8:37 AM
To:  <mailto:[e-mail]>
[e-mail]
Cc: 'LAMPS' < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] [lamps] Can ML-DSA be used in CMS?

 


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.

 

The answer obviously is Yes, but draft-ietf-lamps-dilithium-certificates
does not actually say this.

 

I was reading a draft ICAO ePassport document yesterday that correctly
points out that IETF has a draft for how to use ML-DSA into X.509
certificates, but no draft for how to use ML-DSA in CMS.

 

Authors of draft-ietf-lamps-dilithium-certificates, if you add a section
"Signed-data Conventions" modelled after RFC8419, then I think that saves us
from needing a whole second ML-DSA draft.

 

---
Mike Ounsworth
Software Security Architect, Entrust