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

Re: Using client certificates for signing

From: Mitar <mmitar@gmail.com>
Date: Tue, 23 Feb 2016 23:01:08 -0800
Message-ID: <CAKLmikOtC2TNXCbv25pXsJOpQVofvUNknrjbYC=kK-33JGjChg@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Cc: Henry Story <henry.story@gmail.com>, noloader@gmail.com, "public-webappsec@w3.org" <public-webappsec@w3.org>

I am sorry to exhaust you. But based on your words it seems this is a
common issue for people which has not yet been address adequately.
Instead of giving up, let's find a solution which can work for those
common cases. We might not find the perfect solution, but it is really
sad that one cannot fill their taxes or sign a petition without
installing a Java plugin which then fetches the certificate from the
OS keychain. I have to then trust the Java, some strange closed-source
plugin developed by one company hired by the government, and the whole
fact that everything works only in Windows and IE. Or some other
similar combination.

I would prefer to have at least something in the browser, even if it
is not perfect. Saying that the solution is not perfect will not get
rid of real use needs they are. Also, saying that there is some
magical future solution does not help much at this moment as well.


On Tue, Feb 23, 2016 at 5:49 PM, Eric Mill <eric@konklone.com> wrote:
> 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

Received on Wednesday, 24 February 2016 07:01:40 UTC

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