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

Hi Ryan,
Please see my comments below tagged with >> [AA]

Thanks,
--- asad


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Tuesday, August 28, 2012 7:52 PM
To: Ali Asad
Cc: public-webcrypto@w3.org; GALINDO Virginie
Subject: 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<mailto: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
>> [AA] yes, but it can be deferred.

2) You wish for the scope to specifically provide means for "notification when such a key is selected"
>> [AA] yes

3) You wish for the scope to specifically provide a means for the verification of the key source
>> [AA] yes, but it can be dropped if we have #2.

4) You wish for the scope to specifically call out that the use of pre-provisioned keys are supported
>> [AA] yes.

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.

>> [AA] I think we should seriously consider this. It has also been pointed out by others (Seetharama : http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0306.html ) that we would need a way to narrow down the list of keys a user has to pick from. Else we are looking at a rather cumbersome user experience where keys from multiple locations are presented. End users are already loath to deal with keys, certificates and other cryptographic primitives, and this API will not help the situation if the selection list is not narrowed based on application preference.

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?

>> [AA] Not exactly. I do not mean a specific user interface for smart card interaction. Each user agent implementation can decide how to do that. We have already agree that pre-provisioned keys from smart card can be selected. We have also agreed that if a key is selected from smart card the user agent will implicitly use the corresponding crypto provider (smart card in this case) for all subsequent crypto operations involving that key. What I am asking for here, is for the application to be informed that this is happening.

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?

>> [AA] This would be fine, provided the information regarding where the key was selected from is passed back to the application.

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)

>> [AA] Ok, this one I agree can be dropped since it may be hard to do a verification of the source. But a notification should still be provided, as indicated in #2.

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

>> [AA] Yes, this is a good compromise, and if we modify it just slightly I will be happy :) Here is the one line appended to this text,

"...element provisioning protocols. The application will be informed of the source of such pre-provisioned keys if they are selected by the user."


[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