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

Knowing where the key comes from is important. An application's trust model may depend on the source of the keys. For example, if the application wants the user to use keys stored on her smart card, it needs to verify that the user indeed selected such a key. Many use cases, such as document signing, secure messaging, authentication, and banking transactions will need to know where the key comes from in order to execute based on their trust models. For example, a banking application may allow higher value transactions if it knows that the user has selected a key from her smart card.

I would suggest to put back the key storage attribute to the key object to solve this issue, and I welcome other suggestions.


From: Ali Asad []
Sent: Monday, August 27, 2012 11:48 AM
To: Davenport, James L.; GALINDO Virginie;
Subject: RE: [W3C Web Crypto WG] comments on draft API - section 4

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.

--- asad

From: Davenport, James L. []
Sent: Monday, August 27, 2012 9:10 AM
To: GALINDO Virginie;<>
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.


From: GALINDO Virginie []
Sent: Monday, August 20, 2012 8:32 AM
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<> 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.


Received on Monday, 27 August 2012 18:49:47 UTC