dlongley at digitalbazaar.com
Tue Aug 10 22:37:08 CEST 2010
I just joined the mailing list to my apologies that this message won't
go in-thread. I had Manu forward me the thread.
On 08/10/2010 03:49 PM, Manu Sporny wrote:
> -------- Original Message --------
> Subject: Re: [foaf-protocols] WebID breakthrough - pure
> Date: Tue, 10 Aug 2010 19:20:49 +0100
> From: Bruno Harbulot<Bruno.Harbulot at manchester.ac.uk>
> To: foaf-protocols at lists.foaf-project.org
> 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.)
We wouldn't expect all WebID providers to embed the Flash application,
only those that wanted to support this method of creating and managing
WebIDs. It is definitely a work-in-progress, but here's a basic overview:
1. A web service that supports WebID login (a Verification Agent)
provides the option to use a JS+Flash Web ID provider via a login web
page. This option might only be available if a Web ID certificate was
not already provided via a browser UI.
2. The user, via their browser, enters the URL to their JS+Flash Web ID
provider or selects it from a list of supported/well-known Web ID
providers (ie: similar to OpenID).
3. The server loads the Web ID provider URL in an iframe which displays
the Web ID provider's custom UI for selecting a Web ID. This UI can be
custom-tailored in a number of ways. It could be simple and just allow
you to pick a Web ID you've previously generated (via another page on
the Web ID provider's site). It could provide a button to generate a new
Web ID if one is not available. It could require a password to unlock
your stored Web IDs if you're on a shared computer. It could allow you
to generate a one-time certificate for use on a public machine, etc.
There are many possibilities here that might solve some current issues
with Web ID.
4. Once a Web ID is selected, the JS loaded from the provider site will
create a TLS connection using the client-side certificate selected. The
TLS binary data will be transported using Flash's raw socket interface,
allows for Flash to be more easily replaced by another solution in the
future. At this point the interaction should be the same as if you had
used your browser to handle the certificate selection and TLS connection.
5. The server will handle the TLS connection, dereference the
SubjectAlternativeName Web ID URI, check public keys, and get RDF data,
etc. in the same way it would if JS+Flash weren't used. The response to
the TLS connection can set secure cookies (or send data in the response)
original web page, thus indicating that a user is logged in. This way
secure cookies can be used to handle authentication on every page
instead of requiring TLS client-side authentication to occur again
(which will happen on new TLS connections where no session support is
To generate a Web ID via JS+Flash:
1. You visit your Web ID provider's website and create an account. In
our demo we didn't both implementing this part because there's nothing
new about it.
2. You visit your certificate management page, which again, is very
customizable. From here you enter the details you want to be in your
certificate and click the generation button. This will create the
This could be replaced in the future using HTML5 features. Again, the
ability to lock the Web ID private key with a password (for use on
shared computers) could be added very easily here.
Now, when your Web ID provider's Web ID selection UI is loaded in the
iframe on a web service, you should be presented with your available Web
IDs. A UI might make it easier for users to know what Web IDs to use by
associating a nickname with them, etc. This way they don't need to
remember their Web ID url or similar. The power of this solution is that
developers can figure out how to best assist users with a good UI --
they don't have to rely on browsers to do that.
The Web ID provider, if they want to support JS+Flash, provides pages
that will load JS+Flash. These pages will be loaded via an iframe on a
web page served by a web service that supports JS+Flash Web ID (possibly
as a fallback for browser-based Web ID).
So the responsibilities of both parties to make this work are:
and provide UIs to manage Web ID certificates and select them for login.
It just needs to be included on the Web ID provider's site.
The Web ID service (Verification Agent) must provide a login page with
used/customized by sites that wish to support this. However, there is an
additional complication for Web ID services: cross-domain policy files.
There are several solutions to this problem:
1. The Web ID service opens a port to serve a cross-policy file that
enables Web ID providers to do cross-domain requests to their site.
2. The Web ID service, if using Apache, enables a module that will serve
a cross-domain policy file according to whatever they configure.
The cross-domain policy file issue is the most complicated/messy part of
this implementation, but it is solvable. I hope that some cleaner
solutions will arise in the future. I have some comments on the security
issues you raised below.
>>>> 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).
Yes, it is true that your Web ID provider can get access to your private
key. But, like you said, your Web ID provider controls your ID anyway.
> 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.
I believe that Web ID, necessarily, makes the assumption that any public
key that comes from a particular Web ID provider
for a particular URL is valid. What I mean by this is that the
assumption is that any information signed by the associated private key
should be considered authenticated using that public key. This means
that your Web ID provider can generate as many private and public key
pairs as it wants to without informing you that it is doing so. It can
then associate those keys with your Web ID URL since it controls that
URL. Therefore, your Web ID provider can make authenticated requests on
your behalf using a private key that it has kept all to itself anyway.
A Web ID provider can pick any public key they want to associate with
your Web ID URL. By inference, this means that they can also pick the
private key. That you happen to have a private key that you keep all to
yourself on your browser at home that *also* works is not relevant. They
will just generate and use a different one if they want to cause you pain.
> Best wishes,
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
Digital Bazaar, Inc.
More information about the foaf-protocols