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 Wednesday, 8 August 2012 17:05:02 UTC