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

On 21.10.2012 15:26, David Chadwick 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
Exactly. About that I mentioned earlier.

>
> 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.
+1

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

Best,
Dominik
>
>>
>> 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:58:13 UTC