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

On Sat, Dec 7, 2013 at 10:29 AM, Bart van Leeuwen <
bart_van_leeuwen@netage.nl> wrote:

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

I am also against this solution. Companies may want to re-purpose
certificates within their IT infrastructure (whether it is classic
TLS-based authentication or WebID authentication), so forcing them to use a
predefined CN and O would be a bad idea.

I think the main reason why Henry was pushing for a predefined CN and O was
to filter out certificates that cannot be used for WebID-TLS auth. This,
however, is something we can discuss once we have published the current
proposed specs, so that we can work through the open issues one at a time.
:-)

Andrei


>
> 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
> ##############################################################