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

Hi.
can you suggest how origin authorize keys?
I'm not clear the authorization process.

regards
mountie

On Mon, Aug 27, 2012 at 6:58 PM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

> 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
> >> >>
> >> >
> >> >
> >> >
> >>
> >
>
>
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World