W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

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

From: Nico Williams <nico@cryptonector.com>
Date: Sat, 11 Jun 2011 18:01:38 -0500
Message-ID: <BANLkTi=Pxtnwmj=qQKpHumzoH1dgSY7YDA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Brian Smith <bsmith@mozilla.com>, public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>, David Dahl <ddahl@mozilla.com>
On Sat, Jun 11, 2011 at 7:05 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> On 10/06/11 21:41, Nico Williams wrote:
>> That's where trust comes in.  If you have scripts putting
>> authentication methods together in the scripts, I worry that will only
>> get us a false sense of security.
> I think that this is a really a problem with downloaded code
> and is not specific to downloaded code that calls a crypto API.

Clearly, but the API we're talking about is for downloaded code.  What
do we stand to gain from making crypto APIs available to JS scripts?
Not stronger authentication -- that's the main point I've been making.
 (Even with smartcard-type interfaces, there's no way a browser nor
user could know what a script intends to use a key for.

> In other words, I'm not at all sure that solving key management
> for such API calls is that interesting by itself and that we'll
> be better off investing our time in some way of validating and
> controlling downloaded code, and that that's sufficiently
> different from this crypto API activity that those are actually
> fine things to do mostly separately.

Assuming trusted downloaded code, yeah, there's less urgency in key
management.  But really, what would we do to authenticate that code?
PKI?  We already have that for servers...

Received on Saturday, 11 June 2011 23:02:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:26 UTC