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 Friday, 17 August 2012 20:04:51 UTC