[foaf-protocols] WebID breakthrough - pure Javascript+Flash implementation

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Tue Aug 10 20:20:49 CEST 2010


Hi Manu,

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
> performed in Javascript. So, the Javascript can do whatever we want it to.
>
>> 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 
these guarantees.


Best wishes,

Bruno.



More information about the foaf-protocols mailing list