W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

From: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Date: Fri, 7 Sep 2012 09:02:44 -0600
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Ryan Sleevi <sleevi@google.com>
CC: Lu HongQian Karen <karen.lu@gemalto.com>, Ali Asad <Asad.Ali@gemalto.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <CC6F6618.5C58%s.durbha@cablelabs.com>
On 9/7/12 12:00 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:


ุ  I would like to agree with you. But that is assuming that a user has only one identity tied to an application – not always true. We all have multiple accounts with the same providers. Some identities may be stronger than others – the user may have some in the browser, and some in smart card(s).

It does not follow that the user must be required to select keys. A well-designed application would present the user with a choice of identities, and do key selection based on that.
I guess the UI for selecting keys is an altogether different topic. Yes, (as was also suggested by Anders Rundgren recently), the UI for selecting keys/identities should be different from the current nerdy interface. Thus, a user may not realize they are selecting a 'key' (nerdy term), they might just be presented with 'identities' that are tied to a key.


ุ  Whether a key is acceptable or not may not be possible to do on the client side, so the client-side app will have to communicate all key details to the back-end to determine which key is what it is looking for. Having an attribute on the key could help the application make choices on the client-side. Of course, as repeated so many times, this does not mean that the server does not do its own validations on the key – it still has to do those validations. The reason people do client-side validation of forms in JS is because of expediency – does not mean that server does not do those same checks.

I think we all agree with this statement. However, it seems that you’re using it to justify client-side checks that, almost by definition, cannot be repeated on the server. A server cannot possibly check what provider a key is stored in; it’s going to do cryptographic checks like looking for a certificate. Why not have the app do the same check on the client as well?
Again, I agree with you. Yes, the same logic that the server uses can be used on the client side. It is just burdensome. The server will have to expose its different trust anchors to the client and client will have to iterate through each of them for each key. Again going back to form validations done in JS, note that JS validations are not the only validations the server does, the server could do many more validations. All of them are not implemented on the client-side.
I guess the question is the relative merits of exposing this attribute  vs having the client implement trust-anchor logic.

From: Seetharama Rao Durbha [mailto:S.Durbha@cablelabs.com]
Sent: Wednesday, September 5, 2012 10:31 AM
To: Vijay Bharadwaj; Ryan Sleevi
Cc: Lu HongQian Karen; Ali Asad; GALINDO Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

Just back from long-weekend, sorry for the delay in replying.


On 9/4/12 3:05 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:

Seetharama,

Note that the reason we are down this path is so that the application
can limit the keys it wants the user to select.

I'd go so far as to say that an application that requires a user to select a key has failed its customers. As you note, users are not capable of making good choices here, nor should they have to. With that context, it feels like this is adding a feature that is exclusively intended for use by broken applications.

If an application knows what keys are acceptable to it, then it should just select the best such key. If the application does not know what keys it wants, then arguably the user is in no position to know either.

I would like to agree with you. But that is assuming that a user has only one identity tied to an application – not always true. We all have multiple accounts with the same providers. Some identities may be stronger than others – the user may have some in the browser, and some in smart card(s).

Whether a key is acceptable or not may not be possible to do on the client side, so the client-side app will have to communicate all key details to the back-end to determine which key is what it is looking for. Having an attribute on the key could help the application make choices on the client-side. Of course, as repeated so many times, this does not mean that the server does not do its own validations on the key – it still has to do those validations. The reason people do client-side validation of forms in JS is because of expediency – does not mean that server does not do those same checks.


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Wednesday, August 29, 2012 11:18 AM
To: Seetharama Rao Durbha
Cc: Lu HongQian Karen; Ali Asad; GALINDO Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

On Wed, Aug 29, 2012 at 11:03 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:


On 8/29/12 11:35 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Wed, Aug 29, 2012 at 10:02 AM, Lu HongQian Karen
<karen.lu@gemalto.com<mailto:karen.lu@gemalto.com>> wrote:

Hi Ryan,

I agree with you that Issue-30 needs more elaboration.

Regarding to keylocation, I was thinking

Enum keyLocation {
    None, // unspecified
    Browser, // browser's storage
    Local, // local storage other than browser's
    CryptoProvider // complexity: a user agent may have more than one
cryptoProviders };


The distinction between "Local" and "CryptoProvider" is fundamentally
flawed in assuming an implementation detail - since an implementation
may access "Local" (which I assume to mean 'OS storage', but in fact
can mean much more) storage via CryptoProviders.

In fact, all Browser storage is could simply be another CryptoProvider.

Note that the reason we are down this path is so that the application
can limit the keys it wants the user to select.

<snip>
And that's where the breakdown in communication is happening.

The premise of a user selecting something is related to querying/discovery, not provisioning. Further, this isn't the only reason we're down this path - it has been expressly commented and described by Karen that this distinction is for web applications to make trust decisions - http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0274.html

As discussed elsewhere, the notion of "provisioning", as has been used in the discussion of "pre-provisioned keys", is meaning that all the information is already provided, and there is nothing for the user TO select.

The moment you talk about "the user selecting" something, this goes into
1) Key discovery
2) User interface experience to support key discovery

We're not there yet. We're a rather long way away from that, in fact, because of the security/usability concerns, let alone the implementation details.
Received on Friday, 7 September 2012 15:03:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 15:03:49 GMT