Re: [Sks-devel] sks-keyservers.net New HKPS subpool added

[Phil Pennock]

On 2012-10-06 at 11:12 +0200, Stephan Seitz wrote:
> I'ld like to add ssl to my server, but prior I'm afraid I need a few
> questions answered.
> If I'm going to install a self-signed *.pool.sks-keyservers.net, that
> CRT wouldn't have any reputation. As long as there's no additional trust
> added (e.g. via monkeysphere), one main purpose of certificates, the
> knowledge of talking to the right server, isn't given.

I think that self-signed is out.  But if the pool server operator issues
certs, given a CSR from you, then all certs are valid given a trust in
the CA which is the pool server operator.

If Kristian decides that he wants to take on this work, and figure out a
safe way of managing key storage, then we can talk to the GnuPG folks
about getting his private CA cert (created for this) shipped with GnuPG
as an additional trust anchor.  It doesn't need to be a system cert,
just something which that application uses.

I suspect that any such approach would have a master "root" cert shipped
with GnuPG and kept on an offline storage device, used for signing an
intermediate CA which is used for his routine signing of keyserver CSRs,
so that if there is an incident then we can recover without affecting
the install base of GnuPG: create new intermediate, give all keyserver
operators new CRTs based on their previous CSRs, wait for some
reasonable amount of time for updates and then drop from the pool any
servers still using the old CRT; use master/root to revoke old
intermediate, update CRL.  Make sure that the communication with the
GnuPG folks has discussed how often a CRL should be checked, if at all.

(There's also the OCSP stapling option which shifts around the failure
boundaries, but OCSP stapling support is more problematic, server-side,
last I checked).

> I'm also concerned about the self-signed CAs. If we're going to
> self-sign certs, shouldn't we send the CSRs to Kristian to have it
> signed by his CA?

That was my proposal; Monkeysphere is different and adds a _different_
trust mechanism to TLS -- if traditional PKI validation fails, then
check in a different store.  That approach works, if someone is in the
strong set or has trust paths to various keys.  As far as I can see,
without having actually used it, this becomes more problematic for the
occasional user, unless Monkeysphere is replacing the "untrustworthy
trusted third party in PKI" by designating some PGP keys as "hopefully
not untrustworthy trusted third parties in the web of trust".

> Oh, and one slightly off-topic question. Does some of you know the
> current acceptance of TLS1.1/SNI in the web? I'ld need to switch to SNI
> for Port 443.

SNI is available from TLS1.0 onwards; TLSv1.1+ are good and worthy, but
not required.  Except, apparently, in Opera, but that's Opera being
weird, not a protocol requirement.

http://en.wikipedia.org/wiki/Server_Name_Indication#Support

Summary: Just about every current browser you'd expect to see being
used, except for all the folks with pre-Honeycomb Android
phones/tablets, who are going to be increasingly stuck unless their
providers get off their arses and actually provide updates.

Onto TLS1.1+:

GnuTLS has supported TLS1.1+ for many years; OpenSSL came out with a
stable release (1.0.0) which supported them a year or so back, IIRC.
It looks like NSS is just about managing to get support into mainline
and out to browsers now?
  https://bugzilla.mozilla.org/show_bug.cgi?id=565047

In practice, SNI support is now about at the point where you wouldn't
want to rely on it for something revenue generating (or of equal
importance in non-commercial organisations) but for ancillary systems
it should be fine.  On personal websites, it's definitely okay.  I've
been using it for years, without issues.

Sometimes scripting language support is problematic.  Most notably,
Python folks decided that SNI support would only go into Python 3.  But
since Python 2 has no support for TLS verification, if you're using
Python2 for security-sensitive TLS handling, you're already in such deep
trouble that this isn't a big additional problem.  Switch to Python 3
for competent TLS handling.

-Phil

pgpaHv3AkWsv3.pgp
Description: PGP signature