Re: Microsoft deems all DigiNotar certificates untrustworthy, releases

[Marcus Reid <marcus () blazingdot com>]

On Sun, Sep 11, 2011 at 01:34:43PM -0500, Joe Greco wrote:
> > > Because of that lost trust, any cross-signed cert would likely be revoked by
> > > the browsers.  It would also make the browser vendors question whether the
> > > signing CA is worthy of their trust.
> >
> > To pop up the stack a bit it's the fact that an organization willing to
> > behave in that fashion was in my list of CA certs in the first place.
> > Yes they're blackballed now, better late than never I suppose. What does
> > that say about the potential for other CAs to behave in such a fashion?
>
> The average corporation much prefers to avoid the bad publicity and will
> downplay most bad things.  Your favorite CA probably included.
>
> I think that it's hard to cope with SSL.  It doesn't do the right things
> for the right reasons.  Many of us, for example, operate local root CA's
> for signing of "internal" stuff; all our company gear trusts our local
> root CA and lots of stuff has certs issued by it.  In an ideal world,
> this would mean that our gear talking to our gear is always secure, but
> with other root CA's able to offer certs for our CN's, that isn't really
> true.  That's frustrating.

You don't have to have the big fat Mozilla root cert bundle on your
machines.  Some OSes "ship" with an empty /etc/ssl, nobody tells you who
you trust.

> The reality is that - for the average user -  SSL doesn't work well 
> unless about 99% of the CA's used by the general public are included 
> as "trusted."  If a popular site like Blooble has a cert by DigiNotar
> and the Firerox browser is constantly asking what to do, nothing really
> good comes out of that ...  either people think Firerox blows, or they
> learn to click on the "ignore this" (or worse the "always trust this")
> button.  In about 0.0% of the cases do they actually understand the
> underlying trust issues.  So there's a great amount of pressure to
> just make it magically work.

How about a TXT record with the CN string of the CA cert subject in it?
If it exists and there's a conflict, don't trust it.  Seems simple
enough to implement without too much collateral damage.

> However, as the number of CA's accepted in most browsers increases, 
> the security of the system as a whole decreases dramatically.  Yet
> the market for $1000/year SSL certs is rather low, and the guys that
> are charging bargain rates for low quality certs are perhaps doing
> one good thing (enabling encryption) while simultaneously doing another
> bad thing (destroying any "quality" in the system).  SSL is going to
> have these problems as long as we maintain the current model.

I like the added "chrome" that the new browsers have for EV certs, but
users need to be stabbed in the face, green vs. blue doesn't really do
it.

> In the long run, I expect all the CA's to behave something like this -
> especially the ones that have more to lose if they were to become
> suddenly "untrustworthy." 

Yes, how do you think Verisign/Thawte/Symantec would behave if they
found that their keys were compromised?  They might do the right thing,
because they're not stupid enough to think they could get away with
trying to cover it up.  What would the browser vendors do in that case?
I hope there's a contingency plan, and if there is it seems like it
should be made public.

Marcus