Re: WebCrypto High-Level API - Why?

----- Original Message -----
> From: "Anders Rundgren" <anders.rundgren@telia.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: "Tom Ritter" <tom@ritter.vg>, public-webcrypto-comments@w3.org
> Sent: Friday, January 25, 2013 9:55:34 AM
> Subject: Re: WebCrypto High-Level API - Why?
> 
> 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.

Backward-compat with existing protocols and systems is a 'non-goal' of any high-level API. The point is to make crypto more like HTML5 and the web, easy and 'safer' (as much as can be) - without forcing the developers to get an advanced degree in Crypto.

Regards,

David

> 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 16:57:40 UTC