W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013

Re: WebCrypto High-Level API - Why?

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Fri, 25 Jan 2013 16:55:34 +0100
Message-ID: <5102AAF6.7030706@telia.com>
To: David Dahl <ddahl@mozilla.com>
CC: Tom Ritter <tom@ritter.vg>, public-webcrypto-comments@w3.org
On 2013-01-25 16:20, David Dahl wrote:
> 
> 
> ----- Original Message -----
>> From: "Tom Ritter" <tom@ritter.vg>
>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>> Cc: public-webcrypto-comments@w3.org
>> Sent: Friday, January 25, 2013 8:52:57 AM
>> Subject: Re: WebCrypto High-Level API - Why?
>>
>> On 25 January 2013 01:42, Anders Rundgren <anders.rundgren@telia.com>
>> wrote:
>>
>>> I'm not sure what the High-Level API that has been mentioned a few
>>> times
>>> on the list actually
>>> refers to but I guess it is something like Google's
>>> http://code.google.com/p/keyczar ?
>>>
>>
>> The other example is NaCL: http://nacl.cr.yp.to/secretbox.html
>>
>> Personally I don't understand why we should waste money on making
>>> cryptography useable by "n00bs"
>>> rather than doing what we can making platforms more useful for
>>> those who
>>> actual master cryptography.
>>>
>>
>> Couldn't disagree more.  Why did we create standard libraries instead
>> of
>> making all these pesky noobs write their own printf functions, and
>> why
>> didn't we stop with C - what's this annoying "C#"and "Python"? So we
>> can
>> abstract away things that don't matter to most people, and stop them
>> from
>> rewriting the bugs we fixed over and over again.  (Example:
>> BasicConstraints)
>>
> 
> Indeed. For the vast majority of web developers, the actual need is 
> 
> var ciphertxt = ecryptThisStringForBob("hi"); 
> 
> or
> 
> var sig = signThisDataForAlice("data"); 
> 
> That's it. A high level API that keeps the details at bay and private key material out of the DOM will be extremely useful.
> 
> Regards,
> 
> David

The vast majority of developers that builds secure web-applications use HTTPS
which relieve them from signing and/or encrypting in the browser.  Occasionally
they need to connect to other systems in a secure way but this is all happening on
the server-side.  In addition, for communicating with other parties than yourself,
high-level cryptographic APIs only create interoperability issues.

And those who *really* need this functionality can't use it since Web Crypto doesn't
address unbound pre-provisioned keys although these are sort of the de-facto standard.

Anders


> 
> 
>> I don't disagree that there's a lot that can go wrong with protocols
>> even
>> when they're using the correct algorithms - but the point of having
>> "box()"
>> and "unbox()" functions is to make it *easier* to create secure
>> anything by
>> giving developers a secure starting point.  You seem to approach
>> security
>> with the mindset of "Make it hard for people to write code - we'll
>> have
>> less code, and the code we have will be more likely to be good
>> because it's
>> written by people who persevered!"  No, we won't have less code,
>> we'll just
>> have a lot of code that the developer *finally* got working, through
>> trial
>> and error, and will never watch to touch again.
>>
>> -tom
>>
> 
Received on Friday, 25 January 2013 15:56:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 January 2013 15:56:19 GMT