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

I think I forgot to explain what the point of this proposal was:

  A server needs to have a way to help pre-select the certificates a client
can choose from, so that the user does not select by mistake a certificate
that the server does not know how to verify. TLS has a very minimal system
to do this based on DNs. We would like to add the ability to do this for
WebID certificates: i.e. specify at the protocol layer that a server accepts
a WebID cert.

On 21 Oct 2012, at 01:09, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:

> Hmm. I expect I may be in a minority here, but...
> 
> I'm not fond of baking DN requirements into WebID at *all*. It means that, unlike today, it's not possible to have certificates which are both WebID-compatible and also used for some other purpose.

Why so? 

> It also seems like a horrible hack.

This is the only means made available by TLS for a server to select a certificate. Anything else
would take years to implement.

> 
> I can't help but think that if you really want a way to identify WebID certificates, it should be done backwards-compatibly: *for example*, a non-critical extension with a dummy payload and a matching TLS extension to ask the UA to filter the list of certificates to those containing a particular extension (which I suspect could see broader application…)

That would not help immediately. The problem we are trying to solve is not the problem of identifying WebID certificates, but of allowing the part of the TLS protocol dealing with
CertificateRequests to work. The empty array of certificate-authorities means the client
can ask its user to select among all of his certificates. This is useful for certificate debugging applications. But usually the server specifies which certificate authroities he recognises.
We want to add to that the possibility of saying we accept the US Army certificates, Bank certificates and WebID certificates. 

If we can get the TLS folk to implement a better selection protocol, then we can remove that MUST.
But I guess that would take years and years before anything like that would be worked on, let along implemented.


> 
> M.
> 
> On 20 Oct 2012, at 22:47, Henry Story <henry.story@bblfish.net> 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".
>> 
>> ( 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 )
>> 
>> 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 :-)
>> 
>> 
> 
> --
> Mo McRoberts - Technical Lead - The Space
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------

Social Web Architect
http://bblfish.net/