On Wed, 28 Aug 2002, Cris Bailiff wrote:

> You're welcome. I'm sure you'll do the 'right thing' after careful
> consideration.

I've been going over these details in my head so many times now I'm all
dizzy! ;-)

> Mozilla has a newer CA list embedded within it (in the nss stuff), which
> can be 'exported' or accessed directly in the source:

[snip]

> I guess this file is clearly MPL/GPL licenced, and you would need to
> consider compatability with libcurls licence collection

They don't get along. Or rather, they do get along pretty nicely, but then
all the users of curl and libcurl will get some new interesting side effects
and another lap in the license round-about that we and they don't want.
Basicly, the *PL licenses need to be kept outside (GPL, LGPL, MPL, NPL any
more?). (You'll also see curl drop the MPL option in its license soonish.)

> but it's been generated from other data by someone at some stage as well.

Right, so if we get our hands on the/a tool that extracts that kind of data
from browsers, that would be the coolest and offer people greater freedom
and independence of what we or others deliver.

> The information itself, though, is arguably in the 'public domain' - it is
> a list of 'public keys', wilfully and vigourously distributed by the CA's
> who made them.

For the moment I'm assuming that we can use the package without problems and
I'm setting up configure, make install stuff etc to get this to work. I'm
sure I'll miss lots of things we'll sort out when I can get the next
pre-release out.

> Certainly portably installing and re-finding the bundle might be a bit
> tedious, but other software manages it OK (see above). I guess a configure
> option for the user to specify wouldn't hurt either (they might choose a
> cert store they already have, like /usr/local/ssl). (An option to choose
> the default store to be a cafile or capath might also be nice :-) )

Right. Options to:

1. disable the installation of curl's bundle
2. put it on a custom place on install
3. use another specified CA bundle package
4. whether the path in 3 is a directory for capath or a file for cafile

I think I'll save option 4 for later and only use cafile right now.

> > I don't see that as much problem, as any libcurl-using program could
> > always just set CAPATH or CAFILE to point to the CA cert of their choice.
> > In fact, they should do that and not blindly trust whatever we would go
> > ahead and install for them.
>
> OK - this means a library API change (to call setting a CA bundle).

I can't see why this requires an API change.

> Perhaps the choice to setup using the default curl CA bundle could be
> another flag to curl_global_init. (It does seem lonely with only 2 at the
> moment).

Well, that could be an option if we changed the *DEFAULT to use this option
and we hope that most people use this... I can't really see why we would like
to have this a curl_global_init() option though.

> One final issue worth considering: If you set up a default store, make sure
> it's initialised during the first request, rather than when setting up the
> curl handle. If a user specifies a different cafile, openssl will load and
> add it to the certificates it has already loaded - it doesn't normally
> replace the old certificate store. This would mean it would be impossible
> for a user to decide *not* to trust the certificate supplied with curl, but
> only to trust 'extra' certs on top of those supplied.

I'm not following you here. I was thinking to do it more like this:

By default, have 'cafile' point to "/our/default/installed/ca-cert". If a
CA-related option is used, we changed the pointer to whatever is decided.

Then we use that 'cafile' path to the SSL_CTX_load_verify_locations() to
verify the peer.

I don't want the default installed certs to always be used in addition to the
ones pointed out by the user, as it would give our installed CA bundle too
much power, imho.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390