[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

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
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).

Maybe Mike has some more ideas (adding him to CC:)


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: