Re: [Web Crypto WG] ACTION-40 : clarifying smart card usage in section 4 of the draft API

On Tue, Aug 28, 2012 at 4:05 PM, Ali Asad <Asad.Ali@gemalto.com> wrote:
> To the editors,
>
>
>
> I suggest that we add the following text to clarify the role of secure
> elements such as smart cards in section 4.0, Scope.
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#scope
>
>
>
> Append to the second paragraph as follows…
>
>
>
>>>
>
> Chief among the implementation-specific APIs that this specification avoids
> is key provisioning for use with smart cards and other forms of
> secure-element based key storage. In addition to the inconsistency between
> existing cryptographic APIs, smart card provisioning is often encumbered
> with vendor-specific details that make it unsuitable for a generic
> interface. However, the API will not preclude the use of  pre-provisioned
> keys that already reside in secure elements such as smart cards. The use of
> such keys will be at the discretion of the application. An application can
> request to discover keys from a certain location, such as smart card, secure
> storage or DB. The application may also request notification when such a key
> is selected, and verification that the key indeed comes from the specified
> location.
>

Thanks for the proposed text, Asad.

Have I properly surprised your concerns with the existing text?

1) You wish for the scope to specifically call out the discovery of
keys from certain locations
2) You wish for the scope to specifically provide means for
"notification when such a key is selected"
3) You wish for the scope to specifically provide a means for the
verification of the key source
4) You wish for the scope to specifically call out that the use of
pre-provisioned keys are supported

It does seem that some of these concerns were previously raised during
discussion of Virginie's proposed modifications [VIRGINIE], so I
wanted to make sure I correctly understood the concerns.

I do not believe we've agreed that 1 is in scope. I agree with Vijay
that this is an interesting use case - but I do not immediately see a
way for this to be implemented cross-platform/cross-implementation,
and I think at the current state of this WD, may not be something that
can be normatively scoped until we have a better understanding from
implementors and how they propose to implement this API.

It's not immediately clear to me what you mean by 2, but your comments
during our previous conference call on 27 Aug suggest you imagine some
form of user-agent supplied interface for interacting with smart
cards, as previously floated during discussions about key querying. Is
this a correct understanding?

If querying for a key was an asynchronous operation, would the fact
that the operation completed satisfy those needs, or do you imagine
some other type of method?

I do not believe that 3 is in scope. As has been repeatedly discussed
on teleconference calls and via e-mail, and as pointed out by both
Mark [MARK] and Vijay [VIJAY], the trust decisions or awareness of a
key's "smart carded-ness" is derived through means other than the API
provided by the User Agent. This is essential to the security and
threat model of the general purpose computing devices that power the
vast majority of today's user agents. The verification that the key
comes from a specified location MUST be obtained through some sort of
out of band means (such as through a key identifier or certificate, as
Mark has highlighted)

The fourth point was already attempting to be addressed in the two
sentences that immediately follow your insertion point:

"Additionally, rather than designing an API around cryptographic
providers or modules, 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 conforming
user agents to expose keys that are stored within 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."

Would the proposed modifications address your concerns (adopted from
Virginie's proposed modifications):

"The core concept of this API is the opaque Key object, which may be
used to represent private keys, public keys, or arbitrary secret
keying material, and to do so without requiring or prohibiting access
to the underlying raw cryptographic keying material to be exposed for
operations or applications. The use of opaque Key objects permits
conforming user agents flexibility in choosing the underlying key
storage mechanism, such as through keys stored locally in RAM or on
device storage, within secure elements such as smart cards, or
remotely available through cloud storage. Additionally, such an
abstraction permits web applications to utilize a common,
storage-agnostic set of APIs to make use of keys both generated
directly by the application and keys that have been provisioned
through out-of-band means, such as via vendor-specific secure element
provisioning protocols."


[VIRGINIE] http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0134.html
[MARK] http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0279.html
[VIJAY] http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0321.html

Received on Wednesday, 29 August 2012 00:52:51 UTC