You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Berlin <db...@dberlin.org> on 2002/08/01 06:22:27 UTC
Client certificates.
So, since i'm going back to law school soon, which gives me plenty of time
to work on subversion, i started looking at the issues list.
And I noticed one thing listed as a wanted feature was client certificate
authentication.
Seeing as how i've been creating tons of certificates lately (don't ask),
i felt able to do this.
We only need to provide some callbacks for neon, and be able to provide
client certificates for it when requested.
Was anyone going to take this one/already done it but not submitted it?
If not, i can probably do the whole thing tomorrow.
:)
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 01, 2002 at 12:01:52PM -0500, Ben Collins-Sussman wrote:
>...
> So the *real* challenge of this issue is coming up with a nice way to
> store and manage certificates. I suspect that stashing certs in every
> single .svn/auth/ area (as we do with 'username' and 'password' files)
> isn't going to fly very well. Maybe a subdir within ~/.subversion/
> needs to hold them.
Dan suggested some config options (presumably in a file named something like
~/.subversion/options, formatted/read using our config parser) which would
point to where the certs are located. I can easily see that a default might
be ~/.subversion/certificates/ or whatever.
> But now I fear we're jumping the gun yet again; gstein had/has plans
> to write libsvn_auth, which would be a big reorganization of how the
> client manages credentials in general. Maybe that library should
> happen first?
Don't worry about it. To some extent, this could be a bit nicer in terms of
showing what might be needed for certificate handling. libsvn_auth will
simplify the code, but having Daniel do some of the legwork to demonstrate
what is needed will be good. For example, I wasn't aware of needing just a
password authenticator. That should work fine in the libsvn_auth framework
(as I'm currently seeing it).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Daniel Berlin <db...@dberlin.org>.
On Thursday, August 1, 2002, at 01:01 PM, Ben Collins-Sussman wrote:
> Daniel Berlin <db...@dberlin.org> writes:
>
>> We only need to provide some callbacks for neon, and be able to
>> provide
>> client certificates for it when requested.
>
> I didn't realize neon already understood certificate challenges -- I
> thought we were blocking on that feature!
>
> So the *real* challenge of this issue is coming up with a nice way to
> store and manage certificates. I suspect that stashing certs in every
> single .svn/auth/ area (as we do with 'username' and 'password' files)
> isn't going to fly very well. Maybe a subdir within ~/.subversion/
> needs to hold them.
Actually, I did it like proxies.
That way, wherever the heck they want to put the certs is fine, they
just tell us where it is.
IE we have an ini file (or registry, in the case of windows) in
.subversion with
[groups]
Apache = *.apache.org
[Apache]
certificate=/etc/myapachecert.pem
It doesn't make sense to make client certs an authenticator in and of
itself:
1. It forces certificate management to be done by the client,
entirely, for no good reason. If it's just an ini file, it can still
easily be managed by the client, but the client doesn't have to worry
about all the specifics and stuff behind the scenes.
2. Neon expects the certs to be loaded using neon's cert loading
functions. Thus, if the client manages certs completely on it's own,
it now needs to link with neon and use these functions.
3. There's no really good other way to manage certs anyway, so each
client will likely come up with something like an ini file anyway (or
registry, in the case of windows), each completely incompatible.
It's like forcing clients to manage proxy information entirely. It's
much easier to let them manage the ini file, and take care of the
details for them.
>
> But now I fear we're jumping the gun yet again; gstein had/has plans
> to write libsvn_auth, which would be a big reorganization of how the
> client manages credentials in general. Maybe that library should
> happen first?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Mark Welch <ma...@collab.net>.
Brian Behlendorf wrote:
>On 1 Aug 2002, Ben Collins-Sussman wrote:
>
>
>>So the *real* challenge of this issue is coming up with a nice way to
>>store and manage certificates.
>>
>>
>
>Is there any way we could use the same certificate store as the web
>browsers do? That might make it easier for end users...
>
You'd need to code to a number of libraries/APIs (CAPI, NSS) in order to
access browser cert stores. When I wrote the SSL sleeve we use for CVS,
I initially took the approach of exporting certs from browsers, then
importing them as PKCS12 files.
It isn't a matter of just reading certs out of a file and using them,
though of course it would be nice to do so.
--mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Brian Behlendorf <br...@collab.net>.
On 1 Aug 2002, Ben Collins-Sussman wrote:
> So the *real* challenge of this issue is coming up with a nice way to
> store and manage certificates.
Is there any way we could use the same certificate store as the web
browsers do? That might make it easier for end users...
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Ben Collins-Sussman <su...@collab.net>.
Daniel Berlin <db...@dberlin.org> writes:
> We only need to provide some callbacks for neon, and be able to provide
> client certificates for it when requested.
I didn't realize neon already understood certificate challenges -- I
thought we were blocking on that feature!
So the *real* challenge of this issue is coming up with a nice way to
store and manage certificates. I suspect that stashing certs in every
single .svn/auth/ area (as we do with 'username' and 'password' files)
isn't going to fly very well. Maybe a subdir within ~/.subversion/
needs to hold them.
But now I fear we're jumping the gun yet again; gstein had/has plans
to write libsvn_auth, which would be a big reorganization of how the
client manages credentials in general. Maybe that library should
happen first?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by mark benedetto king <bk...@inquira.com>.
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
RE: Client certificates.
Posted by Daniel Berlin <db...@dberlin.org>.
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.
Yup.
> b is going to be a bit tougher. Brians suggestion
> to reuse webbrowser cert stores is a nice one (especially on
> windows).
It's also a bit tricky.
I think it requires using the cryptoapi.
>
> Sander
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Client certificates.
Posted by Sander Striker <st...@apache.org>.
[...]
> 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. b is going to be a bit tougher. Brians suggestion
to reuse webbrowser cert stores is a nice one (especially on
windows).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 1 Aug 2002, Mark Welch wrote:
> Pardon me for chiming in here, but I've been working on an SSL sleeve
> for CVS for a while at Collab. So, while I'm coming up to speed on
> subversion, this seems like a good point for me to jump into the discussion.
>
> Daniel Berlin wrote:
>
> >
> > Which certs should be used.
> > What CA's to trust is a seperate feature request (IE something else's
> > job).
> > :)
> > We already have a callback, but we just say we trust everything.
>
>
> If you're talking about supporting certificates and you take
> certificates seriously, it is not "something else's job" to trust CA
> certs.
Please read exactly what i wrote again.
It's a seperate feature request, meaning, i'm not doing it, it's a job
for someone/something else.
If you want to do that, go for it.
But it's not what i'm working on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Mark Welch <ma...@collab.net>.
Pardon me for chiming in here, but I've been working on an SSL sleeve
for CVS for a while at Collab. So, while I'm coming up to speed on
subversion, this seems like a good point for me to jump into the discussion.
Daniel Berlin wrote:
>
> Which certs should be used.
> What CA's to trust is a seperate feature request (IE something else's
> job).
> :)
> We already have a callback, but we just say we trust everything.
If you're talking about supporting certificates and you take
certificates seriously, it is not "something else's job" to trust CA
certs. The problem here is the same as in web browsers -- you don't want
to force users to make a fundamental decision about trust, because they
will very likely get it wrong.
What I think this means in a practical sense is that it ought to be easy
for others (release engineers at companies using X.509 infrastructure,
for example) to rebuild svn installers on each platform with the CA
cert(s) they want to trust.
If there's a place where I can jump in and help with this, let me know.
--mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Daniel Berlin <db...@dberlin.org>.
On Thursday, August 1, 2002, at 01:21 PM, mark benedetto king wrote:
> On Thu, Aug 01, 2002 at 01:09:15PM -0400, Daniel Berlin wrote:
>>
>> On Thursday, August 1, 2002, at 12:37 PM, Karl Fogel wrote:
>>
>>> Justin Erenkrantz <je...@apache.org> writes:
>>>>> Was anyone going to take this one/already done it but not submitted
>>>>> it?
>>>>> If not, i can probably do the whole thing tomorrow.
>>>>
>>>> Go for it. =) -- justin
>>>
>>> +1 :-)
>>
>> Just a warning to those working on clients:
>>
>> I'm adding a password only authenticator to go along with the
>> user+pass
>> and username-only authenticators already existing in the ra layer.
>>
>> This is because encrypted private keys in certs only need a password.
>> Sorry that it gives you guys another thing to implement, but, I really
>> don't want to just ask for user+pass and ignore the username given.
>> Seems hackish.
>>
>>
>
> Are you planning on using the config file to figure out what
> certs should be used, what CAs to trust, etc?
Which certs should be used.
What CA's to trust is a seperate feature request (IE something else's
job).
:)
We already have a callback, but we just say we trust everything.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by mark benedetto king <bk...@inquira.com>.
On Thu, Aug 01, 2002 at 01:09:15PM -0400, Daniel Berlin wrote:
>
> On Thursday, August 1, 2002, at 12:37 PM, Karl Fogel wrote:
>
> > Justin Erenkrantz <je...@apache.org> writes:
> >>> Was anyone going to take this one/already done it but not submitted
> >>> it?
> >>> If not, i can probably do the whole thing tomorrow.
> >>
> >> Go for it. =) -- justin
> >
> > +1 :-)
>
> Just a warning to those working on clients:
>
> I'm adding a password only authenticator to go along with the user+pass
> and username-only authenticators already existing in the ra layer.
>
> This is because encrypted private keys in certs only need a password.
> Sorry that it gives you guys another thing to implement, but, I really
> don't want to just ask for user+pass and ignore the username given.
> Seems hackish.
>
>
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.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Daniel Berlin <db...@dberlin.org>.
On Thursday, August 1, 2002, at 12:37 PM, Karl Fogel wrote:
> Justin Erenkrantz <je...@apache.org> writes:
>>> Was anyone going to take this one/already done it but not submitted
>>> it?
>>> If not, i can probably do the whole thing tomorrow.
>>
>> Go for it. =) -- justin
>
> +1 :-)
Just a warning to those working on clients:
I'm adding a password only authenticator to go along with the user+pass
and username-only authenticators already existing in the ra layer.
This is because encrypted private keys in certs only need a password.
Sorry that it gives you guys another thing to implement, but, I really
don't want to just ask for user+pass and ignore the username given.
Seems hackish.
>
> -K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> > Was anyone going to take this one/already done it but not submitted it?
> > If not, i can probably do the whole thing tomorrow.
>
> Go for it. =) -- justin
+1 :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client certificates.
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Aug 01, 2002 at 02:22:27AM -0400, Daniel Berlin wrote:
> So, since i'm going back to law school soon, which gives me plenty of time
> to work on subversion, i started looking at the issues list.
> And I noticed one thing listed as a wanted feature was client certificate
> authentication.
> Seeing as how i've been creating tons of certificates lately (don't ask),
> i felt able to do this.
> We only need to provide some callbacks for neon, and be able to provide
> client certificates for it when requested.
>
> Was anyone going to take this one/already done it but not submitted it?
> If not, i can probably do the whole thing tomorrow.
Go for it. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org