Skip to content

Draft SC-XX: Add MLDSA-87 #624

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

Draft
CBonnell wants to merge 5 commits into
base: main
Choose a base branch
from
+42 −1
Draft

Draft SC-XX: Add MLDSA-87 #624

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
63115df
Add MLDSA-87
CBonnell Oct 16, 2025
bad11c0
Fix section number
CBonnell Oct 17, 2025
10d0cf3
Allow only pure MLDSA chains
CBonnell Oct 17, 2025
f6ac0f8
Restrict certification of MLDSA keys to only MLDSA CAs
CBonnell Oct 17, 2025
e00fbe0
Add a missing "an"
CBonnell Oct 18, 2025
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
43 changes: 42 additions & 1 deletion docs/BR.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2012,6 +2012,11 @@ 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:

* Ensure the Key uses one of the following parameter sets:
* 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 @@ -2020,6 +2025,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]

For ML-DSA key pairs: 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 @@ -2817,7 +2824,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 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 @@ -2851,6 +2858,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 @@ -3344,6 +3365,19 @@ 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-87 (OID: 2.16.840.1.101.3.4.3.19).

The parameters for ML-DSA keys SHALL be absent. The CA MUST NOT use HashML-DSA; only "pure" ML-DSA is permitted. Additionally, the CA SHALL NOT use this algorithm if the algorithm identifier of the Certificate's signature algorithm is not ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).

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

* 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 @@ -3442,6 +3476,13 @@ 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.4 ML-DSA

The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used. Additionally, the CA SHALL NOT use this signature algorithm if the algorithm identifier of the public key being certified is not id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19).

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