[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Gervase Markham]

On 05/09/11 22:55, Kyle Hamilton wrote:
> OCSP only returns whether a certificate has been revoked, not whether it
> was ever known to be issued in the first place.  If it's not known to be
> revoked, it does indeed return "Fine, no problem!"  But...
> 
> The OCSP responder could perhaps have responded based on if the issuing
> key's hash was known to the responder (i.e., had been enrolled in the
> PKI as a key certified as a CA).  I haven't implemented one, I don't
> know how easy it would be.

Turns out they switched the DigiNotar OCSP responder to whitelist mode
in early September.

> 1) There is no strong central regulatory authority which can
> cross-certify member CAs, and decertify those kicked out of the club. 
> This means that there is no actual non-code-push manner to protect
> Mozilla's customers.  Thus there are ultimately multiple days between
> discovery and visible, useful reaction.

Are you saying that a revocation-based model for distrusting DigiNotar
would have been significantly better than a Firefox update-based model?
I'm not convinced that is true.

> 2) the lack of CA advertising in the chrome. 

This is an old argument, and my position remains: there is no way we are
ever going to get average users to pay attention to CA branding, and if
by some amazing effort we managed it, it would just entrench the
position of the top 2 or 3 CAs.

> Don't forget about Verisign's training issue related to TLDs.  

I don't know what you are referring to, I'm afraid.

>>>   there's nothing protecting the user.  Even the most trivial checks by
>>>   browsers would have caught the fake Google wildcard cert that
>>> started all
>>>   this.
>>
>> What sort of "trivial checks" are you suggesting?
> 
> Whitelist of known CAs and high-profile sites?  Or how about a strong
> cross-certification CA with working revocation?

You class either of these as 'trivial'? Both are large engineering and
political challenges.

>>>   (I can't, for
>>>   example, turn on TLS-PSK or TLS-SRP in my server, because no browsers
>>>   support it - it would make the CAs look bad if it were deployed).
>>
>> Patches welcome? (Or did we reject them already? :-)
> 
> Mozilla's security group would reject them if they made it possible for
> TLS to act in any uncertified mode.  It is already rejecting
> common-sense improvements.

Bug numbers? Although I suspect we will have a disagreement about what
constitutes common sense.

Gerv