Workshop "Post Quantum Cryptography for XML Signature and XML Encryption Suites"

[simoneonofri]

A workshop for Post Quantum Cryptography for XML Signature and XML Encryption Suites to discuss experiences and the next steps.

Problem:

• XML Signature and XML Encryption need support for new Post-Quantum algorithms.

Use cases and requirements:

• There is an issue regarding using SAML, e.g., in the US public sector and institutional environments, with various cryptographic requirements.
• SAML's group is no longer available. However, SAML uses XMLDSign for signatures, and we can work on this.
• Given the use-case of SAML, a potential solution would be to migrate to other technology.
• But, as the issue is on XML Signature and Encryption, people highlighted that this is also used in other contexts, so the scope is broader

Investigation:

• During some conversations, we noticed that not all people consider Post-Quantum Cryptography for integrity an imminent threat.
• Similar need for updates happened in the past, and a workshop in 2007 was organized to facilitate the discussion.
• We also have the RFC 9231 to update the XML Signature and Encryption algorithms XML Security URIs registry.
• There is already some research on Post-quantum XML and SAML Single Sign-On.

From IETF 121 Dublin with <3

[cc'ing @twhalen, @plehegar, @ianbjacobs, @martinthomson, @mnot, @OR13, @pamelatech, @ve7jtb, @hlflanagan]

[plehegar]

For completeness: do we need to consider Web Crypto as part of this workshop?

[dontcallmedom]

(if this were expanded to consider Web Crypto, note that there are practical questions emerging from PQ support in WebRTC as well - in particular, around the size of keys required by PQ algorithms IIUC)

[simoneonofri]

@plehegar @dontcallmedom thank you for the pointers, if there is this kind of interest, this can be more a Post-Quantum Web/Quantum Safe Web.

@iherman We have also crypto algorithms in VC, even if there is already exist a CG Report Draft about it

I am adding to the discussion @souppaya, as we already discussed it in person, who have a broader point of view.

[jaromil]

Good point, @dontcallmedom. My wild guess is that the best candidate algorithm to adopt PQC in webRTC is FALCON. It is not yet standardized as a FIPS-, but it is a NIST competition winner fine-tuned to save bandwidth.

Another thing to consider is that, wherever BBS is used, a usable PQC replacement with zero-knowledge capabilities and reasonable sizes hasn't been discovered yet. PQC transition is important for long-term BBS credentials because BBS is based on EC cryptography (BLS12-381) and as such is an easy prey of quantum-based cryptographic attacks.

[martinthomson]

It's not clear to me why a workshop is needed here. There is ongoing work in the IETF to describe both "pure" PQ signature schemes as well as hybrid classical-PQ signature schemes for things like CMS, JOSE, and COSE. There are arguments for either or both that are playing out there. The requirements for XMLDSig are likely entirely consistent with these requirements.

The debate seems endless, but it will eventually resolve. A workshop in the W3C is unlikely to add clarity to the overall situation. It might even make things worse.

(As an aside, encryption is a much easier debate. For that, hybrids are already strongly recommended and somewhat more urgent given store-and-decrypt-later attacks. Again, those decisions can and should follow the decisions that the IETF makes.)

Web Crypto is separable. It also has a much easier answer: the algorithms that the IETF chooses to bless probably need to be supported. If there are hybrids needed, then a hybrid scheme can always be assembled from parts. Of course, if the hybrids enter wide use, there's a simple discussion to be had about whether to provide support for those schemes directly.

There's a whole separate thread about the use of a CRPQ to attack VCs or selective disclosure systems like BBS or other zero-knowledge proof systems. That's an area that need cryptologic research; I'm not aware of anything that is even remotely ready for standardization in that area (though I'm not a cryptographer).

[ve7jtb]

Hi Martin, The question is not really what algs, but if the W3C XML dsig https://www.w3.org/TR/xmldsig-core1/ and https://www.w3.org/TR/xmlenc-core1/ should be updated to be able to use newer algs. Currently for signing the options are: DSA RSA (PKCS#1 v1.5) ECDSA I think the last person to touch this was Donald Eastlake back around 2013. So the first question is who if anyone is going to be responsible for updating the specs once we have algs? We have SAML as a major consumer of this. Any updates to SAML implementations will take time to work there way out into deployments. There are other specifications that don’t have alternatives, such as switching to OpenID Connect. I don’t know what a workshop is going to tell us, other than that no one is likly working on a PQ plan for all the XML-based applications. John B.

…

On Nov 19, 2024, at 6:37 PM, Martin Thomson ***@***.***> wrote: It's not clear to me why a workshop is needed here. There is ongoing work in the IETF to describe both "pure" PQ signature schemes as well as hybrid classical-PQ signature schemes for things like CMS, JOSE, and COSE. There are arguments for either or both that are playing out there. The requirements for XMLDSig are likely entirely consistent with these requirements. The debate seems endless, but it will eventually resolve. A workshop in the W3C is unlikely to add clarity to the overall situation. It might even make things worse. (As an aside, encryption is a much easier debate. For that, hybrids are already strongly recommended and somewhat more urgent given store-and-decrypt-later attacks. Again, those decisions can and should follow the decisions that the IETF makes.) Web Crypto is separable. It also has a much easier answer: the algorithms that the IETF chooses to bless probably need to be supported. If there are hybrids needed, then a hybrid scheme can always be assembled from parts. Of course, if the hybrids enter wide use, there's a simple discussion to be had about whether to provide support for those schemes directly. There's a whole separate thread about the use of a CRPQ to attack VCs or selective disclosure systems like BBS or other zero-knowledge proof systems. That's an area that need cryptologic research; I'm not aware of anything that is even remotely ready for standardization in that area (though I'm not a cryptographer). — Reply to this email directly, view it on GitHub <#484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPQJ2CUOS7QNI72XXLOWL2BOVTNAVCNFSM6AAAAABR53VJMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHAYDGOJXG4>. You are receiving this because you were mentioned.

[martinthomson]

@ve7jtb, that was exactly my point. I don't think that it's useful to run the same debate as is happening in the IETF for these formats. Let the IETF make good choices (and hopefully publish their rationale) before making the call. As I said, I can't conceive of any reason that XML would need to differ from JSON or CBOR security formats when it comes to signing. Running the same debate in parallel is only likely to produce worse outcomes.

[frumioj]

Yes, as @ve7jtb says:

1. We need whatever updates are needed to support both hybrids and "pure" PQC algorithms for W3C XML DigSig/Encryption specifications
2. SAML specifications would need an update to use the new W3C XML DigSig/Encryption specs.

Since there are no W3C or OASIS groups currently doing this work, how does that move forward?

[plehegar]

For XML DigSig, it seems to me that updating RFC 9231 might be enough for XML Signature. The 2013 REC points to RFC6931 and we could look into refreshing the normative references. XML Encryption does not point anywhere for new algorithms, so that one might need a deeper revision. Reaching out to Donald Eastlake would help here.

[d3e3e3]

Hi, There is actually a possible update to RFC 9231 in https://datatracker.ietf.org/doc/draft-eastlake-rfc9231bis-xmlsec-uris/ I would be happy to add algorithms to it.

[simoneonofri]

Thank you all for your comments.

@d3e3e3 thank you for the availability of XML Sig with the RFC 2931bis

In general, for XML Enc, since there are no references to RFC 4051, 6931, or 9231, do you think it should be updated, or are there better ways to support new algorithms?