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

[Mike Ounsworth <[e-mail]>]

Hi Wai Choi,

 

Answers inline tagged with [[MO]].

 

---

Mike Ounsworth

 

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

 

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, 



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?

[[MO]] I think I misunderstood your question. I thought you were asking
whether we would register separate OIDs for public key algorithms vs
signature algorithms.

[[MO]] RFC5280 does not require that SubjectPublicKeyInfo.algorithm and
signatureAlgorithm be the same, and I am not aware of any other technical
restriction that would prevent you from signing the public key of one
algorithm with a different algorithm (other than, as you note, the
self-signed case).

 

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.

 

 

[[MO]] Sorry for not being clear; I meant the SubjectPublicKeyInfo in the
Root would be LMS; the SubjectPublicKeyInfo in the ICA would be Dilithium
(and it would carry an LMS signature), and the SubjectPublicKeyInfo in the
EE would be ECC and it would carry a Dilithium signature.

[[MO]] Again, this is just an example of something that may make sense in
some specific case, therefore, in my opinion, the IETF should not block it.

 

 

Wai Choi

 

From: Mike Ounsworth <[e-mail]
<mailto:[e-mail]> > 
Sent: Tuesday, February 13, 2024 11:23 AM
To: Wai Choi <[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?

 

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/
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamp
s-cms-kyber/__;!!FJ-Y8qCqXTj2!cMQNKvtV9_9h9onqgOmMtVPUsl0nmpi8Zv_QBBtPD_TnFV
OXaisbzSIKbWEFaWjmRecuCVgkEE3qqkx9-Q$> 

(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