[foaf-protocols] Fwd: XAuth critiques

[Bruno Harbulot]

Hi David,

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 
across browsers.

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 
abstracted easily.
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, 
though ;-)
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.


Best wishes,

Bruno.