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

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

From: Ali Asad <Asad.Ali@gemalto.com>
Date: Fri, 7 Sep 2012 22:09:33 +0200
To: Ryan Sleevi <sleevi@google.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>
CC: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Lu HongQian Karen <karen.lu@gemalto.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <821D566D81EF6F4F830409E0BD3B1022C4221E01A0@ABSEXCFWP01.gemalto.com>
>>
So when we say "the client well have to iterate through each of them for each key", I think it should be clarified that we're talking about the client being "the user agent" *not* "the web application"
>>

Yes, I had a similar thinking that the client is the user agent that allows end users to pick a specific key.

Regards,
--- asad

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, September 07, 2012 1:56 PM
To: Seetharama Rao Durbha
Cc: Vijay Bharadwaj; Lu HongQian Karen; Ali Asad; GALINDO Virginie; public-webcrypto@w3.org
Subject: [+SPAM+]: Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

On Fri, Sep 7, 2012 at 8:02 AM, Seetharama Rao Durbha <S.Durbha@cablelabs.com> wrote:
> On 9/7/12 12:00 AM, "Vijay Bharadwaj" <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.

Just as a point of reference - such selection *MUST* be user agent controlled, because it's about making a security decision. Exposing the keys to the web application, in order to allow the web application to present an interface that the user then selects which keys to authorize for the web application, is a fundamentally flawed and inherently insecure operation.

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

Originally, we were talking in terms of discovery/authorization. Such UI is necessarily *only* in the user agent, and cannot be (securely) exposed to arbitrary web applications.

So when we say "the client well have to iterate through each of them for each key", I think it should be clarified that we're talking about the client being "the user agent" *not* "the web application"
Received on Friday, 7 September 2012 20:10:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 20:10:07 GMT