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

["Kousidis, Stavros" <[e-mail]>]

Hi,

Kaveh, Stefan and I are actually in the process of splitting draft-gazdag-x509-hash-sigs in two, exactly as is being discussed here, i.e.

X.509: Algorithm Identifiers for HSS and XMSS (and XMSS^MT)
X.509: Algorithm Identifiers for SLH-DSA

I’ve updated and pushed draft-gazdag-x509-hash-sigs yesterday for one last time in order to fix a bug in the ASN.1 module noticed by Russ and then started the split.

If you go to the github org https://github.com/x509-hbs you will see three repos now


-          draft-gazdag-x509-hash-sigs (the current non-splitted version, we might keep it for historic reasons)

-          draft-x509-shbs (intended for HSS and XMSS, we focus our work on that currently)

-          draft-x509-slhdsa (intended for SLH-DSA, still identical to draft-gazdag-x509-hash-sigs, our next work item)

The split is not super-complex but we need some time doing and reviewing it carefully. For draft-x509-slhdsa we will try to keep the text aligned to draft-ietf-lamps-dilithium-certificates and use the encodings given in draft-ietf-lamps-cms-sphincs-plus.

We will announce the two new drafts on the mailing list once it is done (probably in the next few days/by the end of next week).

Best
Stavros



Von: Ira McDonald <[e-mail]>
Gesendet: Donnerstag, 15. Februar 2024 19:13
An: Mike Ounsworth <Mike.Ounsworth=[e-mail]>; Ira McDonald <[e-mail]>
Cc: Daniel Van Geest <[e-mail]>; Kampanakis, Panos <[e-mail]>; [e-mail]; LAMPS <[e-mail]>
Betreff: Re: [lamps] [EXTERNAL] SLH-DSA in CMS/X.509

Hi,

I agree with Daniel and Mike that we should sort this out for SLH-DSA.  And I would prefer splitting
draft-gazdag-x509-hash-sigs in Stateless and Stateful HBS drafts.  In automotive security there is
a near-term need for Stateless HBS and Stateful ones are simply non-starters (i.e., they don't scale
for performance to firmware for 150 Electronic Control Units (ECUs) per vehicle in 100 million cars).

Cheers,
- Ira



On Thu, Feb 15, 2024 at 12:21 PM Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
Sent: Thursday, February 15, 2024 6:41 AM
To: 'Kampanakis, Panos' <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'LAMPS' <[e-mail]<mailto:[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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Mike Ounsworth
Sent: Tuesday, February 13, 2024 8:37 AM
To: [e-mail]<mailto:[e-mail]>
Cc: 'LAMPS' <[e-mail]<mailto:[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

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm