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

Re: Using client certificates for signing

From: Jeffrey Walton <noloader@gmail.com>
Date: Tue, 1 Mar 2016 21:39:24 -0500
Message-ID: <CAH8yC8mR42ZK1mmbDOT5tnRt_mRrJH8aRLO414CfYFBn1Oikuw@mail.gmail.com>
To: Mitar <mmitar@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
> To me it is really the same thing: I want to login into the website, I
> choose username from my keychain to populate the password, or I choose
> the certificate. But the certificate also allows one to sign stuff,
> instead of business logic on the website assuring that because user
> specified username and password at a given moment they are linked to
> that same stuff.

The disconnect is higher than that...

When security architects place security controls for data, they do two
things. They (1) classify the data, and then (2) they select controls
appropriate for the data according to policies and procedures.

When dealing with low value data, passwords are OK and Usability can
trump Security. User agents are allowed to dumb things, like coughing
up the password to any server that answers, including the wrong one
because the web security model removes the user and embraces
"interception is a valid use case".

When dealing with medium and high value data, passwords are out and
client certificates are in. The password is still used locally to
protect the private key, but it is never put on the wire. We also
model the user because we know the number on threat to the data is
user phishing. With medium and high value data, Security trumps
Usability.

The disconnects won't be reconciled until (1) the browsers become
familiar with other methodologies to managing risk; (2) the security
and risk model includes the user; and (3) browsers realize that
"interception is not a valid use case" because that completely
destroys one of the three states of data - data in transit (the other
two being data at rest and data on display).

Browsers will also need to provide first class protected storage or an
interface into the platform's protected storage. I think you've
touched on some of the workflows, but we need first class protected
support that does not depend on a iOS device pincode or passcode.

My guess is browsers will continue to misunderstand the larger
picture, and continue to whither on client certificate support, and
continue to be subjugated to low value data.

#NSA, GCHQ, law enforcement and bad guys luvz web (in)security.
Received on Wednesday, 2 March 2016 02:39:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:18 UTC