Public Key Infrastructure (PKI)

The Eviden KMS is a full-featured X.509 certificate authority capable of issuing, storing, validating, and revoking certificates for both classical and post-quantum algorithms.

Supported standards

Not supported

The following specifications are not currently implemented:

• Merkle Tree Certificates (IETF draft) — transparency-based certificate format.
• Composite Certificates (draft-ietf-lamps-pq-composite-sigs / draft-ietf-lamps-pq-composite-kem) — hybrid classical+PQC keys in a single certificate.
• OCSP responder — the KMS does not act as an OCSP responder.
• CRL generation — the KMS does not generate CRLs; it can include crlDistributionPoints pointing to an external CRL.

Certificate export formats

Certificates and their associated private keys can be exported in:

• PEM (.pem) — Base64-encoded, human-readable.
• DER (.der) — Binary ASN.1 encoding.
• PKCS#12 (.p12 / .pfx) — Bundled certificate + private key, password-protected.

Post-quantum algorithms

Algorithm identifiers (OIDs)

ML-DSA — signing (RFC 9881, FIPS 204)

SLH-DSA — signing (RFC 9909, FIPS 205)

ML-KEM — key encapsulation (RFC 9935, FIPS 203)

Key usage requirements

ML-DSA and SLH-DSA (signing algorithms)

Per RFC 9881 §5 and RFC 9909 §6:

• The keyUsage extension MUST be present and MUST be critical.
• It MUST include digitalSignature.
• For CA certificates: keyCertSign and cRLSign are added.

X509v3 Key Usage: critical
    Digital Signature

ML-KEM (key encapsulation algorithm)

Per RFC 9935 §5:

• The keyUsage extension MUST be present and MUST be critical.
• It MUST contain keyEncipherment and MUST NOT contain any other bit.

X509v3 Key Usage: critical
    Key Encipherment

Generating certificates with the CLI

Self-signed ML-DSA-44 certificate

ckms certificates certify \
  --generate-key-pair \
  --algorithm ml-dsa-44 \
  --subject-name "CN=My ML-DSA CA,O=Acme,C=FR" \
  --days 365

The server will:

1. Generate an ML-DSA-44 key pair.
2. Issue a self-signed X.509 v3 certificate.
3. Automatically add a critical keyUsage extension with digitalSignature (per RFC 9881).
4. Return the certificate identifier.

CA-issued ML-KEM-512 certificate (RFC 9935)

First create an ML-DSA-44 CA:

# Step 1: create the CA certificate (self-signed ML-DSA-44)
CA_CERT_ID=$(ckms certificates certify \
  --generate-key-pair \
  --algorithm ml-dsa-44 \
  --subject-name "CN=PQC Root CA,O=Acme,C=FR" \
  --days 3650 \
  | grep "Certificate ID" | awk '{print $NF}')

# Retrieve the CA private key ID from the certificate attributes
CA_SK_ID=$(ckms certificates export \
  --certificate-id "$CA_CERT_ID" \
  --output-format json-ttlv \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(next(l['LinkedObjectIdentifier'] for l in d.get('Link',[]) if l['LinkType']=='PrivateKeyLink'))")

Then issue an ML-KEM-512 leaf certificate signed by the CA:

# Step 2: create an ML-KEM-512 leaf certificate signed by the CA
ckms certificates certify \
  --generate-key-pair \
  --algorithm ml-kem-512 \
  --subject-name "CN=ML-KEM-512 Leaf,O=Acme,C=FR" \
  --issuer-private-key-id "$CA_SK_ID" \
  --issuer-certificate-id "$CA_CERT_ID" \
  --days 365

The server will:

1. Generate an ML-KEM-512 key pair.
2. Issue an X.509 certificate signed by the ML-DSA-44 CA.
3. Automatically add a critical keyUsage extension with keyEncipherment only (per RFC 9935).

SLH-DSA-SHA2-128s self-signed certificate

ckms certificates certify \
  --generate-key-pair \
  --algorithm slh-dsa-sha2-128s \
  --subject-name "CN=SLH-DSA Test,O=Acme,C=FR" \
  --days 365

RSA or EC self-signed certificate

# RSA 4096
ckms certificates certify \
  --generate-key-pair \
  --algorithm rsa4096 \
  --subject-name "CN=RSA CA,O=Acme,C=FR" \
  --days 365

# NIST P-256
ckms certificates certify \
  --generate-key-pair \
  --algorithm nist-p256 \
  --subject-name "CN=EC CA,O=Acme,C=FR" \
  --days 365

Verifying certificates with OpenSSL 3.5+

OpenSSL 3.5+ supports all NIST PQC algorithms. Use the following commands to inspect and verify PQC certificates:

# Inspect the certificate
openssl x509 -text -noout -in ml-dsa-cert.pem

# Verify a leaf certificate against a CA certificate
openssl verify -CAfile ca-cert.pem leaf-cert.pem

Using the Web UI

The Eviden KMS Web UI exposes certificate generation through the Certificate Issuance and Renewal page at /ui/certificates/certs/certify.

• Select "4. Generate New Keypair".
• Choose an algorithm from the Key Algorithm dropdown (e.g. ML-DSA-44 (PQC), ML-KEM-512 (KEM), RSA-4096, NIST-P256).
• Enter a subject name.
• Optionally provide issuer key and certificate IDs for CA-signed certificates.

Cross-algorithm PKI

RFC 9881 and RFC 9935 explicitly support cross-algorithm PKI: the CA signing key does not need to match the subject key algorithm.

Examples of supported combinations:

Certificate lifecycle

All standard KMIP certificate lifecycle operations work with certificates:

Revocation handling

CRL distribution points

To include a CRL distribution point in a certificate, add a crlDistributionPoints entry in the extension config file passed via --certificate-extensions:

[ v3_ext ]
crlDistributionPoints=URI:http://ca.example.com/crl.pem

Authority Information Access (AIA)

The AIA extension (authorityInfoAccess, OID 1.3.6.1.5.5.7.1.1) can be added via the extension config file to point to an OCSP responder or CA issuer:

[ v3_ext ]
authorityInfoAccess=OCSP;URI:http://ocsp.example.com/,caIssuers;URI:http://ca.example.com/ca.crt

No Revocation Available (id-ce-noRevAvail, RFC 9608)

For self-signed certificates (no issuer key provided) that do not carry a CRL distribution point, the KMS automatically adds the id-ce-noRevAvail extension (OID 2.5.29.56, RFC 9608 §2). This signals to relying parties that no revocation information is available for this certificate, and that they should not reject it for lack of a CRL or OCSP response.

This behavior applies to all algorithms (RSA, EC, ML-DSA, SLH-DSA, …), not only PQC.

When validating a chain, the KMS skips CRL fetching for any certificate that carries this extension.