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). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
