Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

On 2011-06-07 03:58, Nico Williams wrote:
> On Mon, Jun 6, 2011 at 11:16 AM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
>> Although I'm not a DOMCrypt champion, I think this is where DOMCrypt
>> shouldn't go.  PKCS #11 and Smart Cards are very complex and unsuitable
>> for web programming.  The biggest smart card maker Gemalto launched a
>> web-interface for smart cards a few years back called SCConnect.
> 
> PKCS#11 is difficult to use.  One thing we learned at Sun (later
> Oracle) is that a simple raw crypto API is highly desirable, with
> PKCS#11 relegated to using keys on tokens (smartcards).
> 
> That said, a smartcard interface is the most we could do in terms of
> browser integration with JS crypto APIs, and even that is pretty lousy
> -- the user can't possibly know what some script intends to do with
> some key, nor can the browser figure it out either.  And yet, if we
> don't even do that, then what do we expect a JS crypto API to do for
> us, in terms of security?  A JS crypto API will NOT help us improve
> security unless we also greatly improve server/script authentication.

Well, that's one approach.  I'm fairly skeptical about the prospects
for trusted code and therefore delegate the gory stuff to the browser
itself.  Creating a multistep E2ES (End-to-End Security) provisioning
scheme like KeyGen2 based on a set of JS-methods and objects seems
infeasible; it will most likely turn up as MSFT's "CertEnroll" which
has been replaced by proprietary solutions since it simply doesn't
work.  MSFT is reportedly replacing it with something more along the
lines I propose, running in trusted code and uses XML Schema.

That said, a JS crypto API would be great but it does not eliminate other
solutions it may complement it.

Anders


> 
> Nico
> --
>

Received on Tuesday, 7 June 2011 04:17:55 UTC