[Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

[Raphael Geissert]

On Wednesday 07 September 2011 11:23:18 Kurt Roeckx wrote:
> > On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
> > > On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
> > > > The only currently supported methods are OCSP and CRL, but none would
> > > > do the trick in this case.
[...]
> Looking at different client software, it seems to me that
> nothing is actually checking CRL.  And webbrowsers are
> probably the only one doing OCSP, and only OCSP.

Yes, that was the impression I got when I checked some of the clients.
CRL is probably not used because:
a) it requires "somebody" (some program) to download the CRLs and keep them up 
to date
b) even if they are downloaded, where do they locate them? dirmngr and 
pathfinder both use their own protocol, and fetch-crl installs them in a non-
standard dir
c) clients would need to enable X509_V_FLAG_CRL_CHECK and/or 
X509_V_FLAG_CRL_CHECK_ALL depending on whether the certificates in the chain do 
have CRL distribution points.

> So the only solution I currently see is doing this in the
> part that verifies the chain, and there making sure
> know bad certificates generate a verify failure.

Yep, that's why I moved on to the proposal of the hard-coded check :)

> > > I'm not opposed to such a change, but would like to see a better
> > > option in the future.

Not sure how the engine's modularity was implemented, but something similar 
could be done so that X.509 certs could be "verified" by different modules:
* Standard: current chain validation and other existing checks
* Untrusted: checking a cert against a list of untrusted certs
* etc (something along Moxie's convergence, perspectives, or any other 
distributed trust model)

Anyways, that's something that needs to be discussed elsewhere.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net