[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

client ssl certificate authentication

From: David Waite <mass_at_akuma.org>
Date: 2003-02-09 00:22:08 CET

So its about time to start on the client SSL certificate authentication.
Before I start writing authentication providers, I wanted to make sure I
ran my proposal by the group:

The SSL client certificate support provided by Neon consists of two
functions and two separate registered callbacks.

The first registered callback allows you to get called when ssl client
authentication has been requested from the server. I figure this would
be the start of the authentication phase.

Once you receive this callback, you can call one of two methods; one
loads either a single .pem file or a set of .pem files, depending on
whether the public and private keys are separate. A separate method
allows you to load a single pkcs12 file.

The second registered callback will request the passphrase of the
private key (only if needed - the private key may not be encrypted locally)

So to get to the point - the multiple files and formats situation seems
too complex to expose via a prompting interface - I am thinking that the
authentication provider for this information needs to just read the
key-loading instructions from a configuration file. The passphrase will
use two authentication mechanisms for 'svn:password'; a storage
mechanism and a prompting mechanism.

Does this seem alright with people? Does it seem correct to have
~/.subversion/servers point to the location of the needed key files?
Where (and should) the passphrase be stored?

-David Waite

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 9 00:23:12 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.