On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: > On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote: > > On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: > > > On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: > > > > On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: > > > > > On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: > > > > > > I understand that they'd have to manually load the lists, but > > > > > > perhaps it > > > > > > would make sense to standardize a location from which they should > > > > > > load > > > > > > them? Does OpenSSL or GnuTLS have any concept of a "revocation > > > > > > store" > > > > > > format, similar to a "certificate store", or would this need some > > > > > > special-purpose custom format? > > > > > > > > AFAIR they only know about CRL (Certificate Revocation List,) which > > > > only allows > > > > for one issuer per-file. > > > > > > > > What I can't tell for sure from the documentation is whether OpenSSL > > > > and > > > > GnuTLS do check the CRL's validity (signature and time.) It doesn't > > > > seem like > > > > they do. > > > > This is relevant if we were to ship them in ca-certificates. > > > > > > > > > > > > > And it'd be nice if nss could share that store... > > > > [...] > > > > > > > > > > By the way, shouldn't this bug be clone to libnss3-1d (and maybe > > > > > iceweasel and icedove if they ship the certificates themselves)? > > > > > > > > Perhaps it's time to start a discussion as to how we can properly deal > > > > with > > > > all this mess: > > > > * Multiple packages shipping their own certificates list > > > > * Probably no app except web browsers support CRLs and/or OCSP > > > > * configuration > > > > > > > > Yves, do you know how the CRL stuff is handled in nss? > > > > > > > > > > (my first name is Yves-Alexis :) > > > > > > I have no idea. > > > > > > There's a crlutil > > > (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) > > > but it works on previous database version (bdb, cert8.db and key3.db) > > > while at least evolution now uses the shared sqlite db (cert9.db and > > > key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). > > > > The NSS tools are supposed to work with whatever database version you > > use, since they use NSS ;) > > > > That being said, there is a huge problem with mitigation in basically > > all the SSL libraries. There simply is no way to handle the current > > situation[1] without modifying applications. > > > > Mike > > > > 1. Several fraudulent certificates whose fingerprint is unknown signed > > with several different intermediate certs that are cross-signed by other > > "safe" CAs (aiui). > > So, I'll put that on tiredness. That'd be several fraudulent > certificates which fingerprint is unknown (thus even CRL, OCSP and > blacklists can't do anything), and the mitigation involves several > different intermediate certs that are cross-signed, which makes it kind > of hard. Plus, there is the problem that untrusting the DigiNotar root > untrusts a separate PKI used by the Dutch government. > > Add to the above that untrusting a root still allows users to override > in applications, and we have no central way to not allow that. Aiui, the > mozilla update is going to block overrides as well, but that involves > the application side. NSS won't deal with that.
See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
