Key Agreement Support - ECDH-ES

[madaster97]

Please do not report security vulnerabilities here. The Responsible Disclosure Program details the procedure for disclosing security issues.

Thank you in advance for helping us to improve this library! Your attention to detail here is greatly appreciated and will help us respond as quickly as possible. For general support or usage questions, use the Auth0 Community or Auth0 Support. Finally, to avoid duplicates, please search existing Issues before submitting one here.

By submitting an Issue to this repository, you agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

Would you be interested in adding support for ECDH-ES Key Agreement (https://www.w3.org/2009/xmlenc11#ECDH-ES - section 5.6.4 of the xmlenc spec)?

Describe the ideal solution

As a first-pass, I was thinking to do Key Agreement without a Key Wrap. Practically, what this means is that instead of starting with a random bulk encryption key (that you then wrap with a second symmetric key derived from the key agreement - quote), we just use the derived key for the bulk encryption. Thoughts?

Relevant docs imply we just don't use an EncryptedKey element in this case:

When wrapped keys are used, then an EncryptedKey element will appear as a child of a ds:KeyInfo element

There is some precedent for prioritising bare encryption from the key agreement, in that the JWA spec > JWE algs (tangent I know) does the same by making ECDH-ES a Recommended+, but makes ECDH-ES+A128KW only Recommended

Alternatives and current work-arounds

I am just looking to expand from RSA transport into ECDH agreement support in some of my company's products, and I already use this library for testing our RSA support. No real workaround but to add support myself!