Re: Need for Smart Card support

On Fri, Jun 8, 2012 at 9:43 AM, David Dahl <ddahl@mozilla.com> wrote:

> Of course, the existing PKCS#11 routine (Prefs->Advanced->Encryption) in
> Firefox is a way to register a device. Perhaps I am under the impression
> that the API would govern the registration of hardware modules?
>

I would think that would definitely be out of scope.

"Registration of hardware modules" inevitably involves native code, and the
idea of a JavaScript API allowing sites to install native code is a
non-starter. Further, as noted in the charter and as Harry noted,
specifically trying to avoid that as it involves device-specific calls.


>
> I need to read up on how other browsers do this - and how NSS deals with
> crypto hardware and keyIDs. I think the real question here is does the API
> not have to do anything, just have the keyID passed to it to operate? All
> of the implementation details are hidden from the API, and things
> just work?
>

I would prefer that, in our first draft, and consistent with the charters
goals, that any awareness of smart cards or secure elements be left out.
Simply dealing in key IDs is, I believe, sufficient enough to support the
core use cases and primary goals, and also gives implementors the
flexibility to expose keys stored in secure elements in an
implementation-independent way that is compatible with the core API.

For web developers, the nature of whether or not a key is stored in a
secure element is unknown/unknowable to them - they have simply have a key
ID, for which they can do the appropriate low or high level crypto
operations.

At the risk of fueling a fire, I do not believe the "this key is in a
secure element" can be reliably exposed to applications, both due to the
web security model and due to the vendor-specific nature. As Anders
Rundgren repeatedly pointed out during the community group and the activity
on the public-identity mailing list, proof of possession/proof of a key
being within secure element has been a fundamental challenge in crypto, one
which inevitably requires significantly more complex *protocols* that
simply don't belong within a generic, simple API for signing/encrypting.
Anything short of such complex schemes/protocols can easily be faked, and
thus add zero security or programmatic value and only hinder further
progress.


> Cheers,
>
> David
>
> ----- Original Message -----
> From: "David Dahl" <ddahl@mozilla.com>
> To: "Ali Asad" <Asad.Ali@gemalto.com>
> Cc: "James L. Davenport" <jdavenpo@mitre.org>, public-webcrypto@w3.org
> Sent: Friday, June 8, 2012 11:18:56 AM
> Subject: Re: Need for Smart Card support
>
> ----- Original Message -----
> > From: "Ali Asad" <Asad.Ali@gemalto.com>
> > To: "James L. Davenport" <jdavenpo@mitre.org>, public-webcrypto@w3.org
> > Sent: Monday, June 4, 2012 9:32:25 AM
> > Subject: RE: Need for Smart Card support
> >
> > I think it will be good to have an option for interacting with secure
> > element (smart card being one example) in the API. Browsers that
> > choose to support it can implement it while others can skip it. But
> > the fact that it is there in the API will allow creation of secure
> > applications (as indicated by the use cases below) for those
> > interested in them.
> >
>
> I would like to see what the interfaces for this look like.
>
> A. How does the browser (in a cross-browser and platform way) know about
> the secure element? In other words, how is the secure element registered
> with the browser?
>
> B. Does the secure element appear to the browser as another software API
> that can be called, e.g: window.crypto.secureElement.* ?
>
> * or *
>
> C. Does the secure element export keys which the browser imports and uses
> like any other keys that have a key handle?
>
> I wonder what this looks like in practice. Is this a combination of crypto
> API + new browser features that 'register' the secure element with the
>  browser?  It does not appear an API can do all of this alone.
>
> Cheers,
>
> David
>
>
>
>
>
>
>