W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

certificate-authorities in CertificateRequest

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 12 Oct 2012 10:15:22 +0200
Message-Id: <2E154EA4-F9F6-4FF3-BA8F-69DF6529CB9D@bblfish.net>
To: Ben Laurie <benl@google.com>, public-webid <public-webid@w3.org>
I have re-opened ISSUE-62 on certificate-authorities list [1] 

Currently the  WebID spec


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?


   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

Received on Friday, 12 October 2012 08:16:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:43 UTC