Re: certificate-authorities in CertificateRequest

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?

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

Received on Friday, 12 October 2012 09:27:40 UTC