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

A potential compromise might be adding 'DOMString customProps' property to the key object where a JSON string can be stored. This will raise privacy of these properties and we are only adding a single extra string to the key object. 

I think that separately-stored custom properties might cause a kerfuffle for some app devs when a user removes all web storage for the domain and operations potentially fail.

Cheers,

David  

----- Original Message -----
From: "Harry Halpin" <hhalpin@w3.org>
To: "Ryan Sleevi" <sleevi@google.com>
Cc: "Web Cryptography Working Group" <public-webcrypto@w3.org>, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>, "Mitch Zollinger" <mzollinger@netflix.com>
Sent: Tuesday, August 7, 2012 10:43:59 PM
Subject: Re: crypto-ISSUE-17: Define the scope and API for custom key  attributes  [Web Cryptography API]

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.

  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?

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

Received on Wednesday, 8 August 2012 14:56:30 UTC