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
pgpyw1PHFk1AN.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/sks-devel
