- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 12 Jun 2012 13:09:54 -0700
- To: Nadim Kobeissi <nadim@nadim.cc>
- Cc: public-webcrypto@w3.org
- Message-ID: <CACvaWvZL2FuYAw0-rw0SuuVHg58YV0Nj9pSC_=9dpE0TJ0+jNg@mail.gmail.com>
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. Cheers, Ryan
Received on Tuesday, 12 June 2012 20:10:28 UTC