Skip to content

Adds support for post-quantum ML-DSA algorithms #682

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
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Adds support for post-quantum ML-DSA algorithms #682

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
67 changes: 52 additions & 15 deletions schema/jsf-0.82.schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
"$id": "http://cyclonedx.org/schema/jsf-0.82.schema.json",
"type": "object",
"title": "JSON Signature Format (JSF) standard",
"$comment" : "JSON Signature Format schema is published under the terms of the Apache License 2.0. JSF was developed by Anders Rundgren ([email protected]) as a part of the OpenKeyStore project. This schema supports the entirely of the JSF standard excluding 'extensions'.",
"$comment" : "JSON Signature Format schema is published under the terms of the Apache License 2.0. JSF was developed by Anders Rundgren ([email protected]) as a part of the OpenKeyStore project. This schema extends the JSF standard to include post-quantum algorithms (ML-DSA) following NIST FIPS 204, excluding 'extensions'.",
"definitions": {
"signature": {
"type": "object",
Expand All @@ -15,7 +15,7 @@
"signers": {
"type": "array",
"title": "Signature",
"description": "Unique top level property for Multiple Signatures. (multisignature)",
"description": "Unique top level property for Multiple Signatures. (multisignature). Can include both classical and post-quantum signatures.",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Question: Ideally, this shouldn't be allowed, since it creates a weaker link. Perhaps this is needed to allow everyone to upgrade?

Copy link
Contributor

Choose a reason for hiding this comment

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

The semantics of multi classical/pq signatures will commonly be to require that both validate successfully, to avoid the weaker link.

"items": {"$ref": "#/definitions/signer"}
}
}
Expand All @@ -26,14 +26,14 @@
"chain": {
"type": "array",
"title": "Signature",
"description": "Unique top level property for Signature Chains. (signaturechain)",
"description": "Unique top level property for Signature Chains. (signaturechain). Chain can include both classical and post-quantum signatures following NIST FIPS 204 standards.",
"items": {"$ref": "#/definitions/signer"}
}
}
},
{
"title": "Signature",
"description": "Unique top level property for simple signatures. (signaturecore)",
"description": "Unique top level property for simple signatures. (signaturecore). Supports both classical and post-quantum algorithms including ML-DSA variants.",
"$ref": "#/definitions/signer"
}
]
Expand All @@ -52,7 +52,7 @@
{
"type": "string",
"title": "Algorithm",
"description": "Signature algorithm. The currently recognized JWA [RFC7518] and RFC8037 [RFC8037] asymmetric key algorithms. Note: Unlike RFC8037 [RFC8037] JSF requires explicit Ed* algorithm names instead of \"EdDSA\".",
"description": "Signature algorithm. The currently recognized JWA [RFC7518] and RFC8037 [RFC8037] asymmetric key algorithms, plus post-quantum algorithms. Note: Unlike RFC8037 [RFC8037] JSF requires explicit Ed* algorithm names instead of \"EdDSA\". Three post-quantum ML-DSA algorithms have been added following NIST FIPS 204 standardization.",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Question: Should the description be enhanced to steer the users towards the new algorithms? Or should it remain this way and unopinionated?

"enum": [
"RS256",
"RS384",
Expand All @@ -67,7 +67,10 @@
"Ed448",
"HS256",
"HS384",
"HS512"
"HS512",
"ML-DSA-44",
"ML-DSA-65",
"ML-DSA-87"
]
},
{
Expand All @@ -81,49 +84,50 @@
"keyId": {
"type": "string",
"title": "Key ID",
"description": "Optional. Application specific string identifying the signature key."
"description": "Optional. Application specific string identifying the signature key. Can reference both classical and post-quantum keys."
},
"publicKey": {
"title": "Public key",
"description": "Optional. Public key object.",
"description": "Optional. Public key object. Supports classical key types (EC, RSA, OKP) and post-quantum key types (PQ) for ML-DSA algorithms.",
"$ref": "#/definitions/publicKey"
},
"certificatePath": {
"type": "array",
"title": "Certificate path",
"description": "Optional. Sorted array of X.509 [RFC5280] certificates, where the first element must contain the signature certificate. The certificate path must be contiguous but is not required to be complete.",
"description": "Optional. Sorted array of X.509 [RFC5280] certificates, where the first element must contain the signature certificate. The certificate path must be contiguous but is not required to be complete. Certificates may contain post-quantum public keys following NIST standards.",
"items": {
"type": "string"
}
},
"excludes": {
"type": "array",
"title": "Excludes",
"description": "Optional. Array holding the names of one or more application level properties that must be excluded from the signature process. Note that the \"excludes\" property itself, must also be excluded from the signature process. Since both the \"excludes\" property and the associated data it points to are unsigned, a conforming JSF implementation must provide options for specifying which properties to accept.",
"description": "Optional. Array holding the names of one or more application level properties that must be excluded from the signature process. Note that the \"excludes\" property itself, must also be excluded from the signature process. Since both the \"excludes\" property and the associated data it points to are unsigned, a conforming JSF implementation must provide options for specifying which properties to accept. This applies to both classical and post-quantum signatures.",
"items": {
"type": "string"
}
},
"value": {
"type": "string",
"title": "Signature",
"description": "The signature data. Note that the binary representation must follow the JWA [RFC7518] specifications."
"description": "The signature data encoded as base64url without padding. Encoding standards: (1) Classical algorithms (RS256, ES256, Ed25519, etc.): Follow JWA [RFC7518] specifications for signature serialization. (2) Post-quantum algorithms (ML-DSA-44, ML-DSA-65, ML-DSA-87): Follow NIST FIPS 204 standard for ML-DSA signature encoding."
Copy link
Contributor Author

Choose a reason for hiding this comment

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

encoded as base64url without padding - could this requirement be perceived as a breaking change for existing classical algorithms?

}
}
},
"keyType": {
"type": "string",
"title": "Key type",
"description": "Key type indicator.",
"description": "Key type indicator. 'PQ' indicates post-quantum algorithms following NIST FIPS 204 standards, specifically ML-DSA algorithms.",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this enough? Or should we expand the semantics for all key types?

"enum": [
"EC",
"OKP",
"RSA"
"RSA",
"PQ"
]
},
"publicKey": {
"title": "Public key",
"description": "Optional. Public key object.",
"description": "Optional. Public key object. Supports classical key types (EC, RSA, OKP) and post-quantum key types (PQ) for ML-DSA algorithms.",
"type": "object",
"required": [
"kty"
Expand Down Expand Up @@ -233,8 +237,41 @@
}
}
}
},
{
"if": {
"properties": { "kty": { "const": "PQ" } }
},
"then": {
"required": [
"kty",
"alg",
"x"
],
"additionalProperties": false,
"properties": {
"kty": {
"$ref": "#/definitions/keyType"
},
"alg": {
"type": "string",
"title": "Algorithm",
"description": "Post-quantum algorithm identifier.",
"enum": [
"ML-DSA-44",
"ML-DSA-65",
"ML-DSA-87"
]
},
"x": {
"type": "string",
"title": "Public Key",
"description": "ML-DSA public key data encoded as base64url without padding, following NIST FIPS 204 specification for the corresponding algorithm variant."
}
}
}
}
]
}
}
}
}