- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 21 Oct 2012 12:35:40 -0400
- To: public-xg-webid@w3.org
- Message-ID: <5084245C.8060401@openlinksw.com>
On 10/20/12 7:09 PM, Mo McRoberts 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. It also seems like a horrible hack. > > 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…) > > M. +1 Kingsley > > 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. > ----------------------------- -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Sunday, 21 October 2012 16:36:03 UTC