Re: certificate-authorities in CertificateRequest

On 12 Oct 2012, at 11:27, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:

> Hi Henry
> 
> the problem is a large one that, from a quick scan of the web, seems to effect more TLS users than just WebID. Essentially it is a scalability problem, since the current way of filtering, using the DNs of trusted CAs, is not scalable. Another mechanism is needed.  But this will be very time consuming since it will require the IETF to standardise a new extension e.g. based on the "type" of CA.
> 
> Your proposed solution of "standardising" a CA DN to be used in the TLS negotiation is an appropriate one, given the current limitations of the filtering mechanism. But doesn't this mean that every WedID self signed client cert will need to have an issuer field containing this standard DN rather than the DN of the user?

It, or I suppose one of the signers in the chain, right?

> 
> Or if the client cert is signed/issued by a real CA, then the root CA of this chain will need to say that its issuer is this standard DN rather than the current root? Which on the face of it might seem to rule out the use of commercial CAs.
> 
> Perhaps a solution to the latter problem, is that you/W3C/WebID issue a single self signed root CA with the standard DN, and then issue a set of subordinate CA certs that say the issuer is the standard DN, and the subjects are the subordinate CAs of the existing commercial root CAs. ie. you create a new hierarchy with a WebID CA (with the standard DN) being the root CA of all existing commercial CAs (or at least the ones that WebID users use).

This is close to the lines along which we were thinking. But with a twist...

The problem with the way you put it, is that the W3C would have to become a Certifier for 
all Root CAs, and of every group that wanted to become a client certificate provider. 
This would cause a bottleneck, as the W3C would have to have someone do some type of 
verification procedure that people could take seriously. Unless of course we made the 
private key available for the CN=WebID,O=W3C so that everybody could then go sign their 
own keys. I imagine that just the thought of this is sending goosebumps across the whole 
body of any security specialist. :-)

But my feeling is that there is something to this. What is publishing the private key of
a certificate other than essentially claiming it has no importance at all? So why even
bother with the certificate: all we need is the name.

As I understand, CA certificate verification procedure goes like this: A verifier
receives a to-be-verified certificate chain. It starts with the leaf one, and walks
up the signature chain until it finds a certificate signed by a CA it trusts. It 
verifies the signature and returns the answer of that verification. It need not
go any further up the chain, since anything further up the chain is already verified.

So here is the solution for any chain that wishes to signal its WebID compliance:

    make the root of your chain specify that it was signed by CN=WebID,O=W3C
   
With this we should have the following scenarios:
  a- Usual CA verification procedures will iterate through the chain and either
    + find a CA they have in their TrustStore and so stop with a success or failure
    + or reach the root certificate signed by CN=WebID,O=W3C and fail because they won't
      have that in their trust store
  b- WebID verification does not walk the certificate chain so it has no problems there
    (If WebID wanted to also get CA verification as a bonus, it would be in the situation 
    (a) above )
 

So having written this out, I think I have convinced myself that this is a good 
idea now.  If that is correct, what should the DN be? It should be short. Could
it just be CN=WebID ? If we want to add an organisation should it be W3C? (I was 
thinking GOD, would be a good one too, because essentially it is the CA of all
self signed entities. But W3C is pretty close to GOD I hear ;-)



> Its simply a type of cross certification. I dont know how browsers will work if they find a CA has two issuers. In theory it should make no difference because cross certification is a standardised procedure. Tree walking down from the new WebID trusted root should work just the same as now (although tree walking up from a leaf may cause problems when a fork is reached.) The only way will be to "suck it and see"
> 
> regards
> 
> David
> 
> 
> On 12/10/2012 09:15, Henry Story wrote:
>> I have re-opened ISSUE-62 on certificate-authorities list [1]
>> 
>> Currently the  WebID spec
>> 
>>   http://webid.info/spec/#requesting-the-client-certificate
>> 
>> suggests that the server requests the null certificate-authorities list.
>> This means that the end-user is asked to select all certificates available
>> in his browser. As it happens at present for most users there will be
>> none chosen, since most users don't have any, or very few as the author of
>> the Android API argues in the message in bug report 38393 below.
>> 
>>  But things could change and users could end up having more than 1,
>> and in Europe certificates are more widely spread. If they have more
>> than 1 certificates it would be very helpful if a server could request
>> certificates that were WebID enabled, so that the user did not mistakenly
>> send a traditional certificate that the WebID enabled server could do
>> nothing about.
>> 
>> I think this was an issue Ben Laurie meant to bring up recently when he
>> discussed the number of certificates we have to choose.
>> 
>>   So the only technical solution available to us at this time, is the
>> certificate_authorities selector in a request, and to have this set
>> to some DN that signals a WebID enabled certificate.
>> 
>>    Would this work? What could we have this DN be?
>> 
>>    CN=WebID,O=W3C
>> 
>>    perhaps? Are there tricks one could use so that even actual CAs could
>> add that DN to their chain?
>> 
>>    I am asking for technical answers here please, not for rants about
>> how TLS's failings. If this can get to work and be reasonably popular,
>> it will be incentive for future versions of TLS or future protocols to
>> improve this part of the protocol.
>> 
>> 
>> On 12 Oct 2012, at 09:19, Anders Rundgren <anders.rundgren@telia.com> wrote:
>> 
>>> Google's take on certificate selection:
>>> 
>>> http://code.google.com/p/android/issues/detail?id=38393
>>> 
>>>  "I designed the API with the intent that filtering could be added later if necessary,
>>>   but I've never been convinced that users really are going to have large numbers of keys.
>>>   What I said about issuer filtering really is true. It almost always is configured wrong if at all.
>>>   If you can motivate a use case, I'm all ears"
>>> 
>>> -- Anders
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 

Social Web Architect
http://bblfish.net/