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

Re: Client certificates.

From: mark benedetto king <bking_at_inquira.com>
Date: 2002-08-01 22:11:57 CEST

On Thu, Aug 01, 2002 at 03:18:08PM -0400, Daniel Berlin wrote:
> On Thu, 1 Aug 2002, Sander Striker wrote:
>
> > [...]
> > > Are you planning on using the config file to figure out what
> > > certs should be used, what CAs to trust, etc?
> > >
> > > OpenSSL already has a (complex) configuration mechanism of its
> > > own; maybe we can set up a trusted CA inside ~/.subversion, and
> > > do things that way? This may sound like more trouble than it's
> > > worth, but building our own PKI would be pretty complicated.
> >
> > Let's not confuse things here. We need:
> >
> > a) a means to hand neon a client certificate if the server asks
> > for one;
> >
> > b) verify the servers certificate.
> >
> >
> > These can be implemented seperately. AFAIK Dan Berlin is taking
> > on a.
>

I agree, and figured that that was the case, but wanted to make
sure it wasn't "a and b in a totally proprietary manner".

> Yup.
>
> > b is going to be a bit tougher. Brians suggestion
> > to reuse webbrowser cert stores is a nice one (especially on
> > windows).

As Mark Welch has pointed out, there's no one way to access browser
cert stores (and why single out the browsers? Aren't there other OpenSSL
cert stores on the system?). It would be very neat if users just
had One Cert Store. That would rock.

>
> I think it requires using the cryptoapi.
>

Yeah, that's what I think, too. I do think that the API would do
a lot of the work for us, though. Maybe I should look at the implementation
of the "openssl" command-line tool...

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 08:36:54 2002

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.