- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 14 Jun 2012 11:06:29 -0700
- To: David Dahl <ddahl@mozilla.com>
- Cc: Zooko Wilcox-OHearn <zooko@leastauthority.com>, public-webcrypto@w3.org
- Message-ID: <CACvaWvbn3a=3Dd2bNGQrV3sp2zn0EeWPQi7NvWeufnq6-8-4pg@mail.gmail.com>
On Thu, Jun 14, 2012 at 10:07 AM, David Dahl <ddahl@mozilla.com> wrote: > No, I do not think I have ever advocated for the private keying material > to ever be available in raw form. Please refresh my memory where I was > advocating for private keys to be exposed to content. > > David > During our June 4 teleconference, there was the discussion during the Draft API technical discussion about whether keys should be referred to "by data" or "by ID". My understanding of your proposal was that all keys be referenced by raw bytes, which then lead to the discussion that this would necessarily preclude the use of secure elements, and the counter-proposal that all keys could be referred to via handles (eg: JavaScript objects - presumably obtained by IDs but not necessarily so). My intent was not to preclude the use of obtaining key byes from the API - as I think this is a very useful case that MUST be supported if we're to allow web applications to extend/enhance the API - but to simply indicate that not all keys may permit this operation. That is, there's no reason to rule it out, but there's no reason to mandate it either. Have I misunderstood your position and proposal from the June 4 teleconference? It looks like your comments between Virginie's broaching of the topic and Mitch's response on IRC may not have been captured in the minutes. > > ----- Original Message ----- > From: "Ryan Sleevi" <sleevi@google.com> > To: "David Dahl" <ddahl@mozilla.com> > Cc: "Zooko Wilcox-OHearn" <zooko@leastauthority.com>, > public-webcrypto@w3.org > Sent: Thursday, June 14, 2012 11:59:47 AM > Subject: Re: I want to have unsafe key exchange. > > David, > > I must say, your response surprises me. I was under the impression that > just two weeks ago, you were advocating that the keying material always be > available. > > Perhaps you're talking from the perspective of a high-level API, and I'm > thinking from the low-level API? > > Further responses inline. > > On Thu, Jun 14, 2012 at 8:50 AM, David Dahl <ddahl@mozilla.com> wrote: > > > > > > > ----- Original Message ----- > > > From: "Zooko Wilcox-OHearn" <zooko@leastauthority.com> > > > To: public-webcrypto@w3.org > > > Sent: Thursday, June 14, 2012 9:44:42 AM > > > Subject: I want to have unsafe key exchange. > > > > > > > > <snip> > > > So, I don't really understand whether all the discussion of > > > protecting > > > keys and identifying them by key IDs means that the uses I envision > > > -- > > > unprotected keys -- will be unsupported. > > > > > > > Initially, I think this was not a use case that was in mind for the API. > > However, we have discussed a few operations where this would be required > to > > support specific protocols. I think in most cases, we would not want > > developers using this kind of 'the footgun is loaded' operation. > > > > In my view, this has been a core requirement for the API, so I'm surprised > that you see it out of scope. This was also part of the discussion with ekr > about 'safe' operations. > > I see no reason to require that the API MUST NOT be able to expose the > keying material. I also see no reason to require that the MUST expose the > keying material. I think the API MAY expose key material, and that it's > dependent on externalities (eg: how the app created the key, how/where the > key is stored, any relevant security properties the browser imposes, etc). > > > > > > > Will the spec require implementers to offer an API to extract the > > > complete bytes of a private key or symmetric key, and to create a > > > private key or symmetric key from a string of bytes? > > > > > > > As far as symmetric keys are concerned, I have been thinking we would > spec > > out a wrapped key object, with the unwrapping happening out of the > content > > JS scope. With a compelling use-case I can see an API that allows raw key > > material to be generated that is perhaps not persisted and not given any > > kind of ID. Would that satisfy your usage? > > > > I think this is a MUST requirement. Otherwise, the use of a DHE exchange to > negotiate some keying material seems... not at all useful. > > Wrapped keys are only useful if you have a wrapping key. How do you > import/export the wrapping key? For exchange between peers? Between > browsers? > > In practice, requiring key wrapping tends to heavily dilute the 'actual' > value of the API, and in practice (eg: see the PKCS#11 attack papers > previously referenced) may offer little-to-no added security. > > That isn't to say I think key wrapping is useless, simply that it shouldn't > be mandatory. > > > > > > Do you have a use case written down for this kind of operation? > > > > David > > > > >
Received on Thursday, 14 June 2012 18:07:03 UTC