Re: Dealing with pre-provisioned keys

On Mon, Sep 24, 2012 at 11:11 AM, Da Cruz Pinto, Juan M
<juan.m.da.cruz.pinto@intel.com> wrote:
> This is interesting (somewhat covered in section 2.8). Note that discovery of the underlying cryptographic modules is currently out of scope (section 4.4).
>
> The way I see this happening is:
>
> 1) The underlying crypto service provider (e.g. smart card, OS key store, using PKCS#11 or similar) provides an enumeration of existing (pre-provisioned) keys
> 2) The WebCrypto API implementation enumerates the underlying crypto providers and individual keys, extracting key attributes, etc. How *this* happens is implementation-dependent
> 3) The WebCrypto API exposes these keys as part of the Crypto.keys attribute (KeyStorage interface), so that developers can perform lookups (see ISSUE-31 on looking up keys) and finally use the keys
>
>
> Marcelo.

This matches my understanding for keys that have been pre-provisioned
and previously authorized for the origin through out-of-bands means.

While implementation specific, there are presumably optimizations that
may be able to be made. For example, 2 may not need to communicate
with any smart cards or cryptographic providers a-priori (step 1), and
may instead simply 'advertise' that certain pre-provisioned keys are
available based on configuration directives. It doesn't need to
contact the provider until the user attempts to actually use it (via a
CryptoOperation).

Keys that have been pre-provisioned but which may require explicit
authorization - for example, keys stored on a smart card issued by a
government entity but which many different origins may wish to use -
would presumably go through a different flow, as user consent may need
to be granted to use these keys. This is part of what ISSUE-31 is
tracking.

Received on Monday, 24 September 2012 18:32:05 UTC