Re: Scope of key discovery draft

On Dec 10, 2012, at 3:35 PM, Ryan Sleevi wrote:

> On Mon, Dec 10, 2012 at 3:28 PM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Dec 10, 2012, at 3:23 PM, Acar, Tolga wrote:
>> 
>>> One aspect: exposure of raw key material in IndexedDB instead of a Key object that may not be extractable.
>> 
>> A Key object with "extractable=false" can be stored in IndexedDB without exposing the raw key material. What is stored in IndexedDB is effectively a *reference* to the key material, not the raw key material itself.
>> 
>> Perhaps some clarification of this is required ? Whatever kind of Key object you have, storing and retrieving it to/from IndexedDB should not pose any additional security risks, in terms of exposing the key.
>> 
>> …Mark
>> 
> 
> Thanks Mark for beating me to this.
> 
> I'm torn on the clarifying text, because for 'implementors' it should
> be 'obvious' (in the same way that Blob/File/ArrayBuffer structured
> cloning does not require copying the actual data into IndexedDB), but
> for potential users of the API, this may be ambiguous.
> 
> I'll see about how this can be made clearer, but I'm generally
> antagonistic towards over-clarification, since 'guidance' is often
> mis-interpreted as normative 'requirements', leading to all sorts of
> bad behaviour.
> 
> For example, a user agent *could* decide to store the cryptographic
> material in the same representation of IndexedDB, if it so wanted -
> but by virtue of structured clone, it MUST always return a Key object
> when that key/value pair is retrieved, and the returned Key must
> preserve the same exportability semantics as what was put in. Meaning
> there's no way for client JS to get the data 'out', even if it's
> "right there"

Where this gets slightly tricky is that implementing "exportable=false" should mean slightly more than just "you can't use the WebCrypto export API to get the raw keying material". It should mean that reasonable care has been taken to make it impossible for the Javascript code to get the raw keying material. Put another way, there's no point in the exportable attribute if it can be trivially defeated with some (pure JS) workaround.

This is the converse of clarifying for users that storing in IndexedDB doesn't change the accessibility of the key material: it needs to be clear to implementers that if they support "exportable=false" they're making some kind of promise about what they do with the key, and their implementation of IndexedDB and structured clone needs to consider this.

[I know that didn't help in terms of finding actual words for the spec … sorry]

…Mark

> 
>>> 
>>> - Tolga
>>> 
>>>> -----Original Message-----
>>>> From: Mark Watson [mailto:watsonm@netflix.com]
>>>> Sent: Monday, December 10, 2012 2:28 PM
>>>> To: Acar, Tolga
>>>> Cc: public-webcrypto@w3.org Group
>>>> Subject: Re: Scope of key discovery draft
>>>> 
>>>> 
>>>> On Dec 10, 2012, at 1:52 PM, Acar, Tolga wrote:
>>>> 
>>>>> Thanks, Mark. I have another use case of named origin-specific keys.
>>>>> 
>>>>> The only difference, as the name above suggests, is that these keys are not
>>>> pre-provisioned; they are created on-demand for later use. This is similar to
>>>> native crypto API behavior. A key is created and stored if it doesn't exist, and
>>>> is retrieved if it is already there.
>>>> 
>>>> What aspect of your use-case is not covered by storing the Key object in
>>>> IndexedDB ?
>>>> 
>>>> ...Mark
>>>> 
>>>>> 
>>>>> - Tolga
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Mark Watson [mailto:watsonm@netflix.com]
>>>>>> Sent: Monday, December 10, 2012 1:43 PM
>>>>>> To: public-webcrypto@w3.org Group
>>>>>> Subject: Scope of key discovery draft
>>>>>> 
>>>>>> All,
>>>>>> 
>>>>>> On the call, I presented the key discovery draft as containing only
>>>>>> the material on "named origin-specific pre-provisioned keys", but it
>>>>>> could be extended, if there was support, to other kinds of key discovery.
>>>>>> 
>>>>>> Ryan voiced the opinion that the scope of the document should be
>>>>>> restricted to just this case and that other cases should be addressed
>>>>>> in other documents.
>>>>>> 
>>>>>> I would like to know if there are any other opinions ?
>>>>>> 
>>>>>> If not, does anyone have a good suggestion for a shorter name ?
>>>>>> "WebCrypto: Discovery of named origin-specific pre-provisioned keys"
>>>>>> is a bit of a mouthful.
>>>>>> 
>>>>>> ...Mark
>>>>> 
>>> 
>>> 
>> 
>> 
>

Received on Monday, 10 December 2012 23:51:01 UTC