- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 6 Feb 2013 16:55:02 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: Aymeric Vitte <vitteaymeric@gmail.com>, public-webcrypto-comments@w3.org
On Tue, Feb 5, 2013 at 8:05 AM, Richard Barnes <rbarnes@bbn.com> wrote: > > On Jan 29, 2013, at 3:31 PM, Ryan Sleevi <sleevi@google.com> wrote: > >> On Tue, Jan 29, 2013 at 5:52 AM, Richard Barnes <rbarnes@bbn.com> wrote: >>> >>> On Jan 29, 2013, at 5:42 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote: >> <snip> >>>> Is it foreseen to implement RSA OAEP and Diffie Hellman, or does it exist somewhere ? >>> >>> I'm trying not to write new crypto code for PolyCrypt (I made an exception for GCM). Do you know of JS libraries for OAEP/DH? I was thinking some about doing ECDH with jsbn, but had postponed that because the spec didn't seem entirely clear on that point yet. >> >> Part of the goal of waiting for implementations was getting feedback >> on the spec. >> >> Can you please provide feedback about what you feel is unclear? > > On a closer reading, it looks like the spec is consistent, but maybe not clear. > > As I read the spec, the process for doing ECDH would be as follows: > ----BEGIN----- > var pub = /* get an X9.62 key from somewhere */; > var priv = /* private key, e.g., from GenerateKey */; > var op = window.crypto.deriveKey( > { name: "ECDH", params: { public: pub } }, > priv > ); > ----END----- > > Having see that, it makes sense to me. I've added it to my TODO list for PolyCrypt. But if you grep for "agree" in the spec, there's nothing that tells you that key *agreement* is done through the *derive*Key method. So it might be helpful to have a pointer in that direction. > > On a related note: It seems a little awkward to have the public key represented directly as octets here, when every other public key we use is a Key object. Suggest changing type of EcdhKeyDeriveParams.public to Key. That way I could importKey from SPKI or JWK. You might also want to add an 'x9.62' format to importKey / exportKey, although SPKI is arguable a better format for that sort of thing, since it includes algorithm info. > > --Richard We explicitly removed PKCS#1 from the spec in favour of PKCS#8. I don't see why we'd want to add x9.62 when SPKI is sufficient, and seems entirely inconsistent with the discussion during Lyon.
Received on Thursday, 7 February 2013 00:55:29 UTC