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