11

I'm trying to wrap my head around the OCSP revocationTime for D-Link's certificate.

I recently answered another question and ended up drafting a timeline.

That timeline is basically this:

Jul  5 00:00:00 2012 GMT. Validity: Not Before
Feb 27          2015      Inadvertent disclosure
--- six months of nothing ---
Sep  3 00:00:00 2015 GMT. OCSP "revocationTime" backdated to this.
--- one day of invalidity (?) ---
Sep  3 23:59:59 2015 GMT. Validity: Not After 
Sep 17          2015      Tweakers.net report 
Sep 18          2015      TheRegister.co.uk report
Sep 20 14:00    2015      Is-it-revoked-yet?-question posted.
Sep 20          2015      Answer posted. OCSP `good`
Sep 22          2015      Update answer posted. OCSP `revoked`

And the question is this:

  • Does D-Link's move retroactively invalidate just 1 day of possible use/misuse of their key?

Or asked differently:

  • Will an (hypothetical) EXE signed on Sep 2 with the stolen key STILL work, despite the revocation?

And as a side/background question:

  • What is the general idea with OCSP's revocationTime? Are you supposed to backdate that to the first point in time that you think the key was compromised? (I tried to do my research. But I'm stuck. I couldn't find the explanation in the OCSP RFC. And a 2012 post on the PKIX mailing list by Martin Rex, didn't exactly clear things up for me either.)
Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86

1 Answers1

5

OCSP provides a dynamic mechanism for checking whether a given certificate has been compromised or not and, in case it has been compromised, after what date (and time) should signatures using this certificate considered unsafe (basically, it is a dynamic version of CRLs).

This has several consequences:

  • OCSP responses SHOULD be backdated in case they indicate a "revoked" status. The reason for this is simple: a key is usually discovered to be compromised long after the actual control of that key has been lost. Therefore, it is logical to provide a way to inform users of that certificate whether old signature should also be considered invalid (without revoking ALL signatures).
  • Once a certificate has been revoked, it CANNOT be considered valid again.

All this is made more complex by the fact that OCSP responses can be 1) cached and 2) pre-produced. This means that, during a period of time after a certificate revocation status has been issued, it is possible for different OCSP clients to receive different answers. This situation can last until the date indicated by the nextUpdate field of the last "certificate valid" answer is reached.

So:

Does D-Link's move retroactively invalidate just 1 day of possible use/misuse of their key?

No. They retroactively invalidated the certificate starting at 00:00:000 that day.

Will an (hypothetical) EXE signed on Sep 2 with the stolen key STILL work, despite the revocation?

Yes because it was signed before the certificate revocation time.

Are you supposed to backdate that to the first point in time that you think the key was compromised?

Yes and no: you're supposed to backdate it to the date when the key was last known to be safe.

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • You wrote: *No. They retroactively invalidated the certificate starting at 00:00:000 that day.* How is that different from 1 day? (Cert would have expired on midnight that day anyway.) – StackzOfZtuff Oct 05 '15 at 15:02
  • You haven't included any link to the certificate you're talking about but if the certificate revocation date was set to one day after the OCSP revocation time, then yes: they affectively revoked it only for a day (even if the OCSP "revoked" response means it should be expired indefinitely, that value cease to be of use after the certificate has expired) – Stephane Oct 05 '15 at 15:09
  • Cert + chain is listed in [my earlier answer](https://security.stackexchange.com/questions/100700/has-the-leaked-d-link-windows-signing-key-been-revoked). Also you wrote *that value cease to be of use after the certificate has expired*. Well, no, I don't think that's the case for time-stamped code signing stuff. – StackzOfZtuff Oct 05 '15 at 15:13
  • "that value cease to be of use after the certificate has expired", I mean: the certificate revocation date, not the OCSP answer. Sorry: it wasn't clear. – Stephane Oct 05 '15 at 15:35
  • Thanks. Could you add some reference links? RFC? Textbook? Well-known-implementation-source? -- What you say makes sense to me, and is essentially what I suspected. I just couldn't find any hard sources to back up my suspicion. – StackzOfZtuff Oct 09 '15 at 11:11
  • I'm not sure what you're looking for really: you already linked the base document: rfc2560. You might want to have a look at RFC 5280 as well (CRL) since it is the "ancestor" of OCSP and fulfills the same role. – Stephane Oct 09 '15 at 12:13
  • I can only find *encoding* rules in the CRL or OCSP RFCs. What I could NOT find was the actual *semantics* of either CRL's `revocationDate` or OCSP's `revocationTime`. And I'd like a canonical source the semantics of those two. (Martin Rex tried to explain it on the PKIX ML (linked in my question). But that only confused me more.) – StackzOfZtuff Oct 09 '15 at 12:57
  • Welcome to the wonderful worlds of RFCs... RFC 2459, section 5.1.2.6 describes the revocationDate field of a CRL (technically, of X509's CRL). RFC 5280, section 5.3.2 describes the "Invalidity Date" field which, in the case of validity check, if present, suppressed the revocationDate (still applying to CRLs). Both these properties are replaced by OCSP's "revocationTime" (invaliditydate has, as far as I know, no real equivalent in OCSP). – Stephane Oct 09 '15 at 13:21
  • You meant to say *`revocationDate` has, as far as I know, no real equivalent in OCSP*, right? – StackzOfZtuff Oct 09 '15 at 14:21
  • Yes, sorry. `invalidityTime` has the same meaning in a CRL than `revocationTime` in OCSP: it is the date (and time) after which the certificate should be considered invalid (in CRLs, if it's not present, then `revocationDate` is used instead). – Stephane Oct 09 '15 at 14:29