W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: The Adequacy of HTTPS as a Transport

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 12 Jun 2012 13:09:54 -0700
Message-ID: <CACvaWvZL2FuYAw0-rw0SuuVHg58YV0Nj9pSC_=9dpE0TJ0+jNg@mail.gmail.com>
To: Nadim Kobeissi <nadim@nadim.cc>
Cc: public-webcrypto@w3.org
On Tue, Jun 12, 2012 at 12:49 PM, Nadim Kobeissi <nadim@nadim.cc> wrote:

> Hi everyone,
> I believe that since we're trying to implement crypto primitives that
> web applications will call through served code, we should also address
> whether HTTPS/SSL is a good enough transport on which we can rely for
> those calls to be served securely.
> There have been many high-profile cases over the past year (Comodo,
> VeriSign, to name a few) that have cast the HTTPS certificate authority
> system in an unfavorable light. Can we agree on whether HTTPS is
> sufficient to be used jointly with our W3Crypto framework, or whether we
> need to improve it before we can rely on it as our transport?

> It is my opinion that the security of the transport transport is just as
> valuable as that of our API, and that this merits a discussion at least.
> It might be out of the scope of what we're hoping to accomplish here,
> though, and that's understandable.
> Thanks,
> NK
My own view is that any discussion of transport security would be out of
scope, and likely detrimental to the deliverable goals and timeline that
we've set. While I'm very much interested in the set of problems related to
it, the overlap with a number of existing working groups is significant
(eg: IETF DANE and IETF WebSec, responsible for DANE, HSTS, Cert Pinning,
TACK, etc, IETF PKIX WG for PKI policy like OCSP Must Stable or Policy
extensions, W3C WebAppSec for security/policy mechanisms for scripts)

Our charter at http://www.w3.org/2011/11/webcryptography-charter.html lists
within the secondary features the possibility of derivation of keys from
TLS sessions, which can be used to implement mutual authentication schemes.
This may permit some enhancements, although because this is a Web API,
unless the script itself was pre-provisioned out of band, a hostile
third-party could just replace the script that is doing the verification.

While I think the API and its security design will need to factor in
transport security, it also needs to factor in things like the
trustworthiness of the user agent, the host OS, and key storage mechanisms,
all of which I think are equally out of scope but important considerations.

Received on Tuesday, 12 June 2012 20:10:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC