OCSP validation at moment

[kak-bo-che]

First off great set of libraries, they are so much easier to use than pyasn1 and the crypto libs tied directly to OpenSSL.

I understand that according to the documentation the library does not support enabling certificate revocation checks if the moment is set to any value other than now. I feel that at least in the case of OCSP validation this requirement is unnecessary. (based on my possibly incorrect reading of rfc6960 section-3.2)

   5. The time at which the status being indicated is known to be
      correct (thisUpdate) is sufficiently recent;

   6. When available, the time at or before which newer information will
      be available about the status of the certificate (nextUpdate) is
      greater than the current time.

To me those two requirements seem to be related to the time of the OCSP request and not the moment of the certificate validation. As context I'm using your library to validate pkcs#7 SignedData objects that include cross signing timestamp that I am deriving my moment from. I have not looked into the related case of CRL validation.

related code context

ValidationContext allows a moment to be set that is in the past/future, but in doing so the OCSP revocation check is disabled, because the verify_ocsp_response method verifies that moment falls between this_update and next_update

[wbond]

So to summarize, you are suggesting:

1. If a moment is specified for validation, AND
2. No revocation data is provided AND
3. The current timestamp is less than the expiration date of the certificate

Then the OCSP/CRL checks should be done now.

As long as the certificate is currently not revoked, or the validation moment is from before the revocation timestamp, then it should be considered valid?

Is that correct?

[wbond]

The reason I am including assumption 3 is that I don't know what policies various CAs have on providing revocation information after a certificate has expired.

[kak-bo-che]

It has been my experience that CAs have been responding if a certificate is revoked well after the certificate itself has expired. My application is validating code signed certificates where the common case is the file was signed in 2012 with certificate valid from 2011 - 2013 and then countersigned/timestamped in 2012 with a certificate that is valid until 2020.

In this case the moment I'm validating the signing certificate chain is from 2012 because that is when the counter signature took place. All certificates on that chain need to be valid in 2012 and not currently revoked (2016).

When I validate the associated counter signing chain the moment is NOW. This may only be the case for code signing, but anything that is counter signed the entire chain should be checked for validation so I don't know how a CA would get away with forgetting about keys that have been compromised just because they are expired. Especially if they have a key usage that includes things like document signatures.

[wbond]

If you don't mind, I'm interested in clarifying this process, since my intention in building all of this was document signing and verification. It seems code signing is an almost-identical use case.

Vocabulary:

• Code signing certificate (signing cert)
• Code signing certificate chain (signing chain)
• Counter signing certificate (timestamp cert)
• Counter signing certificate chain (timestamp chain)
• Code signature (sig)
• Counter signature/timestamp (countersig)

As I understand it:

• The signing cert is valid from 2011-2013
• The timestamp cert is valid from 2010-2020
• The sig is created (for example) 2012-06-01
• The countersig is created (for example) 2012-06-02

You want to check:

• sig is valid
• You trust the signing chain at 2012-06-01
• The signing cert was unrevoked on 2012-06-01, based on revocation checks from now
• countersig is valid
• You trust the timestamp chain now
• The timestamp chain is unrevoked now

The other variation I am familiar with for document signing is LTV validation, where the revocation info for the signing chain is included in the document. This way as long as the timestamp chain is still valid, the signing chain may have revocations checks that have gone away. This can be extended by timestamping the document again in the future to provide a more up-to-date timestamp, extending the trust.

If the above is true, then it seems the issue is that you want to validate the signature chain at 2012-06-01, using revocation info obtained now. Is that correct?

[kak-bo-che]

In code signing there is no timestamp associated with the sig so the timestamp: 2012-06-01 exists nowhere. I trust the signing cert/signing chain at 2012-06-02 which is when the countersig occurred and the timestamp exists within the data signed by the timestamping service.

Unrevoked on 2012-06-02 doesn't really matter. If a certificate is revoked, it is revoked period and it doesn't matter if it was valid/unrevoked at the time of the countersig.

The rest regarding countersignature is true.

For Authenticode the structure is there for CRLs, but they are always empty.