[foaf-protocols] Fwd: XAuth critiques

[Bruno Harbulot]

On 09/06/10 15:06, Breno de Medeiros wrote:
> General comment:
>
> Without implementing same-domain restrictions on certificates,
> certificate management without user interaction is a privacy problem.
> Certificate management with explicit user authorization/management is
> too heavy a UX, no matter how refined the browser implementation.

It looks from the points your making (derived from point 1 about SDE) 
that you're assuming that certificates would be used in these 
circumstances more or less like cookies are now, that is, each site 
would create (or have the browser create) a certificate specific for the 
site.
I think this is something we would want to avoid in terms of FOAF+SSL an 
global ID.

Having each site you visit ties its own certificate into your browser 
would undoubtedly be unmanageable (in particular for the reasons you've 
said before).
You'd also lose all the benefits of having global IDs. (It's a similar 
problem to tying too many pieces of information that are related to your 
ID but that are not fundamentally part of your ID to your certificate, 
which is what some CAs may do.)

Instead, you could have have a few certificates representing the global 
IDs you want to have and have servers "invite" you to log on (like they 
do now with passwords). There would be a choice a preference remembered 
in the browser, but which you could change.


There are currently problems that prevent this from happening.
It's not easy to have a log out feature with client-certificate 
authentication either from the browser or from the server. This would 
also let the user log on via another ID. At the moment, it depends 
partly on the TLS session lifetime and the fact the browser will keep 
the connection open. (It's not easy either, from Java for example, to 
have a servlet close the TLS connection to let the browser choose 
another certificate.)
These problems are amplified when we use an intermediary identity 
provider (for example for non-SSL service providers), since the browser 
may end up using the same IdP for different SPs for which the user would 
want to use different certificates.

I was trying to suggest a 401 "WWW-Authenticate: transport" or 
"certificate" (or something along those lines) a while back on the IETF 
TLS list. There was a mixed response. I must admit I haven't really 
pushed that much further: it ultimately depends on the (lack of) 
interest from the browser vendors.

Even without a new HTTP authentication scheme, things can already be 
done to improve the situation, with the existing specifications, in 
particular more control over the UI when using a client-certificate, 
more specifically, a log out button that closes the TLS connection and 
offers you to choose another certificate (or none) when reconnecting. 
This is currently doable but a bit tedious: the user has to go into 
preferences/options -> advanced -> ... and then 'Log out from Software 
security manager' (or similar).
Of course, this situation could improve with better support for TLS 
renegotiation (this new extension is starting to be available). After 
all, in principle clients and servers can initiate a new handshake more 
or less at any time (I'm not saying this should be done really at any 
time, as this would cause other problems.)


Best wishes,

Bruno.