Thanks to Karl for doing a good job making my case for me ;)
On Thu, May 08, 2008 at 05:19:55PM -0400, Mark Phippard wrote:
> I must be missing something because I do not see how this is any
> better. It would still rely on physical security otherwise someone
> could just grab your unencrypted cert and use it to impersonate you.
At the moment you can configure Subversion to use a client certificate
in PKCS#12 format in a file on disk. This client cert can be stored on
disk in (essentially) "plaintext" form; Subversion can use the clicert
to authenticate the user to a server as-is, without ever having to
prompt for any passphrase.
If you store the client cert on disk in that way, you rely on the
physical security of the filesystem, as you say.
If you do *not* trust the physical security of the filesystem, you have
a few different options for continuing to use client certs; one of which
is to store the client cert in encrypted PKCS#12 format, on disk.
Subversion would then need to prompt the user for the password before
being able to use the client cert. Because it is implicit that the user
does not trust the physical security of the filesystem in this case, it
would then be pretty silly to go and store that passphrase *in the
filesystem*.
Does this make sense yet?
Using PKCS#11 providers with SVN 1.5, you can solve the problem of not
trusting the physical security of $HOME in a couple of new ways:
1) using real hardware smartcards means you avoid storing client certs
in files at all
2) GNOME Keyring includes a PKCS#11 provider, and can handle client
certs in PKCS#12 format. So you can dump an encrypted PKCS#12 cert in
the GNOME Keyring, and configure Subversion to use the GNOME keyring
PKCS#11 provider. The first time SVN needs to use the client cert,
you'll get a GNOME dialog popup asking for the client cert passphrase.
Subsequently, it's cached in RAM and works automagically. This provides
an ssh-agent-like solution for SSL, which is pretty neat.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-09 10:41:44 CEST