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

On Fri, Jun 10, 2011 at 3:24 PM, David Dahl <ddahl@mozilla.com> wrote:

> ----- Original Message -----
> > From: "Anders Rundgren" <anders.rundgren@telia.com>
> > To: "David Dahl" <ddahl@mozilla.com>
> > Cc: "Nico Williams" <nico@cryptonector.com>, public-web-security@w3.org,
> "Jarred Nicholls" <jarred@sencha.com>
> > Sent: Friday, June 10, 2011 1:17:21 PM
> > Subject: Re: Smart Card support. Re: Request for feedback: DOMCrypt API
> proposal
> > On 2011-06-09 23:17, David Dahl wrote:
> > <snip>
> >
> > > The client does all crypto operations and the server is only given
> > > cipher text to store
> >
> > IMHO, this is a rather odd value proposition:
> > The server is supposed
> > to provide JS-code for the client to encrypt data so that the server
> > can't
> > see it. Yes, cloud-storage services do this but they provide a lot
> > more than just a crypto API.
> >
> On the contrary.
>
> The point is that the crypto is performed by your browser on the local
> machine - not by minimized server script or closed client apps of dubious
> value. Also, developers can write apps that use third-party APIs and
> services, but the plain text beomes cipher text, with the 3rd party having
> zero knowledge of the conversation, which is a main point of this API.
>
> Conversation, in general, has moved from email to web. In which case, a
> third-party always has a copy of your conversation.
>
> > > - and, yes, key management is still a problem,
> > > which I know is a huge problem that will have a solution at some
> > > point.
> >
> > The S/MIME people haven't got this ball running in 15 years so there's
> > not a surefire victory in sight :-(
>
> I think this is now a job for web engineers to figure out an elegant set of
> solutions. It will take time, but I also think the time is right, the
> emphasis and interest in privacy and user control is only going to grow. Not
> to mention that web developers want "webby" tools to work with, not
> complicated systems whose docs make your eyes bleed. All of this can be
> simplified.
>
> > I'm sure we will get a JS-API, primarily because it is simple to
> > implement and will have a very limited impact on browser "footprint".
> > When it comes to *usage* I remain a bit skeptical.
>
> That's ok, I happen to think that this kind of API has a huge number of
> consumers just waiting to get their hands on it.
>

+1


>
> Regards,
>
> David
>



-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>