Skip to content

SC-XXX: Permit ML-DSA public keys and signatures in certificates #662

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
e3n0 wants to merge 9 commits into
base: main
Choose a base branch
from
+43 −1
Open

SC-XXX: Permit ML-DSA public keys and signatures in certificates #662

Changes from 4 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
3b85978
Allow ML-DSA-87 keys in certificates.
e3n0 Apr 22, 2026
b2a62b8
Permit ML-DSA-{44,65} keys for subscriber certificates.
e3n0 Apr 22, 2026
137e013
Add callback to 6.1.5 for parameter sets, and remove unused signing a…
e3n0 Apr 22, 2026
df14263
Clarify revision description.
e3n0 Apr 22, 2026
371dd4a
Undo changes to BR header and revision history
e3n0 Apr 23, 2026
d31d7e8
Allow ML-DSA-{44,65,87} parameter sets for CA Key Pairs
e3n0 Apr 23, 2026
a98d49e
Merge branch 'cabforum:main' into main
e3n0 May 6, 2026
676002d
Merge branch 'cabforum:main' into main
geegeea Jun 26, 2026
85f3dde
Remove ML-DSA-65 and only allow pure PQ chains.
geegeea Jun 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 52 additions & 3 deletions docs/BR.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
---
title: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates

subtitle: Version 2.2.6
subtitle: Version 2.2.x
author:
- CA/Browser Forum

date: 31-March-2026
date: XX-XX-2026
Comment thread
e3n0 marked this conversation as resolved.
Outdated

copyright: |
Copyright 2026 CA/Browser Forum
Expand Down Expand Up @@ -161,6 +161,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse
| 2.2.4 | SC096 | Carve-out for DNSSEC verification logging requirements | 2026-01-14 | 2026-02-17 |
| 2.2.5 | SC097 | Sunset all remaining use of SHA-1 signatures in Certificates and CRLs | 2026-02-24 | 2026-02-25 |
| 2.2.6 | SC095 | Clean-up 2025 | 2026-02-27 | 2026-03-31 |
| 2.2.X | SCXXX | Permit ML-DSA public keys and signatures in Certificates | 2026-XX-XX | 2026-XX-XX |
Comment thread
e3n0 marked this conversation as resolved.
Outdated

\* Effective Date and Additionally Relevant Compliance Date(s)

Expand Down Expand Up @@ -2061,6 +2062,14 @@ For ECDSA key pairs, the CA SHALL:

- Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.

For ML-DSA key pairs, the CA SHALL:

- If the key pair is a CA Key Pair, ensure that the key uses the ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19) parameter set.
Comment thread
e3n0 marked this conversation as resolved.
Outdated
- If the key pair is not a CA Key Pair, ensure that the key uses one of the following parameter sets:
- ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17), or
- ML-DSA-65 (OID: 2.16.840.1.101.3.4.3.18), or
- ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).

No other algorithms or key sizes are permitted.

### 6.1.6 Public key parameters generation and quality checking
Expand All @@ -2069,6 +2078,8 @@ RSA: The CA SHALL confirm that the value of the public exponent is an odd number

ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]

ML-DSA: No stipulation.

### 6.1.7 Key usage purposes (as per X.509 v3 key usage field)

Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:
Expand Down Expand Up @@ -2867,7 +2878,7 @@ Table: Permitted `policyQualifiers`

##### 7.1.2.7.11 Subscriber Certificate Key Usage

The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key, an ECC public key, or an ML-DSA public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.

Table: Key Usage for RSA Public Keys

Expand Down Expand Up @@ -2901,6 +2912,20 @@ Table: Key Usage for ECC Public Keys

**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (<https://github.com/cabforum/servercert/issues/384>).

Table: Key Usage for ML-DSA Public Keys

| **Key Usage** | **Permitted** | **Required** |
| ----- | -- | --- |
| `digitalSignature` | Y | MUST |
| `nonRepudiation` | N | -- |
| `keyEncipherment` | N | -- |
| `dataEncipherment` | N | -- |
| `keyAgreement` | N | -- |
| `keyCertSign` | N | -- |
| `cRLSign` | N | -- |
| `encipherOnly` | N | -- |
| `decipherOnly` | N | -- |

##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name

For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements.
Expand Down Expand Up @@ -3379,6 +3404,24 @@ When encoded, the `AlgorithmIdentifier` for ECDSA keys MUST be byte-for-byte ide
- For P-384 keys, `301006072a8648ce3d020106052b81040022`.
- For P-521 keys, `301006072a8648ce3d020106052b81040023`.

##### 7.1.3.1.3 ML-DSA

The CA SHALL indicate an ML-DSA key using one of the following algorithm identifiers below:

- ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17), or
- ML-DSA-65 (OID: 2.16.840.1.101.3.4.3.18), or
- ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).

As described in [Section 6.1.5](#615-key-sizes), ML-DSA CA Key Pairs MUST use the ML-DSA-87 parameter set.

The parameters for ML-DSA keys SHALL be absent. The CA MUST NOT use HashML-DSA; only "pure" ML-DSA is permitted.

When encoded, the AlgorithmIdentifier for ML-DSA keys SHALL be byte-for-byte identical with the following hex-encoded bytes:

- For ML-DSA-44, `300b0609608648016503040311`.
- For ML-DSA-65, `300b0609608648016503040312`.
- For ML-DSA-87, `300b0609608648016503040313`.

#### 7.1.3.2 Signature AlgorithmIdentifier

All objects signed by a CA Private Key MUST conform to these requirements on the use of the `AlgorithmIdentifier` or `AlgorithmIdentifier`-derived type in the context of signatures.
Expand Down Expand Up @@ -3487,6 +3530,12 @@ If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When enc

If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040304`.

##### 7.1.3.2.3 ML-DSA

The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.

If the signing key is ML-DSA-87, the signature algorithm SHALL be id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19). When encoded, the `AlgorithmIdentifier` SHALL be byte-for-byte identical with the following hex-encoded bytes: `300b0609608648016503040313`.

### 7.1.4 Name Forms

This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede these requirements.
Expand Down