Subject: [pkix] time stamp verification for non repudiation (in Windows)

From: Hristo Todorov <[email-masked]>
Date: Thu, 3 Jan 2013 17:56:20 +0000

Hi all,

This question is somewhat related to information Peter Rybar provided several hours ago in the thread: why revoked certificate entry has to be included in one CRL issued beyond certificate validity period

"The date on which the revocation occurred is specified in revocationDate field of CRL but the real e.g. compromise was earlier than is the time value in revocationDate. The revocationDate of a CRL does not give you the real time when a certificate was revoked but the revocationDate is the START of the interval since when a certificate is to be invalid according to signed evidence created by CA.

The real revocation date will be earlier than is the date in the revocationDate field of CRL e.g. according to judgement in court."

I am wondering how this is to be treated in light of RFC 3161, especially appendix B (where it would be the judgment of the software, not of the court).

In particular Windows verifies a timestamp by calling a revocation provider with a call including a past time stamp. As MSDN iterates on http://msdn.microsoft.com/en-us/library/aa377524.aspx

pftTimeToUse : " A pointer to a FILETIME version of UTC time. When specified, the handler must, if possible, determine revocation status relative to the time given. If NULL or the handler cannot determine the status relative to the pftTimeToUse value, revocation status can be determined independent of time or relative to current time."

This would seem to indicate that revocation checking on windows should return a good!? status of the time specified above is before revocationDate in the CRL, but as indicated in the previous thread, this is unreliable as the actual key compromise time, hence validation of the past signature with a certificate now revoked seems to be somewhat questionable. Why is then InvalidityDate an optional CRL entry extension? What are the reliable inputs to RFC 3161, appendix B, B6?

On a separate note, why is MS expecting a revocation provider to return good status in the case when  ftTimeToUse < revocationDate and is that not,  not following the spirit of 3161, Appendix B, B 5 and B 6?

Thanks in advance,
Hristo

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 4 Jan 2013 10:43:00 +0100

Good observation FRC 3161, Appendix B, B 5 and B 6

"B) The validity of the digital signature may then be verified in the
      following way:
 5)    The revocation information about that certificate, at the
            date/time of the Time-Stamping operation, MUST be retrieved.
 6)    Should the certificate be revoked, then the date/time of
            revocation shall be later than the date/time indicated by
            the TSA.
"

Probably “shall be later” must be replaced with “shall be before” in sentence B 6.

The sentence with “shall be later” is about the situations when the signature is valid with revoked certificate where the revocation is later then the time when the signature was time-stamped.

Peter Rybar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hristo Todorov
Sent: Thursday, January 03, 2013 6:56 PM
To: [email-masked]
Subject: [pkix] time stamp verification for non repudiation (in Windows)

Hi all,

“The date on which the revocation occurred is specified in revocationDate field of CRL but the real e.g. compromise was earlier than is the time value in revocationDate. The revocationDate of a CRL does not give you the real time when a certificate was revoked but the revocationDate is the START of the interval since when a certificate is to be invalid according to signed evidence created by CA.

The real revocation date will be earlier than is the date in the revocationDate field of CRL e.g. according to judgement in court.”

Thanks in advance, 

Hristo

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 05 Jan 2013 09:33:27 +0100

From:  Hristo Todorov <[email-masked]>
Date:  Thursday, January 3, 2013 6:56 PM
To:  "[email-masked]" <[email-masked]>
Subject:  [pkix] time stamp verification for non repudiation (in Windows)

> This would seem to indicate that revocation checking on windows should return
> a good!? status of the time specified above is before revocationDate in the
> CRL, but as indicated in the previous thread, this is unreliable as the actual
> key compromise time, hence validation of the past signature with a certificate
> now revoked seems to be somewhat questionable.

Almost everything in PKI is questionable.
The identity of the subject is questionable, verified through imperfect
means.
Whether the CA is compromised is questionable. It might be without you ever
knowing about it.

Systems process the data at hand to determine results given defined rules.
That result can be used to manage trust and risks, but should not be
mistaken for being a perfect reflection of reality.

This is why we have courts to sort out what reasonably happened and who is
responsible, if needed.

/Stefan