David Waite <mass@akuma.org> writes:
> Just to make the question more explicit - the CA and client
> certificate options are limited by Neon 0.24. I can get PEM support
> in for client certificates by using openssl directly, but IMO it isn't
> worth it. The ssl-authorities-file limitation may be overcome by
> trusting the default CAs (I need to look more into what this really
> does); it may also be possible to support the existing semantics using
> openssl directly.
>
> I'm in favor of reducing options, so always trusting default CAs (if
> possible, and if these can be specified at the machine and user level)
> and only support PKCS#12 formatted client certificates seems like a
> good idea for me. $DEITY knows that there are other options which
> would be useful (such as trusting server certs by thumbprint, a la
> SSH) which will complicate things right back up.
David and I had a chat about this stuff, and here's our conclusions
(and David's list of action-items):
* svn will -not- be making direct calls to openssl. way too complex.
* the 'ssl-authorities-file' variable used to point to a file
containing a list of trusted CAs. But neon doesn't work that way
anymore; it wants a single CA per file. So David is going to make
our config variable take a semicolon-separated *list* of
file-paths. That prevents us from losing functionality when we
switch to neon-0.24.
* there's really only one kind of client certificate, but at least
two different disk formats for them. Neon has dropped support for
the .pem disk format, so subversion must as well. Not a big deal,
really. Openssl has tools to convert a .pem file to the one
format we support (pkcs#12). This means we get to *lose* two
config variables -- "ssl-client-cert-type", and
"ssl-client-key-file". And we get to lose an extra cert-type enum
in svn_auth.h. Yay, smaller code.
Once David makes these changes to the neon-0.24 branch, we can merge
them to trunk and be done with this issue. We should then be fully
neon-0.24 compatible, with no loss of features.
(In a *separate*, future issue, we plan to add new SSL
features... like the ability to cache specific server certs, or the
ability to trust whatever "default trustable CAs" that users may have
installed into their copy of openssl. But that's another topic.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 26 20:42:00 2003