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

Re: Proposal: DN="CN=WebID,O=∅" was: certificate-authorities in CertificateRequest

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 21 Oct 2012 12:35:40 -0400
Message-ID: <5084245C.8060401@openlinksw.com>
To: public-xg-webid@w3.org
On 10/20/12 7:09 PM, Mo McRoberts wrote:
> Hmm. I expect I may be in a minority here, but...
> I'm not fond of baking DN requirements into WebID at *all*. It means that, unlike today, it's not possible to have certificates which are both WebID-compatible and also used for some other purpose. It also seems like a horrible hack.
> I can't help but think that if you really want a way to identify WebID certificates, it should be done backwards-compatibly: *for example*, a non-critical extension with a dummy payload and a matching TLS extension to ask the UA to filter the list of certificates to those containing a particular extension (which I suspect could see broader application…)
> M.

> On 20 Oct 2012, at 22:47, Henry Story <henry.story@bblfish.net> wrote:
>> Here is my rough proposal now for ISSUE-59: "Filtering & Versioning WebID
>> Certificates" [1]
>>   A WebID Client Certificate chain's root MUST be signed by the agent with
>> DN "CN=WebID,O=∅" - the O= values is the utf-8 character U+2205 know as
>> "Empty Set".
>> ( We could put O=W3C but people would tend to think the W3C was going
>> to be responsible for the signature, whereas here it is clear that
>> there is NO organisation at all. )
>> ( I chose a very short DN, so as to minimise the traffic on the TLS layer )
>> Anyone can have the root of his certificate signed by that agent by making up
>> a public/private key pair and signing a certificate  with the generated private
>> key. In particular for services generating the equivalent of self signed
>> certificates they can give the user a certificate signed directly by that agent.
>> This will then allow servers to ask browsers for certificates from DN's
>> they know and trust as well as WebID based Certificates the user may have.
>> This should help reduce the size of certificates appearing in the selection
>> box  shown to the user.
>> A server that wants to ask the user for all client certificates can still
>> make the null request. This is useful for testing servers for example.
>> I don't expect us all to make requests for those DN immediately, but I think
>> we should work on agreeing on the WebID DN and make sure all certificates
>> created are generated with it, so that in the future we can allow servers to
>> select WebID certificates easily.
>> I'll be demonstrating this at TPAC. If we find that this works ok, I propose
>> we add language to the spec describing this requirement.
>> ----------------
>> I have tested this with my read-write-web server
>> https://github.com/read-write-web/rww-play
>> which I'll be putting online in the next few weeks hopefully.
>> For example the following class builds client certificates:
>> https://github.com/read-write-web/rww-play/blob/0f10d65ffc5048ae8a911b1b05896f5c55832b0d/app/controllers/ClientCertificateApp.scala
>> at line 134 on every VM startup the server creates a new public/private key with
>> which to sign the certificates it creates which will be signed by CN=WebID,O=∅"
>> When I then start my server with
>>> run  -Dhttps.port=8443 -Dhttps.trustStore=webid.WebIDTrustManager
>> and I go to a service such as
>> https://localhost:8443/test/webid/eg
>> then I am only asked for my WebID Certificates (now considered to be those
>> signed by "CN=WebID,O=∅"
>> This solves one of Ben Laurie's problems of being asked for too
>> many certificates, especially certificates that don't have WebIDs signed
>> by institutions the user knows nothing of.
>> I have not yet tried this on longer certificate chains.
>> Also I am looking to see if I can ask for the null resource depending on
>> the certificate
>> [1] http://www.w3.org/2005/Incubator/webid/track/issues/59
>> On 12 Oct 2012, at 19:22, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
>>> Hi Henry
>>> the first point to note is that signing CA public keys by the WebID root
>>> CA is not signifying any trust in the CA per se. It is merely signalling
>>> that this is the public key of this CA. Right? And because the root CA
>>> has already done this for you, then we can be sure it is correct, or else the root CA is a fraudster. But given that the root CAs' certs are already built into our browsers by MS, Apple, Mozilla et al then they have already done the validation for you. Right?
>>> The second point to note is that it is not the root CAs' keys which the
>>> WebID CA is signing, but rather the subordinate CAs of these CAs. This
>>> is because signature chain verification may not wont work if it comes
>>> across a self signed root CA key which is not the WebID CA (the root of
>>> trust). So by signing the keys of subordinate CAs of the root CAs built
>>> into browsers, we create an alternative path to the trusted root CA. Of course this makes the work load even greater than you imagined, since each root CA may have 3 or 4 subordinate CAs. But your proposal below will probably handle this.
>>> More comments below
>> Thanks for the feedback, but I think you did not quite see the radicality of
>> what I was proposing. I am not proposing that an institution have any keys it
>> can sign root CAs with, I am proposing anyone can create those keys and sign them :-)
> --
> Mo McRoberts - Technical Lead - The Space
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Sunday, 21 October 2012 16:36:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC