Daniel Stenberg wrote:

>
>> In other words: If I have a global variable keeping track of the
>> number of times the call-back function was called, making the
>> callback function load the correct certificate only on the /third/
>> call, and loading a "dummy" certificate (synthactically correct, but
>> for the wrong domain) on other calls, and then query the same page
>> five times, then the first two queries will fail, and the third,
>> fourth and fifth query will succeed, and the call-back function will
>> be called exactly three times - until it loads the correct certificate.
>
>
>
> But why does it fail the two first times then?

The first two times a dummy self-signed certificate identifying a
different website was loaded - so failure was expected. The reason
I tried twice was to see if loading the same (wrong) certificate in
the "same" SSLCTX would lead to an error (for loading the same
certificate twice) - which, surprisingly, it didn't in this case.

If I take the standard certificate list (59 certificates IIRC), load that,
and then add CACERTs' certificate, I end up with a list of 60
certificates.
If I load the standard certificate list and then try to add a certificate
already present in this standard certificate list, this (of course) fails,
and I end up with a list of 59 certificates.
So adding the same certificate twice in the callback function EITHER
takes another code path not complaining about duplicate certificates
added through that route or (most likely) the same SSLCTX is
reinitialized before the second call, forgetting about the previously
manually added certificate.

Anyway, this is not an error, but can be viewed (depending on your
perspective) as a slight inconsistency in interface. I don't think that
anything needs to change though. My perspective on libcurl (and
openssl) is one of a documented black box with innards not to be
touched unless absolutely nescessary.

>> on a side note: would CACert's root certificate be eligible for
>> inclusion in curls' root certificate list? or is the policy to
>> include only what Mozilla includes?
>
>
>
> We don't have a policy for adding CA certs, so therefore it doesn't
> happen.
>
> We cannot include what Mozilla includes due to license reasons[*]. Or
> at least I don't want to distribute files using Mozilla's licensing in
> the curl release archive(s) since they would stand out as very
> different than the rest of the package. We do however provide a
> conversion service on the curl site that converts the most recent
> Mozilla certs to a format suitable for curl.
>
> So, the CA cert bundle in curl is slowly degrading over time.

clear.

>
> Sure, we could start adding CA certs to the curl bundle but when doing
> so, we should first decide on what requirements we have on new CA
> certs and on what grounds we accept/reject additions. So far, I've not
> been overjoyed at the thought of yet another task in a project I'm
> already up to my ears with work in already. I would of course sallute
> and hail all efforts from interested parties to help sort out this
> situation.
>
> I've previously read complaints on how CA certs are accepted or not in
> the Mozilla bundle, so I guess an alternative policy could be
> interesting. Of course, in the end, it will be subject for complaints
> too...

definitely.

I think there are two different perspectives on maintaining/upgrading
a stash of root certificates:
1) licensing of the certificates: Do the issuing "authorities" allow you
   to (re-)distribute their certificates bundled with (lib)cURL under your
   licensing terms.
2) Maintaining the chain of trust.

1) Can be resolved relatively easily and quickly: Just ask the root
certificate
owners you wish to include for permission - this shouldn't be too much
of a problem as they license the certificates to any odd browser maintainer
quite readily - coverage is one of their main selling points. 99% or 99.8%
seems to be a signficant difference

2) Is a bit more problematic, and requires a fundamental choise: Do you
decide yourself whom to trust as a CA, or will you add any CA that wants
to be added to your list. In the first case you have to define
standards, define a
policy ("our policy is to include the certificates issued with browser XXX
in version YYY and no others. We provide a tool that allows you to import
certificates presint in browser ZZZ"), and you are going to face complaints
from CA's who haven't been included. In the second case you are going to
face complaints of CA's and system administrators who say you are harming
the trust in SSL by including certificates from "untrusted" CA's.

Of course there is fundamentally no more guarantee of security and identity
in SSL than the quality of encryption and the trust of a well informed
user
that a certain CA doing his/her job (verifying identities) properly.
Encryption will eventually be broken, users are generally not well informed
(most press OK when asked to do so, not even looking what the reason for
the dialog box was in the first place), and (many) CA's hardly verify
identities
for certificates they sign. So what are we talking about - basically the
forces
of politics and lots of money at work. I symphatize with you for not
wanting
to become tied up too much in these areas.

If you want 1) to be sorted out I will gladly volunteer to send a polite
email
to the CA's listed in popular browsers and see what response I get. As to
the second issue: my opinion (users should inform themselve) is not very
helpfull.

With kind regards,

Theo
Received on 2005-09-01