-
|
I have a question regarding the support plan for PQC (Post-Quantum Cryptography) algorithms in xmlsec. Could anyone answer information on the timeline or any plans to support PQC-based signature algorithms, such as ML-DSA or SLH-DSA, in xmlsec? |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 1 reply
-
|
No plans at all at the moment but I would gladly accept patches :) Given that OpenSSL has EVP interface, it's likely a trivial change. BTW quick search doesn't show any mention of these algorithms in the context of XML signatures / encryption. Are there reserved identifiers (URIs) for these algorithms somewhere already (eg https://www.w3.org/TR/xmldsig-core1/#sec-ECDSA)? Are there any test vectors? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your quick answer. BTW, regarding OpenSSL, the EVP library in version 3.5.0 and above supports ML-DSA and SLH-DSA, utilizing specific identifiers for various key types as follows: These correspond to NIST security levels 2, 3, and 5, respectively, and can be used with the openssl genpkey -algorithm [algorithm name] command-line tool. SLH-DSA (Stateless Hash-based Digital Signature Algorithm, SPHINCS+) SLH-DSA supports various combinations of hash functions and parameter sets according to the NIST standard FIPS 205: The above key types are implemented in OpenSSL's default and FIPS providers and can be utilized for key generation, signing, and verification operations using EVP functions such as EVP_PKEY_CTX_new_from_name() or EVP_PKEY_CTX_new(). BRs, |
Beta Was this translation helpful? Give feedback.
-
Technically "no", in practice custom URIs / identifiers will make it impossible to have interoperability. As I said, likely implementation is not hard. I would be more interested in doing it if there is a standard that can be used by many people. As it stands right now it feels more like a one-off. |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, 2025-12-02 at 06:59 -0800, lsh123 wrote:
> Is it necessary for the public XML signatures URI to include the corresponding URIs in order to support PQC signature algorithms in xmlsec?
Technically "no", in practice custom URIs / identifiers will make it impossible to have interoperability. As I said, **likely** implementation is not hard. I would be more interested in doing it if there is a standard that can be used by many people. As it stands right now it feels more like a one-off.
Note that while algorithms are available and coding will be easy, you
should really work through an standardization process because there are
choices to be made here.
Namely whether to use "pure signatures" or "pre-hashed" signatures.
A lot of the IETF protocols decided not to use HashML-DSA/HashSLH-DSA
(which are the pre-hashed variants) and instead use only pure
signatures, including when the actual signed elements are actually pre-
hashed (see OpenPGP latest draft/rfcs)
Note that if you do not use pre-hashed signatures you need the
signature upfront before you can do any verification with SLH-DSA (the
signature includes data that needs to be included in the internal hash
before the digest on the message can be computed) and for both ML-DSA
and SLH-DSA you need the public key upfront to be able to start the
signature process (there is public key binding in the internal hash).
So ... you should really start (or wait for) a standard that defines
how these signature types are used with XML.
My 2c,
Simo.
…--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
|
Beta Was this translation helpful? Give feedback.
-
|
yeah I agree there should be standardization first, I think "pure signatures" will be problematic for any software that supports "streaming" signatures (xmlsec doesn't support streaming and requires the whole XML file in memory) so likely the standards will include both. |
Beta Was this translation helpful? Give feedback.
-
|
I've added experimental (and non standard) support for Pure ML-DSA to xmlsec-openssl:
A bit of plumbing was needed to add new keys and algos (as usual) but the rest was trivial. I might add SLH-DSA to OpenSSL as well and also support both on GnuTLS (currently some features are missing namely reading pkcs12 files). Based on my experience, I think "pure" versions is a way to go for XML Dsig purposes and it's similar to how other XMLDsig signatures actually operate. There is a downside that pre-signed buffer needs to be in memory but for XMLDSig it is only node (https://www.w3.org/TR/xmldsig-core1/#sec-SignatureGeneration) which is typically pretty small anyway. So it's not a huge downside from my point of view. |
Beta Was this translation helpful? Give feedback.
-
|
PR #1006 adds experimental support for pure SLH-DSA-SHA2-128f |
Beta Was this translation helpful? Give feedback.
-
|
And PR #1012 adds bunch of SLH-DSA-SHA2 variants |
Beta Was this translation helpful? Give feedback.
-
|
There are some URL-s proposed in RFC draft https://www.rfc-editor.org/rfc/rfc9231.html#name-xmss-and-xmssmt |
Beta Was this translation helpful? Give feedback.
-
|
On Thu, 2026-01-22 at 00:01 -0800, Raul Metsma wrote:
There are some URL-s proposed in RFC draft https://www.rfc-editor.org/rfc/rfc9231.html#name-xmss-and-xmssmt
xmlsec should not enable (perhaps not even support) by default XMSS or
LMS as these schemes break catastrophically very easily if implemented
in software. They should only be used with an HSM that handles state in
hardware as the security of the scheme completely depends on
maintaining state associated with the private key. Repeating a single
signature with these schemes means revealing the private key.
Best,
Simo.
…--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
|
Beta Was this translation helpful? Give feedback.
I've added experimental (and non standard) support for Pure ML-DSA to xmlsec-openssl:
A bit of plumbing was needed to add new keys and algos (as usual) but the rest was trivial. I might add SLH-DSA to OpenSSL as well and also support both on GnuTLS (currently some features are missing namely reading pkcs12 files).
Based on my experience, I think "pure" versions is a way to go for XML Dsig purposes and it's similar to how other XMLDsig signatures actually operate. There is a downside that pre-signed buffer needs to be in memory but for XMLDSig it is only node (https://www.w3.org/TR/xmldsig-core1/#sec-Signatu…