Bug#704180: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Dec 7 13:44:56 UTC 2013
On 12/07/2013 07:54 AM, Raphael Geissert wrote:
> On Saturday 07 December 2013 01:21:52 Daniel Kahn Gillmor wrote:
>> The other way to maintain the same CA set is for Someone™ to fix #704180
> While I like that solution (having to modify nss to add/remove certs is a
> PITA), I wonder how trust settings should be managed. With nss' ckbi store
> you can ship a certificate and indicate no trust setting for a specific use,
> distrust, etc. No trust setting can be determined from /etc/ssl/certs,
> losing important information.
> Do you know if there's already a plan to address that shortcoming?
(setting followup-to: #704180 for this sub-thread)
my understanding of ca-certificates is that /etc/ssl/certs is itself a
(coarse-grained) trust setting. That is, we have a bunch of certs
shipped in /usr/share/ca-certificates, and during the
ca-certificates.postinst maintainer script, those certificates selected
as "trusted" by the system administrator are symlinked from
/etc/ssl/certs. By default, if the admin has low debconf priority: all
of them are considered trusted.
This isn't the finer-grained trust available in the traditional nssckbi,
which lets you break out three different broad areas of reliance:
* certify web servers
* certify e-mail users
* certify code signatures
so ca-certificates and /etc/ssl/certs is slightly more clunky. But
frankly, even nss-ckbi is clunky by comparison with what anyone who
cares about this would sensibly want. For example, i might only want to
rely on the CA from example.com's administrators to be able to certify
e-mail users *within example.com*.
p11-kit has proposed mechanisms (i haven't tested them, but as i
understand it, the idea is to associate extra X.509v3 extensions with
the certificates in question) to implement this sort of finer-grained
permission, even if it is not represented by ca-certificates.
So it seems sensible to me to start with the coarse-grained nssckbi
override using ca-certificates' coarse "all-or-nothing" approach to
demonstrate basic functionality, and then figure out how to adjust the
finer-grained nuance within p11-kit itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1027 bytes
Desc: OpenPGP digital signature
More information about the Pkg-gnutls-maint