Re: comments on web crypto API: Side effects of a low-level API [1/6]

high level api and secondary feature is different.
TLS or certificate is in scope of secondary features.

the supercookies with cross-origin feature will cause security problem when
it run silently.
silent operation has another issue for key ownership.

one of missing part from current low-level API is
if provisioner decided to give ownership of key to user,
there's no way to make it true.

when an user has key ownership, the key can be used on any site when user
want.
key ownership means strict access control for their keys (including private
key of certificate) with PIN  or other mechanisms that is already adopted
in TLS model.




On Fri, May 24, 2013 at 2:05 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, May 23, 2013 at 1:35 AM, Nikos Mavrogiannopoulos
> <nikos.mavrogiannopoulos@esat.kuleuven.be> wrote:
> > Hello,
> >  Our comments on the available Web Cryptography API are given below and
> on
> > the few next e-mails.
> >
> > === Side effects of a low-level API ===
> > A low level API into javascript moves the notion of standards' based web
> > communications security (which is now only available via the TLS
> protocol),
> > to a web site-based communications security. Any website can advertise
> > security features such as encrypted uploading of files, but a user can
> never
> > verify whether the algorithms used are standards' based, or are correctly
> > used. Most importantly he can barely verify that the algorithms are used
> at
> > all. As it is now the API looks suitable for javascript plugins inside
> > browsers or to intranet applications, but not for the public Internet.
> >
> > A solution to that approach would be to offer high level API to handle
> the
> > common of the expected use cases of the low level API, and that high
> level
> > API will use standardized protocols, implemented in the browser. For
> > example:
> > * An API to upload an encrypted and authenticated file
> >  -> the browser uses the standardized procedure and the user is notified
> by
> > the browser that his file will be encrypted prior to uploading
> >
> >
> >
> >
>
> This API is not trying to replace TLS.
>
> The discussion of high-level versus low-level has been treated at
> great length in this working group - perhaps the single largest issue
> after pre-provisioned keys ("supercookies"). This WG has repeatedly
> asserted that we are NOT trying to provide a high-level API - that is,
> the goal is to provide a suitable set of cryptographic primitives that
> allow for a wide variety of protocols and applications to be
> developed.
>
> Some of these applications MAY be designed with good intention, but be
> insecure. That's life. A web author can design a page that allows for
> cross-site scripting or cross-site request forgery, or any number of
> other insecure practices. It is explicitly NOT a design goal of this
> API to try to make such things impossible, as it runs directly counter
> to the goal of providing a flexible, protocol-agnostic API that allows
> for richer web applications.
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World