On Thursday 01 September 2011 01:37:01 Mike Hommey wrote: > On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: > Well, reality is that the Firefox 6.0.1 release, which has a white least > for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA > - G2, effectively prevents from going to a couple of dutch government > sites.
Do you know if there's any plan to whitelist the G2 CA? > Considering it has been found that the PSM side blacklist doesn't work, > that suggests that the root CA removal alone is responsible for the > situation, but I could be wrong. That's what I also understood from the bug report, but it puzzles me. How does the removal of DigiNotar Root CA affects Staat der Nederlanden Root CA? I must have missunderstood the message. > > Action items based on what others are doing: > > 1. Disable DigiNotar Root CA: done > > 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done > > There are 3 of them iirc. > > > 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be > > done > > > > Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as > > untrusted at the PMS level. > > And that currently doesn't work. It seems reasonable to wait for a more > correct fix there before uploading ice*. There may be another nss round > before that, though, for the Entrust certs. Please also note that Kai > Engert is going to work on a NSS patch to handle the whole think at NSS > level which would port what PSM does for SSL to S/MIME and other uses of > NSS. I'm not sure this will be easily backportable, though. On Thursday 01 September 2011 04:12:44 Mike Hommey wrote: > I did some actual testing. With the DigiNoTar Root CA removal, we > don't block Staat der Nederlanden Root CA and Staat der Nederlanden Root > CA - G2. We also don't block (obviously) the ones with intermediate > certs signed by Entrust, and if I followed the story correctly, this > means we're effectively *not* preventing the *.google.com, > addons.mozilla.org, *.yahoo.com, etc. fraudulent certificates from being > used. Unless other certificates were signed with another CA, at least the *.google.com one should fail now. The chain of the the public *.google.com cert is: Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK000229200002, CN=*.google.com > A few urls to test: > https://www.diginotar.nl should be blocked, and is -> OK > https://sha2.diginotar.nl should not be blocked, and isn't -> OK > https://zga-tag.zorggroep-almere.nl should be blocked, and isn't -> BAD The last one is atm only blocked if the user has a CRL-enabled system (KDE + kleopatra, or similar,) or OCSP validation enabled. I have an idea, but I need to test a few things first. It is too simple, so I guess I must be missing something, otherwise people would have already done it. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
