[Cryptography] On the deployment of client-side certs

[Thierry Moreau]

This is a multi-million dollar question: a workable answer might signal 
a serious alternative to password-based authentication.

On 14/11/16 10:45 PM, Ray Dillinger wrote:
> In response to recent discussion on the list:
>
> Right now we have infrastructure in place to authenticate the host side
> of most connections.  Predictably we still have massive fraud
> perpetrated through credential theft followed by use of stolen
> credentials as an unauthenticated client.
>
> There is a technical standard for client-side certificates, which was
> part of the original SSL specification.  However, because CAs demanded
> that people pay for every certs, it was utterly ignored and never
> deployed; Homer Husband and Harriet Housewife were not going to spend a
> four-digit number of dollars (or equivalent) on a certificate, and no
> sane vendor or banker was going to require them to.  Hence the
> half-fast* job of one sided authentication that has become the norm.
>

Some historic perspective.

The privacy question was raised early: the client certificate was to 
hold the user identity and sent in the clear with SSL.

Client certificate costs were intended to fund certification 
authorities, i.e. entities collecting feed and avoiding liability by all 
means. No financial institution would trust such a third party.

Also, in these days where suspicion about state surveillance agenda is 
fashionable, I might argue that SSL lack of privacy was a bargain 
considering that OSI Network Layer Security Protocol had built-in 
certificate encryption (for the technical side of this -- pointless -- 
arguing, see http://www.connotech.com/pract_sec_authed_dh_xchng.html ).

> This sounds like a proper use case for self-signed certs (on the
> consumer side) with pinning (on the host side) to prevent fraudsters
> from impersonating consumers.

The user mental model (even before the user interface issue is 
addressed) is very difficult. The authentication capability lies in the 
PRIVATE COUNTERPART of the public key found in the certificate, and the 
certificate itself is at once public and privacy-threatening. I note 
that your post makes no reference to the very security basis (again the 
PRIVATE key). Try to explain that you might get certified for a PRIVATE 
key that your device generated, or be provided a PRIVATE key along with 
a certificate, or renew a certificate with either the same or a fresh 
PRIVATE key, or ...

> That's within practically everybody's capability, (in the sense that
> code to create self-signed certs is all over the place and most SSL
> implementations allow certs to be used on both sides) but nobody's about
> to do it (consumers) or require it to be done (bankers, merchants, etc)
> or facilitate doing it (servers, browsers, mail clients, etc).
>

Instead of self-signed, I prefer auto-issued (see 
http://www.connotech.com/public-domain-aixcm-00.txt ) because it 
facilitates the server side configuration.

Make certificates totally meaningless except as a carrier format (SSL 
compliance concern, period) for the public key matching the PRIVATE key.

> How can we change that?  What can we do to make it easier to do, provide
> a transition path toward, and get pinning, certificate checking, and
> revocation list checking integrated on hosts and cert generation/use
> integrated into clients?  And make it simple and easy for consumers to
> share their certs from multiple devices, reliably remove them from
> devices before loan or sale, and revoke-and-replace whenever one of
> their devices with a copy of their cert gets stolen?
>

I am not too familiar with pinning concept (does it apply at all to the 
client side?). I prefer first party certification where any service 
provider maintains its own database of trusted public keys (along with 
the bank account number, hospital patient file index, or whatever 
socio-legal convention for entity name applies).

I have a scheme for user enrollment with this first party certification 
concept, but that's may not be applicable as a mass market solution 
since the other aspects are unresolved.

Anyway in this view the user cares about the PRIVATE key, finds ways to 
carry it between devices (admittedly easier said than done), and 
self-issues certificates at will.

The educational challenge is enormous since almost every security expert 
has been trained (more or less implicitly) to relegate the PRIVATE key 
protection issue as a minor system configuration management duty (to be 
isolated from the user mental model). How many security experts ever 
tried to explain (e.g. to a computer-literate user audience) the very 
foundational principle of public key digital signatures?

-Thierry Moreau

> 				Bear
>
> * "half-fast" is the earlier form, as in tying something down with
>     loose or wrong knots so it wasn't actually fastened (made fast);
>     But it sounded like "half assed", and as 'fast' to mean secured
>     has fallen out of use we rarely see the earlier form anymore.
>     It seemed appropriate in this case to recall that 'fast' used to
>     mean 'secure.'
>
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>