Re: Scope of key discovery draft

On Mon, Dec 10, 2012 at 3:43 PM, Acar, Tolga <tolga.acar@intel.com> wrote:
> Yes, a clarification would be useful. So far, I've been under the impression that IndexedDB can only store plaintext key material - clearly not accurate based on Mark's answer.
>
> In terms of how a Key reference is stored and interpreted by a particular implementation is a detail buried somewhere, and I am not sure if somewhere is in this standard: this is an API standard, and probably should not dictate how stored keys must look like as long as the API can use them.

It is every bit intentional (and indeed, core) that this does not
dictated how keys are stored by an implementation. This is specified
in the "Introduction" (
https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html#introduction
) and expanded upon in "Security Considerations" (
https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html#security-developers
)

> Having that said, this becomes problematic in cross-crypto provider case; but I think that is not a problem to address in this cut. OTOH, this makes me worried about developers accessing the DB directly bypassing the API - yes, we can recommend "don't do it", but instead always talk to the API.
>
> - Tolga

I'm not sure what you mean about "accessing the DB directly, bypassing the API"

The only way they can access IndexedDB is via the IndexedDB API.

The IndexedDB API dictates that values retrieved follow the structured
clone algorithm -
http://www.w3.org/TR/2012/WD-IndexedDB-20120524/#value-construct

Ergo, there's nothing special in this API, beyond defining the
structured clone for Keys, that ensures storing a Key will always
return a Key (that is equivalent in every way dictated by the
structured clone algorithm)

An conforming user agent that stored keys in a crypto provider could,
for example, store within the IndexedDB a serialized form of data used
to represent the Key object - such as a string that contained the
crypto-provider implementation, the key id, and the necessary
attributes that MUST be restorable upon resumption from structured
clone.

>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, December 10, 2012 3:35 PM
>> To: Mark Watson
>> Cc: Acar, Tolga; public-webcrypto@w3.org Group
>> Subject: Re: Scope of key discovery draft
>>
>> 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"
>>
>> >>
>> >> - 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:49:56 UTC