[foaf-protocols] Fwd: XAuth critiques
Bruno.Harbulot at manchester.ac.uk
Wed Jun 9 15:01:18 CEST 2010
On 09/06/10 12:50, David Chadwick wrote:
>> Thinking more from the user side, if I install a cert via keygen and
>> then find it in two browsers, but not the third, I'll be a little confused
> agreed. So it does need to be common to all browsers. Imagine one
> browser uses C: and another uses D: how confusing that would be to
> users. The solution is to have a standard PSE (Personal Security
> Environment) in which private keys and self signed root CA keys are
> stored. Public key certificates can be stored anywhere, so the user
> should be able to choose a file directory and all browsers should be
> configurable to look there for PKCs.
That could work, but I just wonder how you'd see that standardized
This more or less already exists in Java. Via the Keystore abstraction,
you can already use JKS (custom Java), PKCS#12 (slightly different
because it's cert + private key in fact), PKCS#11, NSS (Mozilla format,
but cannot be used concurrently with Firefox, I think), Keychain on the
Mac. I don't know if there's something to talk to Windows's store, but I
wouldn't be surprised.
It's a rather good abstraction, in particular because PrivateKey is an
object that represents the concept rather than the content of the key.
In the case of a PKCS#11 back-end you can't always get the private
exponent out of an RSA key, but you can still use it.
I guess there are other abstraction layers (and after all, PKCS#11 is
itself a layer of abstraction on top of other certificate and key
repositories). Maybe PKCS#11 is the solution? There are software
implementation too after all.
I think the problem with this is to get the vendors to agree to the
standards. It's not obvious because the existing solutions have features
that are often very specific to the OS and cannot necessarily be
For example, if I use a privKey+cert from my keychain for client-cert
authentication to a remote server, OSX's keychain mechanism will ask me
whether I want to allow the private key to be used for 'signing'
(there's a slight flaw in that UI in that it doesn't ask which key is
used or what is being signed). However, if I use Safari (or something
that uses TLS via the CFNetwork API of OSX), the UI will ask me whether
I want to allow that private key to 'connect' to the remote party.
This is because the CFNetwork and the keychain in OSX make a fundamental
distinction between private key usage in TLS and for other purposes
(although ultimately, it's about signing indeed).
There are also notions of locking the keychain when you close down the
lid of your laptop, etc.
It would be good to have a common layer, but I reckon vendors have too
specific differences in their technologies at the moment.
> One problem is that browsers, people, and even technical gurus refer to
> private keys as certificates. They are not, They are separate, and
> should be treated as such
That's true. I think experts know what they mean when they say it,
The fundamental problem with use of certificates is to explain this to
non-technical users. It would be problematic if people started to send
their friends their p12 files if they were asked to send their certificates.
More information about the foaf-protocols