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

Hi all,

I believe that using "W3.org" (in any field) would be misleading, as it 
creates confusion about the certificate having "somthing to do" with W3C.

On the matter of using CN=WebID, O=∅, I think that some organization 
would like to make use of O=, as well as of CN. We should find a 
solution that is non-blocking for future users/uses. Let's take a look 
at the LDIF fields:

CN: common name

It refers to the individual agent (person's name, device name, etc.) for 
whom/which the cert has been created. Some CAs cannot reuse the same CN, 
so it must change for each cert that is issued. When performing WebID 
authentication, this field is displayed in the list of certificates. It 
should not contain information that is not pertinent to user when having 
to make a choice between multiple certs.

DN: distinguished name.

As the name goes, it refers to the name that uniquely identifies an entry.

O and OU: organization and organizational unit

They are the organization and organizational unit (or sometimes the user 
group) that the user is part of. One user can have one O, and multiple 
OU (different groups/departments).

DC: domain component

This refers to each component of the domain. For example www.google.com 
would be written as DC=www,DC=google,DC=com.

I suspect that DC is used in the process of certificate validation. 
Since in WebID trust is established by dereferencing the 
subjectAlternativeName value (and not by certificate validation), the DC 
field would not really serve its initial purpose.

Therefore, I propose that we re-purpose this field (DC) to contain "WebID".

As a side note, this is what I usually see when I login using WebID:

Andrei Vlad Sambra
-------
Issued to: CN = Andrei Vlad Sambra

Serial Number: 00:FF:D5:DE:C6:E3:E0:DE:37
Valid from 4/16/12 3:19:19 PM to 4/14/22 3:19:19 PM
Issued by: CN = MyProfile
OU = MyProfile
O = MyProfile
ST = Essonne
C = FR
-------

I strongly believe that CN/O/OU/DN should not contain any information 
other than what they are supposed to contain.

I think we can discuss more about this during TPAC.

Best,
Andrei


On 10/25/2012 08:03 AM, 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 08:32:41 UTC