Repository navigation
Key Agreement Support - ECDH-ES #120
Description
Activity
I made a plan for a potential PR. How does the below sound?
Let's meet these main requirements of the spec, both for encryption and decryption:
- Key Derivation > ConcatKDF:
https://www.w3.org/2009/xmlenc11#ConcatKDF - Key Agreement > ECDH-ES:
https://www.w3.org/2009/xmlenc11#ECDH-ES - Symmetric Key Wrap >
AES128andAES256(yes I'm ignoringtripledes):https://www.w3.org/2001/04/xmlenc#kw-aes128https://www.w3.org/2001/04/xmlenc#kw-aes256
- Only add Key Wrap / Derivation for ECDH-ES (just to limit scope, if it's easy enough we could add this for RSA too)
For both encryption and decryption, I am pitching that as a first pass we only support wrapped keys. Unwrapped keys are also in the spec, but I think we should choose 1 to start.
For why I chose wrapped keys specifically: see below.
Key Wrap
Since we do NOT already support symmetric key wrap with RSA Key Transport, why add it for ECDH-ES?
This is a grey area in the specs I think (you can do ECDH-ES without a key wrap), but the main difference between RSA Transport and ECDH-ES without Key Wrap is the data flow for the encrypting party. ECDH-ES with key wrap does not have this difference / matches the data flow of RSA Transport without key wrap.
To explain: current state with RSA Transport, the first step is to create a random content encryption key, THEN perform the asymmetric crypto to encrypt the key. In theory implementers could be doing the bulk encryption ahead of the key encryption, or otherwise assuming the content encryption key exists from the get-go.
If you try to use ECDH-ES without a Key Wrap function, the implication is that you're using the derived key as the content encryption key. So now you need to handle waiting to generate / use a content encryption key until AFTER the asymmetric crypto operations. It isn't clear what downsides there are to that approach, but it is a difference that would require more work for those implementing encryption who may be starting from an existing RSA Transport codebase.
Note there is not a major data flow difference for the decryptors in this case: either way you don't get the content decryption key until after the asymmetric crypto is done!
All the above is to say: it would be very nice of those who implement decryption to support a Key Wrap operation, to make the lives of the encryptors easier! There is also far more documentation showing the key wrap pattern, such as this working draft with many examples!
https://www.w3.org/TR/xmlenc-core1-testcases/
Reading that draft is actually what knocked the ideas above out of my head! Specifically this quote made things click (describing the data flow with key wrap in place):
At first the content is encrypted by a random symmetric key
- Key Derivation > ConcatKDF:
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
EncryptedKeyelement in this case: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-ESa Recommended+, but makesECDH-ES+A128KWonly RecommendedAlternatives 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!