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

On 7 Dec 2013, at 16:41, Andrei Sambra <andrei.sambra@gmail.com> wrote:

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

yes, but what other solution do you propose?

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

yes, as I explain above. A server that requests the null certificate list, may receive certificates 
that are only meant to be used to authenticate  to one particular web site ( the way most 
client certificates are used currently, since most sites don't use CAs, nor WebIDs ) 
that don't have WebIDs at all, and so with which your server can do nothing. 

Let me add as background information about the TLS Spec:
http://tools.ietf.org/html/rfc5246#section-7.4.6
on Client Certificate

      If the certificate_authorities list in the certificate request
      message was non-empty, one of the certificates in the certificate
      chain SHOULD be issued by one of the listed CAs.

In section 7.4.4.  Certificate Request which describes the fields:

   certificate_authorities
      A list of the distinguished names [X501] of acceptable
      certificate_authorities, represented in DER-encoded format.  These
      distinguished names may specify a desired distinguished name for a
      root CA or for a subordinate CA; thus, this message can be used to
      describe known roots as well as a desired authorization space.  If
      the certificate_authorities list is empty, then the client MAY
      send any certificate of the appropriate ClientCertificateType,
      unless there is some external arrangement to the contrary.

Now there may be other ways to solve the problem. That is why I sent a mail 
to the current IETF TLS mailing list, to check if there were
other possibilities current or ones that were being prepared for
future specs.

Otherwise what is your answer to the problem?

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

This is the only issue being discussed currently on this working
group. I don't see what it has to do with spec publication.


> 
> Andrei
>  

Social Web Architect
http://bblfish.net/

Received on Saturday, 7 December 2013 15:56:42 UTC