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

Hi Henry

given that you want any SP to be able to create these root certs, then 
that sounds like an OK idea

regards

David

On 25/10/2012 07:03, Henry Story wrote:
>
> 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/
>

Received on Thursday, 25 October 2012 09:16:26 UTC