-
Notifications
You must be signed in to change notification settings - Fork 204
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
Add support for HKDF when using KeyAgreeRecipientInfo in EnvelopedData #254
Comments
Support tor HKDF is something that would be nice to have. A PR would be welcomed as long as it matches project style and has appropriate test coverage. @YuryStrozhevsky is best to comment on approach but that sounds reasonable to me. |
@gnarea I have inverstigated the question a little. So, in fact there is a place in CMS where you could/should state which KDF you were using - |
@rmhrisk, @YuryStrozhevsky, thank you so much for the prompt and helpful replies!
Good catch! Just to be clear, I think you're referring to RFC 8418 which covers the use of X25519 and X448 in CMS, right? This approach would have the added bonus of helping with #89.
Good point. I missed that.
Me too. I think I'm going to put together a proof of concept so we can have something more concrete to discuss. |
X9.63 is the only KDF supported by EnvelopedData, but I have to use HKDF instead. What's the best way to achieve this?
There's no method or property I can override to use a different function, so I think this can't be implemented without changing PKI.js itself. (I could potentially override
.encrypt()
anddecrypt()
, but I'd end up duplicating an awful lot of code from PKI.js, which wouldn't be a good idea.)I'd be happy to put together a PR to add support for HKDF (and any other KDF), and here's what I have in mind:
Since
KeyAgreeRecipientInfo
doesn't hold any data about the KDF, we'd have to specify the KDF on each call toEnvelopedData.encrypt()
andEnvelopedData.decrypt()
(X9.63 would still be used by default for backwards compatibility). This extra argument could be a function with the signaturekdf(sharedKey: CryptoKey, recipientInfo: KeyAgreeRecipientInfo): Promise<ArrayBuffer>
.How does this sound? I'm also open to a less invasive alternative, if there's one.
The text was updated successfully, but these errors were encountered: