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

Reviving this issue based on today's discussion - do we believe that key attributes should also be per-origin (as Ryan suggested for key identifiers)? How should the gettability and settability of key properties be affected by contextual limits such as private browsing?

My view - I think that exposing attributes as being associated to keys is valuable - it keeps the API simple while also allowing user agents to make choices that make the most sense for a given platform (with WebStorage or IndexedDB being one such choice). It also seems to be the only way to support setting of attributes that apply across origins.

Thoughts?

-----Original Message-----
From: David Dahl [mailto:ddahl@mozilla.com] 
Sent: Wednesday, August 8, 2012 10:05 AM
To: Ryan Sleevi
Cc: Harry Halpin; Web Cryptography Working Group; Vijay Bharadwaj; Mitch Zollinger
Subject: Re: crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]

I probably should have said "potential" privacy issues. Perhaps it is a non-issue - now that I really think it through, and I imagine the key will still work even without access to the custom attrs.  

Cheers,

David
----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: "Harry Halpin" <hhalpin@w3.org>, "Web Cryptography Working Group" <public-webcrypto@w3.org>, "Vijay Bharadwaj"
> <Vijay.Bharadwaj@microsoft.com>, "Mitch Zollinger" 
> <mzollinger@netflix.com>
> Sent: Wednesday, August 8, 2012 11:58:41 AM
> Subject: Re: crypto-ISSUE-17: Define the scope and API for custom key 
> attributes [Web Cryptography API]
> 
> On Wed, Aug 8, 2012 at 7:56 AM, David Dahl <ddahl@mozilla.com> wrote:
> > 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.
> 
> It's not clear what privacy concerns you're talking about?
> 
> >
> > 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 Tuesday, 14 August 2012 16:30:33 UTC