-
Notifications
You must be signed in to change notification settings - Fork 47
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.
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
Workshop "Post Quantum Cryptography for XML Signature and XML Encryption Suites" #484
Comments
For completeness: do we need to consider Web Crypto as part of this workshop? |
(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) |
@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. |
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. |
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). |
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.
|
@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. |
Yes, as @ve7jtb says:
Since there are no W3C or OASIS groups currently doing this work, how does that move forward? |
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. |
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. |
A workshop for Post Quantum Cryptography for XML Signature and XML Encryption Suites to discuss experiences and the next steps.
Problem:
Use cases and requirements:
Investigation:
From IETF 121 Dublin with <3
[cc'ing @twhalen, @plehegar, @ianbjacobs, @martinthomson, @mnot, @OR13, @pamelatech, @ve7jtb, @hlflanagan]
The text was updated successfully, but these errors were encountered: