Re: [lamps] Can ML-DSA be used in CMS?

[Wai Choi <[e-mail]>]

Mike,



Thanks for the pointer to Kyber.



My first question is: Can a certificate with PQ signature algorithm contains a non PQ public key, for example, signature is ML-DSA, but public key is X25519. Seems your answer is for self-signed certificate, right?



For the second question, I don't quite understand the example Root:LMS, ICA: Dilithium, EE: ECDSA. Are LMS, Dilithium, ECDSA referring to the signature algorithms on the Root, ICA, EE certificates respectively? If so, that implies the ICA has ECC key to create the ECDSA signature? In other words, this example illustrates ICA has low value since it does not use quantum safe key, and we can't tell whether EE has low value since we don't know what public key is on the certificate.



Wai Choi



From: Mike Ounsworth <[e-mail]>
Sent: Tuesday, February 13, 2024 11:23 AM
To: Wai Choi <[e-mail]>; [e-mail]
Cc: 'LAMPS' <[e-mail]>
Subject: [EXTERNAL] RE: [lamps] Can ML-DSA be used in CMS?



Hi Wai Choi,



We do already have a draft for Kyber in CMS. Please see: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/

(it is very out-of-date; we are working on a massive update and will have it published before 119).





To your other questions:



> 1. Although it makes sense to have PQ algorithms on both Signature Algorithm and Public key Algorithm, is it a MUST requirement?



I think the approach that we are taking with the new PQC algorithms is to use the same OID for both the Public Key Algorithm, and for the Signature Algorithm. This approach worked will for Ed25519, E448, x25519, x448, and it avoids cross-protocol attacks where a single key can be used for multiple different cryptographic schemes.



Was that your question?





> 2. Does the whole chain of certificates need to use PQ algorithms?



My personal opinion is that this is out-of-scope for IETF. I believe that IETF should specify the technical wire formats, and issue such as whether you are allowed to mix-and-match algorithms up a single certificate chain (and which algorithms are allowed to be mixed, and whether certificate lifetime comes into play, etc) are policy issues and thus outside the scope of IETF to specify.



As an example, I could imagine PKI scenarios where the PKI as a whole has high value, but individual end entity keys have low value. For example smartcards serving as low-value gift cards for a restaurant chain, or a backend TLS deployment where TLS Client and Server certs renew every 7 days. In those scenarios, I think it could be totally reasonable to deploy a PKI as: Root: LMS, ICA: Dilithium, EE: ECDSA. So I don't think that the IETF should make any opinion here.



---

Mike Ounsworth



From: Wai Choi <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 13, 2024 8:10 AM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'LAMPS' <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] RE: [lamps] Can ML-DSA be used in CMS?



Do we need a draft to address how to use Kyber in X.509 certificate? While having a certificate used for signing is common, one used for email encryption is not rare. Wonder why all the discussion focuses on signing only...



Other basic questions on PQ certificates:
1. Although it makes sense to have PQ algorithms on both Signature Algorithm and Public key Algorithm, is it a MUST requirement?



2. Does the whole chain of certificates need to use PQ algorithms?



Wai Choi



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



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