RE: ISSUE 2: How to address pre-provisioned keys

+1

For existing keys, it appears to me that key-based or certificate-based lookup should suffice, as Ryan outlines below. Smart card management is out of scope in any case.

That leaves the question of key generation and whether we should support the desire of web apps to do things such as generate a key pair on a specific smart card. My feeling at this point is that this is non-portable and hard to get right (if it is even possible in the web security model), and we should explicitly declare this out of scope.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, July 23, 2012 4:40 PM
To: Lu HongQian Karen
Cc: public-webcrypto@w3.org
Subject: Re: ISSUE 2: How to address pre-provisioned keys

On Mon, Jul 23, 2012 at 4:05 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>
> ISSUE-2: How to address pre-provisioned keys and managing ACLs
>
> https://www.w3.org/2012/webcrypto/track/issues/2
>
>
>
> Since the key provisioning is out of the scope, the web crypto API 
> should be able to discover existing keys and learn how the key should 
> be used. We can imagine that the key has various attributes, including
>
> *         Type of the key, length, value, etc.
>
> *         Key store location - where the key is stored, for example
>
> o    Browser/local-storage, browser/secure-store, OS/secure-store, or smart card, etc.
>
> *         Crypto provider name - who does crypto using this key, a hint for the browser, for example
>
> o    Browser, or smart card
>
>
>
> For example, for a pre-provisioned key in a smart card, it will have the smart card as the key store, and the smart card as the crypto provider. Web browsers already have ways for a user to choose which smart card and which key.

Hi Karen,

I feel like these points have been addressed on several of our calls, but I appreciate you bringing them forward to the list so that we can keep a good archive of these discussions.

As I've mentioned previously, I do not think "crypto provider name"
and "where the key are stored" are suitable to be exposed via this API, and it was very intentional that I avoided proposing such a notion with the strawman that has now migrated to the editor's draft.

"Where the key is stored" is not a secure/strong signal, since a hostile/compromised script can easily be compromised. This has been pointed out by several members during the call. Thus it merely acts as an advisory signal, and because of this, doesn't really offer any value, but may cause significant harm if applications treat it as a 'secured' attribute. This point was raised again on our most recent call, on 7/16, with a similar discussion being had.

"Crypto provider name" is not a portable solution, and is very much tied to the underlying cryptographic implementation. An example of this is that one browser may interact with a key store via an opaque OS API (such as Keychain on OS X), and thus have no knowledge about how a key is implemented, one may interact via a PKCS#11 module and thus only have the (non-localized) module name, which may vary for users in different languages depending on the version of the module they have installed, and another user agent may interact via CNG, which uses key store providers.

Further, because both of these concepts are directly tied to smart cards, they seem to be out of scope.

>
> One use case is a web application letting users to sign documents using their smart cards. The signature key pair is pre-provisioned inside the smart card. The key pair, hence, has the attributes: keystore=smartcard; crypto=smartcard. The application uses the web crypto API while the browser knows to use the smart card for the signature operation instead of its own implementation.

Thank you for providing this use case, since it provides an opportunity to show why such an API is not necessary for equivalent (but reliably secure) functionality.

Rather than exposing such information (which, as discussed above, cannot be done so portably/reliably), applications might instead use "pre-provisioned keys", within either the ontology I proposed or Vijay proposed. The application should merely request that the user agent perform the signing with Key X, where the application knows a-priori that Key X is stored on a smart card. Thus, instead of a user agent telling an application that Key X is stored on a smart card (where the user agent may be deceptive or coerced), the application instead knows this out of band, where such attributes can be delivered and vetted securely.

Likewise, if an application is dealing with keys that were not directly pre-provisioned by it (eg: a banking application that wishes to use a government-issued smart card, which is a situation where the smart card provisioner is != application consuming the web crypto API), then it's fully possible that
- The banking application can inquire the user agent for accepted keys
 - Criteria might include certificates or issuers, as has been discussed in "Secondary features" of the API and mentioned on previous calls and threads
- The user agent can interact with the user to determine whether or not they wish to grant access to said keys
- If granted, the banking application can interact with properties of the key (such as signing a 'proof of possession' message, or calculating the hash of the public key)
- The banking application can make a back-end (ie: wholly independent of this API) call to the government issuer, asking "Did you issue Key X to this User"
- The government issuer can inform positively or negatively, as well as any other assertions (eg: this key is stored on a smart card)

Such solutions do not require any introduction of smart-card specific key notions to this API.

Further, within the scope of secondary features, there exists discussion about the exposure of X.509 certificates and meta-data associated with keys. Such keys would be able to act as an alternative for the (banking <-> government) backend. For example, if the banking application knows that the government provider stores on smart cards any key+cert pairs that chain to a given root, the banking application need only verify that the signature chains to such a root.

A solution such as that equally does not require the API expose any smart-card specific notions.

>
> In addition to listing available keys, it may be interesting to have API to discover browser-supported key stores and crypto providers.

I did not receive significant feedback on my KeyQueryList proposal, which I believe addresses this in a way that is wholly agnostic for crypto providers. It is in the process of being incorporated into the editor's draft, to hopefully ensure its visibility.

As discussed on several calls, including the most recent one, the API so far has not been designed around the concept of crypto providers, but instead around interactions with keys. Even the concept of "key stores" is not present in the API - instead, a single monolithic key store is presented (whether via KeyQueryList, window.crypto.keys, or ddahl's KeyAccessor).

I strongly believe that, having written applications that uses almost a dozen different APIs, each of which has a separate notion of what represents a cryptographic provider and how key storage is exposed, that the notion of "crypto providers" is an inherently non-portable notion, and any web applications written to such an idea would find them limited to a very specific browser implementation, on a very specific platform, and for very specific devices. Such a solution is not generic enough to meet our criteria or the criteria of users of this API.

While many implementations share similar concepts or abstractions, such as the concept of providers, the functional details and naming significantly differ, such that I do not believe it's possible to define a generic Web Platform API that is not inherently bound to one or two specific implementations (eg: CryptoAPI, CNG, PKCS#11, etc).

A concrete example of this is how the five different major desktop APIs (PKCS#11, CNG, CryptoAPI, Keychain, CDSA) each refer to keys and providers in different ways and with different abstractions. In the above case, the /only/ commonality in their nomenclature is identifying private keys by looking up their public key pair.

This is why I've strongly discouraged the notion that they be exposed, and instead have focused on interactions with keys and key discovery.
While such an API is more abstract, it offers a way that applications that are developed should be able to cross-operate between different user agents on different platforms, each of which may be talking to the same key backed on the same smart card, without requiring the web application to specifically encode this knowledge.

My own preference would be to table further discussions of smart cards until we've reached agreement on some of the other outstanding issues.
We've definitely identified smart cards and secure elements as out of scope for this effort. The API I put forth and which we've been discussing was done in such a way as to not preclude smart cards, if a browser decided to implement/expose them, but absolutely does not require any implementation whatsoever to be conformant.

As an implementor, I think it's worth mentioning that we have serious security concerns about exposing smart cards to web applications, such that any mandate to support them might lead us to not implementing the API, and thus our initial focus will be solely on browser mediated key storage. Past work such as SConnect or CAPICOM have shown that such exposure creates a fertile ground for attackers, and it's an exposure we'd like to protect our users from.

Cheers,
Ryan

>
>
>
> What do you think?
>
>
>
> Regards,
>
> Karen & Asad
>
> Gemalto
>
>

Received on Tuesday, 24 July 2012 14:35:57 UTC