On Sun, Oct 31, 2004 at 10:22:38PM +0200, Sigfred H?versen wrote:
> To my previous svnserve SSL patch, I've added authentication using client
> certificates. However, client management of certificates remains to be done
> and I'm unsure on how to proceed. More on that below.
>
> A SSL enabled svnserve will now accept clients that does not have that
> capability, or does not want to use it. An exception, of course, is
> authentication using certificates. If both svnserve and the client supports
> ssl, a SSL handshake will be done.
>
> A repo administrator will add users with certificates in a new section
> [certificates] in the svnserve password file :
>
> [certificates]
> username1 = <PEM encoded certificate>
> username2 = <PEM encoded certificate>
> ....
I think the way the config parser works, multi-line things like the
PEM-encoded certificate will have their newlines removed. This may
irritate the OpenSSL PEM parser. I suppose we could replace spaces
in the conf item with newlines before handing the cert off to OpenSSL.
What if you put the client cert's DN in there instead?
>
> I've added a new auth mech "SSL-CERT" that the server send when it wants the
> client to authenticate with a certificate. The authentication will only
> succeed if the client gives a valid username and certificate during the
> handshake. The authentication is done by checking that the client supplied
> certificate is signed by the corresponding certificate in password file.
>
> For the client certificate management there are two credentials that will be
> useful : SVN_AUTH_CRED_SSL_CLIENT_CERT and
> SVN_AUTH_CRED_SSL_CLIENT_CERT_PW. However, none of them supports caching.
> Since my client certificate authentication is a pair (username, certificate),
> it would be useful to have a "const char *username" member in
> svn_auth_cred_ssl_client_cert_t as well.
Can the server invert the mapping of user->DN and build a DN->user map?
(Or perhaps we should just store them that way in the password file)
Then the username wouldn't actually need to be part of the provider,
in fact, the client wouldn't even know the username!
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 01:39:56 2004