- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 12 Oct 2012 10:15:22 +0200
- To: Ben Laurie <benl@google.com>, public-webid <public-webid@w3.org>
- Message-Id: <2E154EA4-F9F6-4FF3-BA8F-69DF6529CB9D@bblfish.net>
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/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 12 October 2012 08:16:03 UTC