Return to Answer

Given a prospective certification path (a sequence of n certificates), path validation performs the following, per RFC 5280, section 6.1.3:

The reason field is mostly irrelevant, the only one that matters is removeFromCRL which removes a certificate from the CRL (basically "unrevoking" it). The final "certificate status" per section 6.3.3 is:

Given a prospective certification path (a sequence of n certificates), path validation performs the following, per RFC 5280, section 6.1.3:

The reason field is mostly irrelevant, the only one that matters is removeFromCRL which removes a certificate from the CRL (basically "unrevoking" it). The final "certificate status" per section 6.3.3 is:

Exceptions apply for timestamped signatures.

But wait! Timestamped signatures

All of the above applies to path verification for "current" use. One notable exception is PKI use for timestamped signatures. This is described in RFC 3161.

Two important deviations from the above are spelled out in the RFC:

Use of revoked certificates, as long as the signature was prior to revocation: (from the intro)

   ... verify that a digital signature was
   applied to a message before the corresponding certificate was revoked
   thus allowing a revoked public key certificate to be used for
   verifying signatures created prior to the time of revocation

Meaningful reason codes when a key has not been compromised. Details from section 4:

      When a TSA shall not be used anymore, but the TSA private key has
      not been compromised, the authority's certificate SHALL be
      revoked.  When the reasonCode extension relative to the revoked
      certificate from the TSA is present in the CRL entry extensions,
      it SHALL be set either to unspecified (0), affiliationChanged (3),
      superseded (4) or cessationOfOperation (5).  In that case, at any
      future time, the tokens signed with the corresponding key will be
      considered as invalid, but tokens generated before the revocation
      time will remain valid.