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

[Rob Stradling]

On Friday 09 Sep 2011 17:45:07 Gervase Markham wrote:
> On 09/09/11 03:15, Rob Stradling wrote:
> > On Friday 09 Sep 2011 10:44:05 Erwann ABALEA wrote:
> >> What can be answered to a request for an expired but not revoked
> >> certificate? "Good" or "Revoked" are unacceptable, "Unknown" is also
> >> false (the CA *knows* the state), and every other answer is not
> >> signed.
> > 
> > I think "Good" would be the best match.  There would need to be a note to
> > explain that the profile reinterprets "Good" as "Not Revoked; Has Known
> > Serial Number".
> 
> 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".

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?

This would of course need some sort of "secure network time protocol".  Is 
there such a thing?
http://datatracker.ietf.org/wg/stime/charter/ looks like a dead end.

> If, in your scheme, we have to redefine "Good" as "Not Revoked; Has
> Known Serial Number", then why can't we instead redefined "Revoked" as
> "Not good; revoked or expired"?
> 
> Gerv

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