On 28/08/12 23:07, Michael Collins wrote:
Tomorrow we hope to have a discussion about TLS<http://wiki.freeswitch.org/wiki/Tls>. We have several community members who are experienced with key and certificate management and we will be calling upon them to share their experience with the rest of us. After that we will have an open discussion.
FYI, this came up at DebConf, some of us are thinking about similar issues at a platform level: http://penta.debconf.org/dc12_schedule/events/895.en.html and notes from the session can be accessed with the gobby tool (sorry I can't find this online somewhere, I've cut and pasted below for convenience): http://wiki.debian.org/gobby.debian.org look under debconf12/bof/X.509 As was emphasized at DebConf, it is a particular issue for VoIP services, because different applications (e.g. a Jabber server and a SIP server) can share the same key material (no need to waste money buying a cert for each protocol), but sharing private keys between different applications requires a more rigorous platform-wide effort to protect the keys. 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