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

On 21 Oct 2012, at 18:12, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 21 Oct 2012, at 15:26, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
> 
>> Hi Henry
>> 
>> On 20/10/2012 22: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".
>> 
>> I dont like the O=∅ for several reasons
>> i) it may confuse users
>> ii) it may break some implementations
>> iii) its not based on a valid DNS name
>> 
>> I prefer O=W3C.org  or O=W3.org because then you can be sure that no-one else can take the DN as W3C is responsible for the name space.
> 
> I don't really mind. If we agree already with the general solution then
> this is good.
> 
> The issue with W3.org is that it may confuse users, admins and others that 
> the W3 is signing. One could replace ø by {} for potentially breaking 
> applications.

Another option is just to have CN=WebID and nothing else. Would that be ok?


> 
> What other options are there? Is there a special DN for standards? Perhaps IANA is the
> place to look? Other ideas?
> 
>> 
>>> 
>>> ( 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 )
>> 
>> alternatively you could have O=webID.w3.org without a CN then it is clear that "webID" is going to sign the cert.
>> 
>> What are the requirements?
>> i) a short DN to minimise traffic
>> ii) a fixed DN to signify its a WebID CA/certificate
>> iii) a DN that cannot righfully be used by any other CA or cert issuer
>> 
>> It is for this last reason that I propose using a DN based on an Org name that is based on a DNS name of W3C.
> 
> Those are also good reasons, but they can create a confusion too. This is going
> to be an arbitrary choice. I am open to other ideas.
> 
> 
>> 
>> regards
>> 
>> David
>> 
>>> 
>>> 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/
> 

Social Web Architect
http://bblfish.net/