CAcert System Admins discussion list

[Benny Baumann <benbe AT cacert.org>]

Hi Dmitry,

Am 25.05.2015 um 01:29 schrieb Dmitry Smirnov:
> Hi Benny,
> 
> Thank you for review and improvement suggestions.
> 
No problem.

> On Sun, 24 May 2015 11:30:01 Benny Baumann wrote:
>> https://sources.debian.net/src/ca-cacert/2011.0523-1/debian/control/
>> Line 19: Should read "Root certificate_s_ allow-s- SSL-based
>> applications [...]"
> 
> Corrected, thanks.
> 
> 
>> Lines 34f: I'd suggest "Please note that Debian's inclusion of CAcert
>> does not imply that any audit according to RFC 3647 or similar standards
>> has been completed."
> 
> How about
> 
>     Please note that CAcert may not comply with RFC 3647 or similar 
> standards.
> 
Make it

    Please note that CAcert may not _yet_ comply with RFC 3647 or
similar standards.

and I'm fine with it!

> See
> 
>     
> https://anonscm.debian.org/cgit/collab-maint/ca-cacert.git/commit/?id=368cdfce
> 
> 
>> NB: "Auditing for trustworthiness" does not - as widely believed - say
>> anything about the trust and reliance a user can put into issued
>> certificates. Trust isn't something you certify, but something you have
>> to earn. Thus our primary goal is less to be "audited for
>> trustworthiness" but to complete an audit for acceptance in browsers as
>> an additional indication for people to decide if they trust us.
> 
> Of course. Thank you for expressing it nicely.
Sorry, realist about PKI ;-)
> 
> 
>> Also a note on the way the source package is generated: Please include a
>> check to verify the downloaded files. Even if you aren't verifying the
>> connection (BTW: The files are accessible on HTTP too) you should
>> include at least a fingerprint for the root to verify downloaded files.
> 
> Could you provide some examples please? I'm not sure how to do it using 
> `wget`.
> How can one check root certificates using pre-downloaded public key?
> 
As gpg is usually available you can include the long fingerprint of the
GnuPG key, fetch that key from a key server, verify the received key has
the proper fingerprint, download the index.php?id=3 and grep for the PGP
block. Within that block you find the fingerprints of the class 1 and
class 3 roots. extracting those fingerprints from the verified signature
block allows comparing them for the calculated fingerprints of the
downloaded files.

I asked our critical admin team on putting the certificate fingerprints
of the root/intermediate certificates into DNS secured by DNSSEC in a
machine-readable format. Still waiting for a reply though. Details when
those entries become present.

> Besides source archive is generated by the maintainer who can do manual 
> checks
> as well. Some checks already implemented in the "dh_auto_test" target.
Saw those. Maybe add things like verifying downloads are valid X.509
certificates. Also include check for class3 is signed by the root ;-)

>> Also please note the disclaimer in section 4 of the CAcert RDL and the
>> obligations specified in section 3. While members of CAcert should be
>> aware of this I think the current package is lacking a proper
>> implementation to ensure that EVERY user is made aware of these
>> clauses/conditions.
> 
> The condition "or reproduce this license and copyright notice in full in the
> documentation provided with the distribution" is met. License is prominently
> available in the "/usr/share/doc/ca-cacert/copyright" just like in every 
> other
> Debian package. Both Debian and CAcert policy requirements are met without
> need for explicit user acceptance. Besides similar disclaimers are common in
> almost all free software licenses.
> 
I did not say that the current implementation violated the licence, just
remarked on the implication therein. Yet it would be preferable if such
a notice could be displayed (even non-interactive) upon install.

The part to take note of is not the reproduction of the licence (that's
default and implemented by putting it into the filesystem according to
FHS), but the limited liability and reliance you should be aware of as
relying party/user. Especially combined with lines 34f this might
warrant bringing it to the attention of at least the administrator of a
system.

Kind regards,
BenBE.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature