Re: crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]

On Tue, Aug 7, 2012 at 8:43 PM, Harry Halpin <hhalpin@w3.org> wrote:
> On 08/06/2012 07:31 AM, Ryan Sleevi wrote:
>>
>> On Sun, Aug 5, 2012 at 10:26 PM, Web Cryptography Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>>
>>> crypto-ISSUE-17: Define the scope and API for custom key attributes [Web
>>> Cryptography API]
>>>
>>> http://www.w3.org/2012/webcrypto/track/issues/17
>>>
>>> Raised by: Ryan Sleevi
>>> On product: Web Cryptography API
>>>
>>> During the July Face-to-Face, vgb proposed a definition of key attributes
>>> grouped into three categories - functional, advisory/supplementary, and
>>> scope.
>>>
>>> Of these, only functional attributes (such as the algorithm family, size,
>>> usage) were seen as immutable attributes. Advisory/supplementary and scope
>>> represent potentially mutable attributes for an application. Some may be
>>> provided, but not enforced, by the user agent, whereas others may be wholly
>>> defined and enforced by the underlying application.
>>>
>>> For attributes defined by the application, the question is whether to
>>> define a custom storage mechanism on the Key object, or whether they should
>>> be implemented by applications via existing web platform APIs. An example of
>>> an existing API might be utilizing localStorage (
>>> http://www.w3.org/TR/webstorage/ ) or IndexedDB (
>>> http://www.w3.org/TR/IndexedDB/ ) to associate attributes with the key,
>>> using the Key's ID as a key with the underlying storage mechanism.
>>>
>>> Arguments In Favor:
>>>   - It tightly couples supplementary attributes with Keys, allowing
>>> pre-provisioned Keys to have pre-provisioned attributes exposed via the API.
>>>   - Clearing the IndexedDB or Web Storage will not erase
>>> application-critical attributes for keys.
>>>
>>> Arguments Against:
>>>   - It represents yet-another-Key-Value-storage mechanism, except this
>>> one tightly coupled to Keys
>>>
>>>
>>>
>>>
>> My preference is to leave the storage of these attributes up to the
>> application, using either Web Storage or IndexedDB.
>>
>> If defining a custom user agent that is robust enough to support
>> pre-provisioned keys, it should be possible to define pre-provisioned
>> IndexedDB values that are keyed off the... key.
>>
>> Considering the existing platform fragmentation between Web Storage,
>> IndexedDB, and Web SQL, it seems very undesirable to introduce
>> yet-another-key-value store.
>
>
> Agreed strongly here re yet another storage, but we *do* need to safely
> store key material persistently, and I'm wondering about finger-printing and
> other security concerns.

I think there may have been a miscommunication.

Yes, I'm still proposing a unique *key* storage that the browser will
be responsible for. Perhaps the confusion was the use of "key value
store", which was just to express the arbitrary association of string
keys (not Key keys, but like "startDate" or "endDate" string keys).

What I was specifically asking about was custom attributes (eg: the
Netflix custom ID) for keys. During our face-to-face, we discussed a
desire to store application-specific attributes. The question is
whether the Key object should have such attributes.

This is http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-Key-userAttributes

>
>  Yet would not there be problems, as you noted, I wonder if there is the
> ability to actually directly store custom key attributes in the underlying
> browser code that can already stores keys (i.e. JWK/ASN.1 format
> extensibility being another closely related question) and thus avoid a new
> storage mechanism while avoiding an existing non-localStorage/IndexedDB? Or
> if we want to use WebStorage to store keys, has the security community
> actually looked in detail at whether or not WebStorage actually
> safe/isolated enough for persistent custom attributes for keys?

I don't think the JWK/ASN.1 question is related. Storage will be
implementation dependent, regardless of how it is expressed to the
application.

>
> We can punt this question to the HTML WG if needed, not sure of answer
> myself. t

I don't think punting is necessary, but perhaps I misunderstood?

Received on Wednesday, 8 August 2012 16:58:36 UTC