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

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

From: Dominik Tomaszuk <ddooss@wp.pl>
Date: Sun, 21 Oct 2012 00:18:29 +0200
Message-ID: <50832335.3070605@wp.pl>
To: Henry Story <henry.story@bblfish.net>
CC: David Chadwick <d.w.chadwick@kent.ac.uk>, Ben Laurie <benl@google.com>, public-webid <public-webid@w3.org>
On 21.10.2012 00:11, Henry Story wrote:
>
> On 21 Oct 2012, at 00:00, Dominik Tomaszuk<ddooss@wp.pl>  wrote:
>
>> On 20.10.2012 23:47, Henry Story 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".
>> +1 for CN=WebID and -0.5 for O=∅. It probably will be more safe to use the ASCII character. (I know that Unicode is ubiquitous).
>
> I think it does not matter that it is unicode. Servers and clients only do byte
> comparison I read ( please verify). The advantage of the unicode is that if a human
> looks at a client certificate in the browser they will see Org=∅ and that
> should help them understand what is going on.

If he/she know what does the ∅ char means. I still think it is better to 
describe it in words.

>>
>>
>> Best,
>> Dominik
>>
>>>
>>> ( 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 :-)
>>>
>>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
Received on Saturday, 20 October 2012 22:18:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:37 UTC