[this discussion started on http://bugs.debian.org/608719]
On 03/19/2012 11:14 PM, Ben Hutchings wrote:
On Sun, 2011-01-02 at 18:20 -0500, Daniel Kahn Gillmor wrote:
It looks like dovecot-common's postinst script creates a new X.509
certificate and places it in /etc/ssl/certs/dovecot.pem. This
certificate is for use as the IMAP or POP server's end entity
certificate.
However, /etc/ssl/certs/ is used elsewhere in debian (e.g. the default
for wget's --ca-directory option) as a directory of legitimate root
certificate authorities -- *not* end entity certificates.
Is this specified in any policy? If not, shouldn't it be discussed on
debian-policy?
Sure, that makes sense. I'm cc'ing debian-policy here. I'm not
subscribed to that list, so please keep me Cc'ed in the followup.
Personally, I think that it is a bad idea to treat the
certificates in /etc/ssl/certs as automatically trusted. Even if
packagers follow such a policy, system administrators likely will not
read the policy and will not suspect that installing a certificate there
has this effect.
If this is the consensus within the project, perhaps a bug should be
filed against the ca-certificates package then, since
/usr/share/doc/ca-certificates/README.Debian states:
------------
“update-ca-certificates” will then update “/etc/ssl/certs” which may be
used by the web browsers in Debian. It will also generate the hash
symlinks and generate a single-file version in
“/etc/ssl/certs/ca-certificates.crt”.
------------
and update-ca-certificates is run during postinst configure of the
ca-certificates package.
It seems to be me that it would be better to create
subdirectories for different categories of certificates, e.g.
'trusted-ca', 'server', 'client'.
Doing this kind of overhaul might be worthwhile, but i would break down
the "trusted-ca" category still further. Consider, for example, that
libNSS allows the user to identify which root CAs are trusted to:
* identify web sites,
* identify e-mail users, or
* sign code
(some CAs may trusted for all three categories, some for only one or two
of them).
If the system store could identify these separate categories
differently, then we could divert (or ship a modified) libnssckbi.so
that actually drew its configuration from the admin's configuration
choices (instead of using the hardcoded builtins).
Is there any existing debian policy about X.509 certificates we should
be pursuing? What should the system administrator expect of
/etc/ssl/certs? Would more documentation someplace help?
--dkg
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
