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

I think we agree at least partly - my intention was that attributes created by a given origin should only be visible to that origin. Essentially I'm advocating for the following:

There are two kinds of keys, those created by an origin (origin-specific) and those provisioned out of band (origin-authorized)
- Origin-specific keys (and all their attributes) are only available to the creating origin. If it is desirable to share these with a different origin, then the two origins need to cooperate by providing an export-import flow.
- Origin-authorized keys may be authorized to any origin by an implementation-specific method (requiring user interaction is encouraged). Each such authorized origin can see the key and use it in the same way.

For origin-authorized keys, there are two kinds of attributes:
- Origin-specific attributes are those created by a specific origin. They are only visible to that origin.
- Origin-authorized attributes are those that are provisioned out-of-band (presumably in the same way as the key was). They cannot be modified through the API and are visible to all origins.

In fact, I'm not even sure that origin-specific attributes are valuable on origin-authorized keys. I can't think of a use case for them - this is one case in which it seems to me that it should be okay to require the app to store such attributes in localStorage or indexedDB, since the origin-authorized key is presumably managed out of band and is liable to disappear at any time.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, August 17, 2012 1:04 PM
To: Vijay Bharadwaj
Cc: David Dahl; Harry Halpin; Web Cryptography Working Group; Mitch Zollinger
Subject: Re: crypto-ISSUE-17: Define the scope and API for custom key attributes [Web Cryptography API]

On Tue, Aug 14, 2012 at 9:29 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> 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?

One of the concerns I have is exactly this - should attributes be visible across origins?

My instinctual reaction is that no, they should not be - and for the same reasons that IndexedDB or Web Storage are not visible inter-origin.

This does raise an interesting question with regards to certificates though. If demoted to "second-class" - that is, accessible as attributes of the keys, but those attributes are not visible between multiple instances of the underlying key in different origins - then it's essentially a statement that you (that is, the implementor) cannot share certificates between origins. Not having access to the certificate means that one of the main use cases envisioned for exposing the underlying key to multiple origins - that is, for portability based on user consent - may not be worthwhile.

To put it differently:
- If a hypothetical implementation chose to expose the same key to different origins (that is, under different key IDs), should the attributes for Key(ID1, Origin1) be shared as attributes with
Key(ID2,Origin2) as well?
- If so, what are the privacy and security implications?
  - User assent has been granted (but was it informed?), so is there a privacy risk?
  - Is there a security risk in sharing attributes, if the mere act of sharing keys allows origins to spoof messages to eachother (that is, for a given C = Signature(Message, Key), it cannot be distinguished whether C originated from Origin1 or Origin2), is there any risk in also sharing attributes (where Origin1 can affect attributes used by Origin2, and vice versa?)
- If not, are there things that should be exposed/shared anyway?

These do all feel like questions that are more in the realm of Implementation issues than actually spec issues, since right now the spec says nothing either way about sharing between origins, and is instead focused on a single-origin security model that 'just happens'
to be possible to expand to multi-origin.

I don't think I have a concrete proposal on this yet, and since I'm the biggest advocate for UAs being able to extend the security bounds, I'll try to come up with something more concrete for the mailing list.
That said, my intent when proposing was certainly that attributes (whether custom or indexeddb/webstorage) would remain scoped to the origin, even if the key wasn't.

>
> -----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 Monday, 27 August 2012 10:00:02 UTC