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

[Rob Stradling]

On Monday 12 Sep 2011 21:27:05 Gervase Markham wrote:
> On 12/09/11 03:53, Rob Stradling wrote:
> >> I'd strongly disagree. :-) If someone has tampered with my clock such
> >> that I don't notice a certificate has expired, and so I contact an OCSP
> >> responder to ask about it, the last thing I want is a "Good" response.
> > 
> > I see your point, but I think equating "Expired" with "Revoked" would be
> > a change in semantics that would constitute a "blatant violation".
> 
> Less so than equating "Revoked" with "Good"?

Yes, less so, because "Revoked" and "Good" are two different states in RFC2560.

Perhaps you meant 'equating "Expired" with "Good" '?
Again, I'd say less so.

But I think I've convinced myself that this "Hardened Profile" discussion isn't 
going anywhere.

> > I appreciate that clock accuracy is important.  I have a question on
> > that... Why should protection against clock inaccuracy be an integral
> > part of the revocation checking protocol?  Could the suggested Hardened
> > Revocation Checking Profile say "Clients MUST have accurate clocks",
> > explain why this is so in the "Security Considerations" section, and
> > leave it up to Clients to solve the problem?
> 
> Er, no. :-) That doesn't sound very Hardened to me. A much simpler
> solution is for the revocation to be whitelist-based. Then anything
> expired or unknown is marked as bad, no further question.

Yes, that would be simpler, at least for cases where the current status of the 
certificate is all you're interested in (e.g. SSL/TLS server certs).

Gerv, are you hinting that Mozilla are interested in implementing some sort of 
whitelist-based certificate status checking mechanism in Firefox?  (Peter's 
RTCS I-D, for example).

> Gerv

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online