W3C home > Mailing lists > Public > public-webid@w3.org > December 2013

Signalling WebID Certificates - the CN=WebID, O={} CA

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 7 Dec 2013 08:59:28 +0100
Cc: Stéphane Corlosquet <scorlosquet@gmail.com>, Andrei Sambra <andrei@fcns.eu>, public-webid WebID Group <public-webid@w3.org>
Message-Id: <593346BC-E364-4A8F-A98A-E84F2A933C0B@bblfish.net>
To: Anders Rundgren <anders.rundgren.net@gmail.com>

On 3 Dec 2013, at 07:42, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> Hi Guys,
> I took a peek in this document:
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
> FWIW, I want to provide some input on this.  I believe that X.509 user authentication will become a major activity but not in the way it was "meant" [using TLS CCA (Client Certificate Authentication)].  How can I be so sure about that you may [rightfully] wonder?  Well, to begin with the majority of eID networks today do not actually use TLS-CCA, but rather rely on non-standard "plugins".
> There are some pretty good reasons for that:
> http://webpki.org/papers/PKI/webauth.pdf#page=1 <http://webpki.org/papers/PKI/webauth.pdf>
> Using "plugins" is of course not great (they will actually soon be "outlawed"!) so therefore Google has created something called U2F (Universal Two Factor) authentication which like the plugins and WebAuth works on the application level rather than on the transport level.  This will be the final nail in the TLS CCA coffin.
> Fortunately this in no way makes WebID redundant!
> However, I would consider another solution for "signaling" a WebID since WebIDs differs in one respect from most (if not all) other X.509-based user authentication schemes by not mandating a known CA.  A specific extended key usage WebID-flag would be fine and would not be in conflict with anything out there.  Assigning new semantics to existing definitions like SubjectAltName is not a fully future-proof solution.

We have an independent reason to want to signal the existence of 
WebID and that is covered in 

"ISSUE-62: null certificate_authorities list"

The problem with the server requesting a client certificate with
the "null certificate authorities list" is that 
it means that the server will accept ANY certificate.

But this is usually not the case.

As a result of the client being requested the certificate using the 
"null certificate authorities list" the Web Browser may offer the user
a list of certificates many of which may not be signed by any known
CA  _and_ that is not WebID enabled either, leaving the server to 
have to reject the certificate. And it is not always possible to do that
for the server once he has accepted the certificate. It would also make
the interaction with the client very bizarre, as the client would offer
the user a number of certificates to choose from, many of which would
keep getting refused, with little explanation.

I think the best solution I have found to this for the moment is for us
to signal a WebID signed certificate by having it be signed by a "Self 
Signed" DN perhaps the 

    CN=WebID, O={}

I know this works when signing a certificate directly with that DN.
But I have not yet tested to see if that works with certificates
chains signed that way. I suppose it should.

The advantage of this is that a client could then request the
certificate list including CAs he trusted AND WebID certificates.

We have not yet come to a consensus on what the name should be.


> Cheers
> Anders

Social Web Architect
Received on Saturday, 7 December 2013 07:59:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:52 UTC