Question: how to create a certificate for ML-KEM pubkey?

[mouse07410]

Background

Using OpenSSL-3.4.0 with OQS provider (from Open Quantum Safe), I

1. generated ML-DSA and ML-KEM key-pairs,
2. created from ML-DSA key-pair an ML-DSA self-signed certificate to act as CA, and
3. created an ML-KEM certificate from ML-KEM pubkey, signed by the above CA.

Botan-3.7.0 parsed the above certs and validated the ML-KEM cert.

Goal

I want to replicate the above (1)-(3) with Botan, aka generate keypairs and create corresponding certificates.

Current progress

1. Generated key-pairs:

$ botan3 keygen --algo="ML-KEM" --params="ML-KEM-1024" > prkey-kem.pem
$ botan3 keygen --algo="ML-DSA" --params="ML-DSA-87" > prkey-dsa.pem
$ botan3 keygen --algo="ML-DSA" --params="ML-DSA-8x7" > prkey-dsa.pem
$ botan3 pkcs8 --pub-out prkey-kem.pem > pubkey-kem.pem
$ botan3 pkcs8 --pub-out prkey-dsa.pem > pubkey-dsa.pem
$

2. Created CA (self-signed cert) from ML-DSA key-pair:

$ botan3 gen_self_signed prkey-dsa.pem "/CN=ML-DSA-CA" --ca > dsa-ca.pem
$

Problem

Cannot figure out how to create a certificate signed by the above CA for the ML-KEM public key. Would appreciate help.

[randombit]

Currently this is not possible through the command line because the only flow for creating a signed certificate is to first create a PKCS10 request (botan gen_pkcs10) then sign it (botan sign_cert), PKCS10 uses a signature as proof of possession, and ML-KEM cannot sign.

You can create such a certificate using the (quite low level/escape hatch) function X509_CA::make_cert since this doesn't require involving PKCS10.

Can you share how you created these certs using OpenSSL? I though OpenSSL similarly only had a PKCS10->cert flow, at least in the cli.

[mouse07410]

Currently this is not possible through the command line . . .

Respectfully request adding this capability.

Can you share how you created these certs using OpenSSL?

Certainly (assuming the key-pairs and ML-DSA CA cert has been already created):

openssl x509 -new -key prkey-dsa.pem -force_pubkey pubkey-kem.pem \
       -out kem-cert.pem \
       -subj "/CN=PQ_KEM_Entity"  \
       -set_issuer "/CN=Experimental_PQ_CA" \
       -days 360 \
       -extfile <(printf "keyUsage=keyEncipherment\n")

As you see, OpenSSL allows to "force" the pubkey into a cert, bypassing the need for a CSR - as CSR (obviously) is not possible for ML-KEM type of keys that can't perform signing operation.

[mouse07410]

@randombit given the importance of creating certificates for PQ KEM keys, may I ask to prioritize this?

It would be great if Botan had the ability to do that from CLI.

[randombit]

Have the LAMPS drafts even been finalized yet?

[mouse07410]

Have the LAMPS drafts even been finalized yet?

I don't think they've been finalized yet - but doing at least what OpenSSL did to allow creating certificates for ML-KEM keys (and other keys that can't sign data) seems necessary.

[mouse07410]

Any update on this? I'd really love to see Botan CLI supporting an analog of OpenSSL -force_pubkey option.

[reneme]

Currently, there is an ongoing tender from BSI (Projekt 663 - partially in German) that requests an implementation of draft-ietf-lamps-kyber-certificates among other things.

Whoever wins this tender, should likely implement this in the coming months.

[mouse07410]

Currently, there is an ongoing tender from BSI (Projekt 663 - partially in German) that requests an implementation of draft-ietf-lamps-kyber-certificates among other things.

Whoever wins this tender, should likely implement this in the coming months.

One question is - will Botan maintainers be interested in supporting this tender from BSI/Projekt 663? And would "winning this tender" be a required condition for doing this work on Botan library?

[DDvO]

as CSR (obviously) is not possible for ML-KEM type of keys that can't perform signing operation.

This statement is true only in a limited sense, namely when both

• equating CSRs with PKCS#10, in particular ignoring CRMF, and
• following the PKCS#10 implications that such a structure must be self-signed.

Using a more capable CSR format such as CRMF defined in RFC 4211, there are several other options to provide a proper proof of possession (POP) also in case the key pair does not support signatures. They include

• direct POP via a challenge-response exchange before sending out the actual CSR, see e.g., https://www.rfc-editor.org/rfc/rfc9810.html#sect-5.2.8.3.3
• indirect POP via being able to decrypt the new certificate produced by the CA and encrypted with the public key of the requester, see e.g., https://www.rfc-editor.org/rfc/rfc9810.html#sect-5.2.8.3.2

BTW, a CSR that is not properly authenticated, as when simply throwing a PKCS#10 structure over the fence, is not secure. This way, any party can come in (e.g., as a MITM) and obtain a perfectly "valid" bogus certificate for its (adversary) key. Therefore, it is highly recommended to use a proper cert enrollment protocol such as CMP or EST, taking care of the source authentication of the request originator. CMP does support requesting certs for encryption-only keys such as KEM with POP since long, but so far EST and others do not.

[DDvO]

There are meanwhile some suggestions, but not (yet) standards, for how to do a CSR for encryption-only keys that (re-/ab-)use that legacy PKCS#10 format. They include several variants of a new "KEM CSR protocol", all of which

• include in a PKCS#10-style CSR a KEM public key (with two variants for this part) and
• require an indirect POP by the client decrypting the new KEM certificate and returning a hash value of it to the CA.