Adds support for post-quantum ML-DSA algorithms #682
Conversation
Signed-off-by: Prabhu Subramanian <prabhu@appthreat.com>
| "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.", |
There was a problem hiding this comment.
Question: Ideally, this shouldn't be allowed, since it creates a weaker link. Perhaps this is needed to allow everyone to upgrade?
There was a problem hiding this comment.
The semantics of multi classical/pq signatures will commonly be to require that both validate successfully, to avoid the weaker link.
| "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.", |
There was a problem hiding this comment.
Question: Should the description be enhanced to steer the users towards the new algorithms? Or should it remain this way and unopinionated?
| "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.", |
There was a problem hiding this comment.
Is this enough? Or should we expand the semantics for all key types?
| "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." |
There was a problem hiding this comment.
encoded as base64url without padding - could this requirement be perceived as a breaking change for existing classical algorithms?
Fixes #674
With inspiration from the Node.js PRs and this, this pull request adds three new post-quantum algorithms: "ML-DSA-44", "ML-DSA-65", and "ML-DSA-87" to better future-proof BOM signature validity. The hypothetical but real threat this addresses is that traditional signatures with RSA/ECDSA may become invalid when quantum computers break them.
Following alternative ideas could be considered:
"algorithm": "urn:nist.gov:fips204:ml-dsa-44"instead of simple upper case enum strings. This however is a significant breaking change to replace all existing identifiers in use.signerdefinitionSignature object support
signeras one of the types. A new type calledpostQuantumSignercould be created to extendsignerto capture additional attributes related to PQ algorithms and also to support a broad range of PQ algorithms.Currently, additional properties are disabled for signer. To increase flexibility, this could be enabled.
This PR proposes a simple enhancement to the enum, key type indicators, and validation, making this feature >= 1.7 only without any possibility for backports.
TBD:
Enhancing CBOM to support the corresponding OID values.