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

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.

>
> ( 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.

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 :-)
>
>

Received on Sunday, 21 October 2012 13:26:32 UTC