- From: Dominik Tomaszuk <ddooss@wp.pl>
- Date: Sun, 21 Oct 2012 00:18:29 +0200
- To: Henry Story <henry.story@bblfish.net>
- CC: David Chadwick <d.w.chadwick@kent.ac.uk>, Ben Laurie <benl@google.com>, public-webid <public-webid@w3.org>
On 21.10.2012 00:11, Henry Story wrote: > > On 21 Oct 2012, at 00:00, Dominik Tomaszuk<ddooss@wp.pl> wrote: > >> On 20.10.2012 23: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". >> +1 for CN=WebID and -0.5 for O=∅. It probably will be more safe to use the ASCII character. (I know that Unicode is ubiquitous). > > I think it does not matter that it is unicode. Servers and clients only do byte > comparison I read ( please verify). The advantage of the unicode is that if a human > looks at a client certificate in the browser they will see Org=∅ and that > should help them understand what is going on. If he/she know what does the ∅ char means. I still think it is better to describe it in words. >> >> >> Best, >> Dominik >> >>> >>> ( 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 :-) >>> >>> >> >> > > Social Web Architect > http://bblfish.net/ >
Received on Saturday, 20 October 2012 22:18:53 UTC