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

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.

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