On 8/9/13 9:51 AM, Hugh Glaser wrote:
This is great! Thanks guys. I normally really, really don't care about all that crypto stuff (it should all happen transparently), but I'm find all this interesting!So yes, I created a p12 (using http://id.myopenlink.net/certgen/ - you sometimes have to trust someone :-) ) and emailed.
Yes! And that's another subtle interesting point i.e., "you have to trust somebody or something, at some point" . Trust violation is very expensive and it adds natural checks and balances to the entire Web of Trust pursuit.
I am confident (!) that with Keychain things will be fine, but less sure about Windows. Opened it on a Windows box, and it seems to have taken the thing to heart and put it in some certificate management thing. I am a little uncertain what I should put at the URL (non-FOAF) I gave it - the final page gave me some options with micro data, RDFa etc - I am guessing I can just wrap any of them in <html><body> etc?
Yep!
Anyway, I can sort that. So now all (!!!) I really need to do is make my wordpress site look for the ID thing. Hmmm. Melvin, did you get any response to http://lists.w3.org/Archives/Public/public-webid/2012Aug/0041.html ? Or Kinglsey, what did you do on the server side of your photo?
In my case, I Just made an ACL based on a combination of the identity claims that I know are mirrored in the WebID bearing certificate. In the most basic sense, you can simply start with the basic WebID+TLS test which is part of the basic server side implementation. Thus, I would expect the WordPress plugin to perform aforementioned test.
BTW -- When you distribute pkcs#12 files, the receiving parties don't actually need to have any knowledge of the actual ACL that you use to protect the resources being shared :-)
Kingsley
Cheers On 9 Aug 2013, at 13:25, Kingsley Idehen <kide...@openlinksw.com> wrote:On 8/9/13 7:47 AM, Norman Gray wrote:Henry, greetings. [replying only on public-lod] Bit of an essay, this one, because I've been mulling this over, since this message appeared a couple of days ago... On 2013 Aug 8, at 16:14, Henry Story wrote:On 7 Aug 2013, at 19:34, Nick Jennings <n...@silverbucket.net> wrote:1. Certificate Name: maybe there could be some examples of ways to name your certificate.[...]That's why it should be done by the server generating the certificate. The details are here: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#the-certificateI appreciate the logic here, and can see how it works technically smoothly for the anticipated use-case (the one illustrated in the WebID video on the webid.info front page). I don't think that's enough, however, because I don't think I could convincingly explain what's happening here, to a motivated but non-technical friend who wants to understand what they've just achieved when I've walked them through getting their WebID certificate from (something like) the social service illustrated in the video. People understand what a username & password is (the first is my identity, the second is a secret that proves I am who I claim), and they understand what a door-key is (no identity, but I have this physical token which unlocks a barrier for anyone in possession of the token or a copy). The same is not true of a WebID. Making this a one-click operation is nice (and a Good Thing at some level), but just means that the user knows that it was _this_ click that caused some black magic to happen, and I'm not sure that helps. Therefore...2. With firefox, after filling out the form, I get a download dialogue for the cert instead of it installing into the browser. So I saved, then went into preferences and "import" ... which was successful with "Successfully restored your security certificate(s) and private key(s)". Previously, with my-profile.eu, this was automatically installed into the browser (I was using Chrome then). Though I guess it's better to have it export/save by default so you can install the same cert on any number of browsers without hassle. Still, it creates more steps and could be confusing for new users.In the case of WebID certs downloading the certificate is in fact silly as you can produce a different one for each browser. So that message is a little misleading. A good UI should warn the user about that.Thinking about it, and exploring the behaviours again this week, I'm more and more sure that the browser is a problematic place to do this work. _Technically_, it's exactly the right place, of course, and the HTML5 keygen element is v. clever. But it's killing for users, and coming back to WebIDs and certificates this week, and parachuting into this discussion here, I've been a 'user' this week. A 'web browser' is a passive thing: it's a window through which you look at the web. It quickly disappears, for all but the most hesitant and disoriented users; in particular it's not a thing which takes _actions_, or where you can store things. That means that the browser creating the key-pair, and storing the server-generated certificate, is literally incomprehensible to the majority of anticipated users. And even to me. I have an X.509 e-science certificate which needs renewing every year, and every year I stuff up this renewal in one way or another: the certificate isn't in the right place, or I try to retrieve the replacement with a different browser from the one which generated the CSR, or something else which is sufficiently annoying that I purge the experience from my memory. And I understand about certificates and the whole PKI thing -- someone who doesn't is going to find the experience bamboozling, hateful and stressful. It sounds as if Hugh is going to generate his users' certificates off-line and distribute them; I got a little warm glow when I generated a WebID certificate (offline) using Keychain Access (KA), and then another using Nicolas Humfrey's script, and imported it into KA; when the UK e-science CA (above) started using a downloaded Java webstart application to do the renewal requests, it was massively easier on my head, even though the application itself wasn't going to win any design prizes. In each case, there was a 'thing' -- a 'certificate' -- which I can see on my desktop and then store securely in my 'keychain', and I can comprehend that I should think of it as a 'passport' or 'identity card', since that's a familiar thing which, like the WebID, is a proof of identity which might give me access to things on various grounds. I'm willing to be persuaded (presuming I'm not on OS X and willing to let KA look after this) that my browser has a 'keychain' and that I have to put this passport/id-card in there and leave it there. I'm a bit uncomfortable with that, since I wouldn't want to leave my passport lying around where I can't see it, but if you tell me that's safe, I suppose I'll go along with that. The crucial thing here is that I can see this 'certificate' file sitting on my desktop, and I got that because someone gave it to me, or because I downloaded an application and pressed a button saying 'make me a WebID'. I then _did something_ with that certificate file, so I have at least some vague sense that I've _stored_ that certificate somewhere, in a way that is subsequently proffered by my browser. I'm happy to have my certificate in a 'keychain', because that sounds like it's an application which is designed to keep things safe. I think I'd still be unhappy keeping this 'in' my browser, because that feels like I'm storing my passport in a pocket attached to the glass of my window, which is obviously mad. I don't have an easy solution to this -- I can see all the problems with creating applications which users have to run to generate WebIDs, and regarding which they then have to be given follow-up instructions. But doing this in the browser, though technically neat and correct, may have killing UI/model problems, as described above (because of the invisibility and passivity of the browser in most people's conception), and these problems may make this the browser-generation route less successful in the end. ---- Codicil 1:In general, that brings up some thoughts for me, maybe here's the place to share them. It would be cool in browsers could bake the idea of a WebID into the persona/profile of the browser session. (ie. chromes profiles, and firefox has a profile plugin). Just allowing (by default, i guess) one WebID per persona. This way you are encouraged to manage different profiles at the browser level, rather than juggling a bunch of certificates with naming hacks to figure out which is which... ?You can contribute your feedback as bug reports to the browsers. A place to start is here: http://www.w3.org/wiki/Foaf%2Bssl/Clients#Further_User_Interface_IssuesOooh, they're awful. I just checked, and I submitted an Apple bug report about this -- detailing the awfulness and inadequacy of Safari's and Keychain Access's UIs here -- back in October 2008, which finally received "We are closing this bug since our engineers are aware of the issue and will continue to track it" in November 2011, and nothing since. *sigh* Codicil 2:Please let us know if you can think of improvements to the spec text, as we will be publishing it soon.Something I just noticed: In section 2.1.2 of tls-respec.html, the language feels a little rough. Can I offer: ...by using the HTML 5 keygen element. This element can be placed in an HTML5 form, where it acts as follows: just before it submits the form, the browser asks the Key Store to create a public and private key pair, and when it receives the public part of the key from the store, it wraps this in a key request, as part of the form it sends to the Service. The Service can then create a WebID Certificate, and return this to the Client to pass back to the Key Store; the private key never leaves the secure Key Store. This exchange allows the Server to make the decision about what the Certificate should say, and what the WebID should be, since it is probably in the best place to do so. The user experience for this Certificate creation is a one click operation. ---- I hope all this rambling is useful. Best wishes, Norman+1 In addition to the above, note that IE doesn't support <keygen/>. We had to make a .NET equivalent of a signed applet to create what (on the surface) looks like the normal <keygen/> flow. Having played around with many workflow scenarios over the years, we concluded that <keygen/> should simply be an option, but not the default. Hugh introduced a use-case that does actually reflect how many will be introduced to this concept i.e., the most tech savvy person in the friend network will generate WebID bearing certificates offline, and then distribute to other friends. The same thing will happen amongst family members -- something I've already experienced personally -- where the following workflow steps provided a solution: 1. I took a photo of the kids 2. I notified some family members about the photos -- via an email that includes pkcs#12 file attachments or download URLs 3. I let them know that seeing the photos requires clicking on the pkcs#12 file -- so that they can use it as proof of identity when viewing the shared photos 4. I shared the pkcs#12 password with them (phone, sms, separate email etc..) 5. done. -- 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
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
