search

WICG / webcrypto-secure-curves

Proposal for the addition of Curve25519 and Curve448 to the Web Cryptography API
https://wicg.github.io/webcrypto-secure-curves/
Other
40 stars 3 forks source link

Importing and exporting raw private keys? #6

Closed twiss closed 2 years ago

twiss commented 2 years ago

I noticed that in Node.js's implementation of EdDSA, there's a nodeEdKeyImportParams.public property, which enables importing both private and public raw keys, while this proposal currently only allows importing raw public keys, consistent with ECDSA and ECDH in the current Web Crypto API. I do think this would be something that's nice to have, though, as well as exporting raw private keys - potentially not just for EdDSA but also ECDSA and ECDH. Perhaps, rather than defining an import parameter, we could define a separate format, e.g. 'rawprivate', that could be used for both import and export. (We could also rename 'raw' to 'rawpublic', depending on whether we care more about internal consistency or consistency with the rest of Web Crypto.)

Alternatively, we could also declare this out of scope and try to add 'rawprivate' to all (relevant) algorithms in Web Crypto more generally, especially since technically speaking, adding a new import format would require monkey-patching importKey(), which is a bit annoying (but not insurmountable).

@panva, and anyone else that may have an opinion, have any thoughts?

panva commented 2 years ago

I propose to stick to the current scheme. Ignoring the specifics of node's proprietary implementation.

twiss commented 2 years ago

Alright. Are you thinking mostly of consistency, or do you have any specific opposition to importing and exporting raw private keys?

panva commented 2 years ago

Consistency. And I feel like we'd be overstepping our mandate if we did more than just register algorithms and defined their use within the existing framework here. A separate work exploring the possibility of registering new key formats I don't have a problem with.

We lack the historical records, or rather, the time to go through them, to make a call reverting a decision that was surely made for a good reason.

twiss commented 2 years ago

Fair enough.

I don't think there is/was a strong reason for avoiding this, as private key export can be trivially done using jwk. Importing a private key using jwk is less trivial if you don't also have the public key, but importing also seems less sensitive. (I've searched the Web Crypto WG mailing archives and nothing turned up.)

But in any case, I agree we can postpone this and consider it for Web Crypto more generally later.

panva commented 2 years ago

The reluctance of back then only implementers to derive the public key from a private key input is what could have lead to this affordance missing.

You can see something similar with raw EC public key imports where the optional to implement support for compressed public keys is only supported in chromium but lacking in FF and Safari.