Bruno.Harbulot at manchester.ac.uk
Tue Aug 10 20:20:49 CEST 2010
I agree with your overall goal and your demo looks neat. However, I
think there are a few security issues with that approach (comments below).
I think the problems you describe are not limited to the category of
users who can't make the difference between downloading and streaming
audio, it's wider than that. We've seen similar reactions and confusion
(with traditional PKI) with users who are postgrads or postdocs and
rather technology savvy in general. The confusion due to pop-ups and
various technical messages is there, and it's rarely the user's fault.
WebID has the advantage that it simplifies the PKI registration process
considerably, but it doesn't solve everything, as you point out.
We have to remember that security and authentication, however necessary
it may be, always stands in the way of what the user wants to do, so
you're right, it's important to simplify this as much as possible.
On 09/08/10 04:52, Manu Sporny wrote:
> On 08/08/2010 06:16 AM, Henry Story wrote:
>>> 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.
>> Ok, but it is not really a big deal to deal with, as that ActiveX
>> component comes
>> with the Operating System. So from the users perspective there is no big
>> issue there. From the coders perspective it is not such a big issue.
>> It am not sure how long IE will be before it integrates<keygen>
>> either given that it is part of html5 now.
I'm not sure keygen will ever be supported in IE, even with HTML5,
considering that, as far as I remember, the people from MS on the HTML5
list clearly said they wouldn't implement it anyway, as they had
something better already.
>>> Our current thinking is to entirely abandon the native browser
>>> client-side certificate generation and selection mechanism because it is
>>> complicated and broken.
>> I think we have found that for all desktop browser certificate
>> creation is quite easy. Other than
>> Internet Explorer, which I think works, but does require more detailed
>> looking at.
> It's not clicking the "Create Certificate" button that I'm concerned
> about. It is the certificate selection screen and the fact that the user
> is provided a dialog that requires them to understand that they need to
> select a certificate to connect to a website. This is a really foreign
> concept to the vast majority of people that use the Web. It requires
> them to know about how WebID works, which is going to negatively impact
> WebID adoption.
It makes sense in principle. I'm not quite sure how it's meant to work
with a non-DigitalBazaar WebID. I've tried with mine and all I can see
is the RDF/XML.
Let's leave the serialization debate out of this thread, but are you
expecting all WebID providers to embed the Flash application? Can you
provide details regarding how the protocol works in this case?
(I guess this might be a matter of work-in-progress.)
>>> 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.
You're probably not too wrong on this, unfortunately.
> Flash only provides the raw socket interface, all TLS processing is
>> Does the browser certificate selection
>> mechanism open, or does the flash keychain get called.
> We haven't tested this yet, but the current thinking is that we
> misconfigured Apache and if the server requires optional client-side
> certificates, the browser certificate selection dialog isn't displayed.
> We still need to test this theory.
(As a side-note, I think the whole problem of initial request of the
certificate should go away when more servers support the new TLS
renegotiation extension. I'm not sure what the status is with IIS and
its underlying libraries, but Apache Httpd/OpenSSL have supported it for
a few months. OpenJDK 7 should support it too.)
>> Does flash have a keychain? Or are
>> you just creating a parallel keychain in code, and saving that to
>> your hard drive?
> Flash doesn't have the concept of a keychain, AFAIK. We're using Flash
> local storage to store the certificate. One positive side-effect of
> using Flash is that your WebIDs are all accessible to any browser that
> uses the Flash Runtime. So, Chrome, IE, Safari, Firefox and Opera all
> share the same Flash local storage. So, if you create a WebID in Chrome,
> the same WebID can be used in IE on the same machine.
I think there's a security issue there: I think with this model, your
WebID provider not only controls your public key, but it can potentially
read your private key, since it controls the Flash application which can
then gain access to where the private key is stored. That's something
that OS and browser-based certificate management prevents.
On the one hand, it's not such a big deal since the WebID provider
controls the public key anyway (and thus controls the ID).
On the other hand, it's a problem if you start doing verification by
using a higher level of assurance that simple dereferencing, i.e. as
soon as you start using the public key to verify that the user behind
the screen is using the service, not just their WebID (which is a
handle/identifier). Typically, if you start making things like payments,
you'll want at least to store the public key (or fingerprint) of the
user, so that, for auditing purposes, you can prove that it's not just
the WebID that came to your site, but it's the person who had the
private key for the public key at the time.
This is useful if you assume that, regardless of whether the WebID was
verified correctly, the private key for the public key you're presented
with is only controlled by the user. If the WebID provider can
potentially read (and retrieve) your private key, the you no longer have
More information about the foaf-protocols