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.)
5
+150

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.

  • 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 5 '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 5 '15 at 15:09
  • Cert + chain is listed in my earlier answer. 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 5 '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 5 '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 9 '15 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.