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

Henry Story <henry.story@bblfish.net> wrote on 07-12-2013 08:59:28:

> 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-proofsolution.

+1
 
> We have an independent reason to want to signal the existence of 
> WebID and that is covered in 
> 
> "ISSUE-62: null certificate_authorities list"
>  http://www.w3.org/2005/Incubator/webid/track/issues/62
> 
> 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={}

-1000

During TPAC2012 I already expressed concerns for this approach.
I run IBM Domino which acts both as a mail, application and directory 
server.
I've managed to attach a WebID to my account with the certificate chain ( 
self signed ) of my company.
If I would have to adopt the above principle, I would have to recreate the 
whole certificate chain.
Furthermore everything that is signed will need to contain WebID in the 
certificate chain.
If you look for a way to prevent wide adoption, then do this.

Back then I already explained that creating WebIDs from e.g. a AD-server 
could be straight forward.
But I really doubt any large company looks forward to resigning and 
recreating all its directories just becuase of WebID.

Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen

##############################################################
# twitter: @semanticfire
# netage.nl
# http://netage.nl
# Enschedepad 76
# 1324 GJ Almere
# The Netherlands
# tel. +31(0)36-5347479
##############################################################