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

On Wed, Aug 29, 2012 at 7:11 AM, Ali Asad <Asad.Ali@gemalto.com> wrote:
> 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> 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.

Pre-provisioned keys mean that the key has, with the cooperation of
the user agent and the application, been granted for an origin through
out-of-band means.

The very presence of the key tells you everything you need to know (as
pointed out by Mark, as pointed out by Vijay, and as repeatedly
pointed out by me)

Since smart card vendors have overloaded the term "provisioning" to
mean something that is specific to their implementations, I'll try to
clarify the language here: "Provisioning" a key, as we've been using
with the term "pre-provisioned", means the generation of the key, its
attributes, AND the authorization of origins allowed to access it AS
IF the origin had created it directly (eg: with the same level of
trust and [lack of] user interaction).

This is wholly and fully independent of key DISCOVERY - since the
pre-provisioned key is already and immediately known to the
application.

If you have a pre-provisioned key, there is NO work your web
application needs to do to discover this. The key exists and is ready
to use and abuse. Since to do anything meaningful with it, your
application MUST be aware of it through out of band means, the
"notification" that a key is stored (on a smart card, in external
storage, etc) should be provided through those same out of bound
means.

Thus, this is *different* than the smart card usage of the term, which
sees "provisioning" as the act of storing the key on the card, while
still leaving a distinct discovery step. For this API, and in all of
our discussions of pre-provisioned keys, this is NOT what is meant
when we talk about "provisioning"

>
> 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 J 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.”

Respectfully, no. Such addition is unnecessary for the reasons described above.

>
>
> [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 18:00:32 UTC