Re: Scope of key discovery draft

On Mon, Dec 10, 2012 at 3:53 PM, Acar, Tolga <tolga.acar@intel.com> wrote:
> Thanks, inline.
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, December 10, 2012 3:49 PM
>> To: Acar, Tolga
>> Cc: Mark Watson; public-webcrypto@w3.org Group
>> Subject: 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 API  = Web Crypto API, not indexedDB.
>
>>
>> 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.
> Yes, that is one, but not the only, conforming option. One implementer may choose to store the plaintext key in the DB even when the keyu says not extractable. But, let me not fray the discussion, as I see that Mark brings up the same point in his response.

Here again, the Security Considerations address this -
https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html#security-developers

" For example, a conforming user agent may choose to implement key
storage by storing key material in plain text on device storage.
Although the user agent prevents access to the raw keying material to
web applications, any user with access to device storage may be able
to recover the key."

Received on Tuesday, 11 December 2012 00:00:39 UTC