Re: [W3C Web Crypto WG] comments on draft API - section 4

+1 (except that I would also like to add this attribute to the query API as well).


Though I agree with Ryan that, at the end of the day, such information is inconsequential at the JS layer – as the server still needs a pre-created trust characteristic for the key used. However, ability to select a key based on its source at the JS level still looks useful to me.

I mentioned this at the F2F also – I think that having the ability to limit a key set to application determined sources increases usability. Taking the case of presenting a set of keys for the user to select – there is no reason to present a bunch of keys that are not 2-factor based, if the application is only interested in the second factor key.

Seetharama

On 8/27/12 10:47 AM, "Ali Asad" <Asad.Ali@gemalto.com<mailto:Asad.Ali@gemalto.com>> wrote:

I concur with Jim;  but with specific focus on key discovery. The API does not provide a way for the application to know the source of the key selected by the user.

We all agree that generating a key on secure element, or mandating the use of a secure element through the API is out of scope. As such when an application makes a call to ask user to select a key, the API should not have any secure element specific request. However, if the user does select a particular key from a secure element (e.g. smart card) then this information should be conveyed to the application. The current thinking is that the agent (browser) keeps track of the key source and then implicitly uses the corresponding crypto provider when that key is used in a crypto operation. I do not feel that passing this implied information to the application will degrade usability of the API – in fact it will allow application to be written with a stronger focus on security if so desired by the app. I am thinking of a simple application that wants a user to sign something with his smart card. In the absence of this knowledge about source of key selected by the user, the server that validates the signature will not be able to assert this “two-factor” mode of doing signature. We can have a similar scenarios for PKI based user authentication based on classical challenge-response.

Regards,
--- asad


From: Davenport, James L. [mailto:jdavenpo@mitre.org]
Sent: Monday, August 27, 2012 9:10 AM
To: GALINDO Virginie; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: [W3C Web Crypto WG] comments on draft API - section 4

Did Virginie’s suggested working get incorporated into Section 4?  I like her wording better than what is in Section 4 right now.

As Virginie stated, the API does not include “discovery of cryptographic modules.”   Since the intent is that each key is internally bound to a cryptographic provider or module, how will we handle the discovery of out-of-bound keys?  Further, how can we ensure that this out-of-bound key is tied to a SUPPORTED cryptographic provider or module?  Section 1 talks about key discovery, but it’s not yet in the API.

--Jim

From: GALINDO Virginie [mailto:Virginie.GALINDO@gemalto.com]
Sent: Monday, August 20, 2012 8:32 AM
To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: [W3C Web Crypto WG] comments on draft API - section 4

Hi editors,

Just thinking about means to formulate in a different way the scope of the draft API. What do you think about the following – I kept most of the wording, but reordering and clarifying paragraph. What do you think ?

----

Level of abstraction : The specification attempts to focus on the common functionality and features between various platform-specific or standardized cryptographic APIs, and avoid features and functionality that is specific to one or two implementations. As such this API allows key generation, management, exchange and discovery with a level of abstraction that avoids developers to care about the implementation of the key storage. The API is focused specifically around keys and opaque key handles, which may or may not expose the underlying raw cryptographic keying material to the application. The intent behind this is to allow an API that is generic enough to allow conformant user agents to expose keys that are stored within in local storage, in isolated storage or in secure elements, if desired, but in such a manner that rich web applications will not have to be coded with specific knowledge of the key storage mechanism or its implementation details.


Cryptographic algorithms  : Because the underlying cryptographic implementations may vary between conforming user agents, and may be subject to local policy, including but not limited to concerns such as government or industry regulation, security best practices, intellectual property concerns, and constrained operational environments, this specification does not dictate a mandatory set of algorithms that MUST be implemented. Instead, it defines a common set of bindings that can be used in an algorithm-independent manner, a common framework for discovering if a user agent or key handle supports the underlying algorithm, and a set of conformance requirements for the behaviours of individual algorithms, if implemented.
Editorial note
WEBCRYPTO-ISSUE-1<http://www.w3.org/2012/webcrypto/track/issues/1> is currently tracking the ongoing discussion about whether there should be a set of mandatory algorithms that user agents MUST implement, as opposed to a set of algorithms that user agents SHOULD implement.

Operations : Although the API does not expose the notion of cryptographic providers or modules, each key is internally bound to a cryptographic provider or module, so web applications can rest assured that the right cryptographic provider or module will be used to perform cryptographic operations involving that key.


Out of scope :  This API, while allowing to generate key material on the fly and retrieve it, does not address provisioning of keys in external secures token (e.g. smart card) as it is often saddled with vendor-specific details that make it unsuitable for a generic interface. Neither the API addresses the discovery of cryptographic modules.
--------------

Regards,
Virginie
gemalto