Skip to content
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

Open
simoneonofri opened this issue Nov 17, 2024 · 11 comments
Assignees
Milestone

Comments

@simoneonofri
Copy link

simoneonofri commented Nov 17, 2024

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:

  • 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:

From IETF 121 Dublin with <3

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

@plehegar
Copy link
Member

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

@dontcallmedom
Copy link
Member

(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
Copy link
Author

@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
Copy link

jaromil commented Nov 19, 2024

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
Copy link
Member

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
Copy link

ve7jtb commented Nov 19, 2024 via email

@martinthomson
Copy link
Member

@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
Copy link

frumioj commented Nov 20, 2024

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
Copy link
Member

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
Copy link

d3e3e3 commented Nov 21, 2024

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
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

8 participants