W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: Using client certificates for signing

From: Eric Mill <eric@konklone.com>
Date: Tue, 23 Feb 2016 20:49:29 -0500
Message-ID: <CANBOYLX3uYVOwukfiQ1uBg8J7e9_=kfpeYb7oafE87zMup34pg@mail.gmail.com>
To: Henry Story <henry.story@gmail.com>
Cc: noloader@gmail.com, "public-webappsec@w3.org" <public-webappsec@w3.org>
I'll just say that as a list member, I'm exhausted by the constant
rehashing of this same issue. This thread isn't adding anything to prior
ones, and it's subtracting energy from (at least one of) its members.

On Tue, Feb 23, 2016 at 11:01 AM, Henry Story <henry.story@gmail.com> wrote:

>
> > On 23 Feb 2016, at 10:34, Jeffrey Walton <noloader@gmail.com> wrote:
> >
> >> Microsoft are also behind the W3C TAG (Techncial Architecture Group)
> finding
> >> on client certificates
> >>
> >>  http://w3ctag.github.io/client-certificates/
> >>
> >> I'd suggest reading that for guidance rather than the rumour mill.
> >
> > Well, its kind of disingenuous that companies who make browsers are
> > against it and they present their claims. The security model and
> > threat models used for the web are broken. They are simply not
> > realistic, and they represent some netherland that does not exist for
> > most users.
> >
> > "Interception is a valid use case" is ghastly, including the
> > abomination known as Public Key Pinning with Overrides. Claiming
> > authority for it in the W3C's Priority of Constituencies is tenuous at
> > best. Even the IETF is embarrassed by that standard.
> >
> > The browser's inability to work with client certificates is one of the
> > reasons the browser is delegated to low value data only. And not
> > surprisingly, the same companies building the browsers tell you its OK
> > to handle high value data, and store the data in their clouds. Its
> > like trying to ask a drunk if he is drunk, and trying to get a
> > straight answer...
> >
> > Client Certificates have long been the way we have combatted the
> > chronic mishandling of secrets perpetuated by browsers.
>
> I am of course a big proponent of TLS, client-certs and keygen.
> https://www.w3.org/2005/Incubator/webid/spec/tls/
>
> That does not mean that I think the current technology is perfect
> of course, but on the web one should not ask for perfection,
> but instead for continuous improvement.
>
> • CA's are known to be broken because of the least common denominator
> problem
> Browsers chould implement IETF DANE to improve that
> https://tools.ietf.org/html/rfc6698
>
> • X509 Certificates are old fragile technology.
> Hopefully the Verifiable Claims task force will
> come up with a much more webby way of doing that
> http://opencreds.org/specs/source/use-cases/
>
> • WWW-Authenticate: with password is bad
> TLS authentication could be moved to the http layer
> with HTTP-Signature. I have implemented this and it works
> https://github.com/solid/solid-spec/issues/52
>
>
> Henry
>
> >
> > Jeff
>
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
Received on Wednesday, 24 February 2016 01:50:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC