kidehen at openlinksw.com
Sun Aug 8 16:14:24 CEST 2010
Manu Sporny wrote:
> On 08/07/2010 06:26 PM, Henry Story wrote:
>> There are a couple of your claims above that I think need a little
>> tuning or explaining in more detail.
>> First the claim that WebIDs cannot be created in Internet Explorer is
>> not quite true. IE has an Active X component that comes with the
>> operating system and that is available. Creating a WebID using IE from
>> http://webid.myxwiki.org/ should work, though as I don't have Windows
>> I don't test it that much to tell the truth. Bruno Harbulot wrote a
>> calls to that Active X component. The advantage of doing it that way
>> to be enabled on IE, but so does your solution :-)
>> Now the IE Active X solution may have some usability issues, but I
>> think it needs clearly pointing out what those issues are, so that
>> they can be understood clearly,
> I've tried to fix the language in the blog post to state that IE needs
> an ActiveX component to generate a proper certificate in IE.
Depends on what you mean by IE.
The issue is really Windows and the fact the Microsoft consider keygen
Keygen is considered unsafe because you can load a page from outside the
host Windows machine that makes critical alterations to the OS (access
to the Cert. Manager utility is one such example).
Microsoft wants software that works with the Cert. Manger to be signed,
hence the option to use a signed "one click" applet. This is the same
mechanism used across the board courtesy of .NET.
Henry: I don't sey keygen support in IE happening anytime soon, even
with HTML5 support, this is basically why we built our own Cert Manager
(as per my demos).
>> Secondly you say "you get the peace of mind that if you lose one of
>> your WebIDs, you can always just deactivate it via your WebID provider
>> and generate a new WebID". There is in fact a better way still: you
>> can keep your WebID, and just remove the public key from your public
>> profile. In fact you should be able to have any number of public keys
>> associated with one WebID.
> Hmm, that's what I meant to convey in the blog post, but failed to do
> so. I've fixed up some of the language to make the point you make above,
> and the one I was trying to make initially, more clear.
As per Henry's comments. I have many pubkeys associated with my WebID.
Thus, if I used a third party devices and forget my private key in
Firefox (for instance) or Keyring (Mac OS X) or Windows Cert. Manager,
all I do is go to my Personal Data Space and remove the public keys
associated with any of those user agents. In an absolute emergency, I
drop all the pubkeys (just simple deletes via UI) and make a new one for
whatever user agent I next use.
>> Now when I log in to digital bazaar it asks me for the WebID I already
>> have (I have a few in fact).
> We think that this is an Apache misconfiguration... we set client-side
> certificate support to optional, so we'll look into this a bit more
> early next week.
You should pick up the WebID of the visiting user agent.
Visit: https://id.myopenlink.net , using a user agent that has one of
your generated X.509 certs with WebID binding.
>> My browser -- Chromium -- asks me for my
>> client certificate, but then you don't use it! If this system should
>> allow me to use either my flash certificate or my browser certificate
>> this would be great -- if I have already submitted my browser
>> certificate then it should use that. So hopefully we can get it to
>> that point. Especially as me and many people have disabled flash - I
>> just reinstalled it for your site.
> Yes, I think that's quite do-able - shouldn't be difficult to
> accomplish. I'll talk with our engineering team and see what they have
> to say.
Yes, I demonstrate this in all my demos. These are the basic patterns
we've established via interop fests conducted so far by implementors.
>> What I think you have done is to have tied one more keychain into the
>> WebID system: the flash keychain. Flash is really a browser in a
>> browser. Now it would be even better if flash could use the browser
>> keychain, because then the same keychains could be used for logging in
>> from the browser and flash.
> Unfortunately, we don't currently know of any way of retrieving the
> across all browsers.
> Our current thinking is to entirely abandon the native browser
> client-side certificate generation and selection mechanism because it is
> complicated and broken.
This isn't a browser issue per se. Its about the Browser and the host OS
It is now even possible to have Firefox work like IE i.e. rather than
use keygen have it work directly with the Windows Cert. Manager. I'll
put out a demo soon that shows how we go for the OS PKI facilities first
and keygen second (where in this case its browser hosted PKI).
> The browser-based interfaces leave much to be
> desired when viewed from a regular website usability perspective.
Because this isn't a Browser issue. A Browser is just a piece of
software that runs within a host OS. Apple and Microsoft both grok this
very well and reflect it in their respective implementations of PKI
> the usability story better when generating and selecting a WebID
> Waiting on the browser manufacturers to improve their client-side
> certificate management UIs will take years. That doesn't mean that
> people wouldn't be able to use the browser-based certificate management
> mechanism for WebID, just that we think that approach is a dead end.
No approach is dead, we just have to understand that you have to deal
with PKI at two levels: Browser and Host OS. Just give the users options :-)
> -- manu
President & CEO
More information about the foaf-protocols