Bug#704180: Bug#718434: Bug#731463: Bug#718434: ca-certificates: should CAcert.org be included?

[Daniel Kahn Gillmor]

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.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20131207/cf920bd5/attachment.sig>