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 all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
63115df
Add MLDSA-87
Oct 16, 2025
bad11c0
Fix section number
Oct 17, 2025
10d0cf3
Allow only pure MLDSA chains
Oct 17, 2025
f6ac0f8
Restrict certification of MLDSA keys to only MLDSA CAs
Oct 17, 2025
e00fbe0
Add a missing "an"
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).

@robstradling robstradling Oct 16, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Microsoft's announcement at the CABForum F2F yesterday said "Mandatory support for ML-DSA-87".

ML-DSA-44 and ML-DSA-65 weren't mentioned at all. I don't know if that implies that the PQC Pilot Program will (1) disallow these parameter sets or (2) permit (but not require) them to be supported.

If 2, then this PR should probably allow them too.

@CBonnell CBonnell Oct 17, 2025

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the call-out on this. I discussed this with the MSFT reps a bit ago and they confirmed that the pilot is limited to MLDSA-87 only at this point. So, I believe this language can stay as-is.

@aarongable aarongable Apr 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving a comment here as welll, since it's not yet clear whether this PR or #662 will be the one that moves forward.

Now that we're making this change due to general preparedness, and not just the Microsoft pilot program, we should allow ML-DSA-44 and ML-DSA-65.


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 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 @@ -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`.

Comment thread
CBonnell marked this conversation as resolved.

### 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