X.509 Certificate, Root CA, and Key best practices
==================================================

Confusing for packagers, admins, and users.  Let's fix!

Servers:
--------

 * where to store secret key material?  (/etc/ssl/private)
 * sharing key material across services?
 * locations for server certificates?
 * auto-creation of key/cert/certreq?
 * intermediate CA certificate storage
 * list of trusted root authorities for client certs -- shared?

Clients:
--------

 * list of trusted root authorities -- system store?  end-user override?
   -> Make all clients use the same store?
 * managing per-user certificates and secret keys -- p11-kit
 * how do we deal with root authorities for different contexts (web, e-mail, code-signing, etc)
 * CRL/OCSP check?
   -> blacklist
   IIRC Microsoft now distributes blacklists via their update service 
(chrome iirc too)
 * What can the cert be used for (email, website, software)
   -> mozilla has that information in it's store
   -> openssl can store it, but then uses a different header that others might not be able to read

CSR process:
------------

(clients and servers) -- how can we make this less painful?

affected packages:
------------------

 * iceweasel/icedove (via nss and libckbi.so)
 * ca-certificates (potential split into ca-certificates, ca-certificates-mozilla, 
   ca-certificates-debconf, etc.)
 * ssl-cert
 * ca-certificates-java
 * kdelibs5-data: /usr/share/kde4/apps/kssl/ca-bundle.crt
 * nmap: /usr/share/ncat/ca-bundle.crt
 * ruby: /usr/lib/ruby/XXX/rubygems/ssl_certs/ca-bundle.pem
 * sympa: /usr/share/sympa/default/ca-bundle.crt
 * nutsurf-common: /usr/share/netsurf/ca-bundle.txt
 * abiword: /usr/share/abiword-2.9/certs/cacert.pem
 * acgvision-agent: /etc/acgvision/acgTrustStore.certs
 * apparmor: /etc/apparmor.d/abstractions/ssl_certs
 * gnupg2: /usr/share/gnupg2/com-certs.pem
 * libpurple0: /usr/share/purple/ca-certs/
 * linphone-common: /usr/share/linphone/rootca.pem
 * ntop-data: /usr/share/ntop/ntop-cert.pem
 * phoronix-test-suite
 * pidgin-microblog
 * burp
 * cpushare
 * acl2-books-certs
 * postgresql
 * openssl (embeds /etc/ssl/certs)
 * gnutls (no default authorities -- is this a good thing)
 * dovecot (and other IMAPs, POP3s servers)
 * exim4 and other MTAs (SMTPS, SMTP AUTH)
 * apache
 * vsftpd
 * resiprocate
 * XMPP servers
 * ...

normalizing and de-confusing names of directories:
--------------------------------------------------

 * /etc/ssl → /etc/x509 ?
 * .../certs → .../cas ?
 * /etc/ssl/public for non-ca certificates?

toolsmithing suggestions
------------------------

 * monitoring/review of sensitive directories (e.g. cronjob to review these directories and report on changes,
   like many people do already with nagios/icinga)
 * tool to inspect/interrogate all open sockets that appear to support TLS/SSL and report problems
 * something like db-config-common for X.509
 * ssl-cert and ca-certificates ca-certificates-java
 * per-machine root-authority that could be enabled by default?

Next steps:
-----------

 * best practices documentation: http://wiki.debian.org/X.509
 * what of this can or should be policy?
 * how can we get project-wide rough consensus
 * come up with a plan for how to file bugs; i.e. in the bug report,
   we need a suggested plan for what to do differently
 
 
Objectives:
-----------

 * make it easy for an administrator to configure his or her system for X.509 certificates with a single easily auditable point of control
 * make it easy for a packager to rely on certificate creation, management, expiry, etc. so that each package doesn't need to reimplement these functions
 * make it easy for a user to use client-side certificates across tools
 * make it easy for a user to connect to public services predictably with different tools

Other Distros Approaches
------------------------
 * Fedora's attempt to replace NSS
   http://fedoraproject.org/wiki/Nss_compat_ossl
   http://fedoraproject.org/wiki/FedoraCryptoConsolidation