PKI: How does CA certificate revocation affect leaf certificates?

Question

I'm struggling to find relevant section in RFCs, and I hope someone here can help me.

How does - per specification - subCA revocation affect leaf certificates issued from this CA prior to revocation? I don't only mean TLS certificate, but also code signing, time stamping, S/MIME.

My take:

1. Depends on revocation reason code - for example, reason code "Cessation of Operations (5)" should not affect validity - after all, they were issued when subCA was valid, and the subCA revocation happened for reason other than "Key Compromise".

2. However, there is a problem with issuing new CRLs - the leaf certificates would be trustworthy only for as long as CRL is still valid. Which means, that if prior to subCA revocation I issue long-life CRL, all should be good to go.

The above works on logical level unless there's something in RFC that prevents that; and as always, developers of PKI verification code often don't understand PKI, so it probably also depends on particular software.

Answer 1

The short answer:

If an intermediate is revoked it can no longer be used to verify certificates it was previously used to sign, rendering the children certificates invalid.

Exceptions apply for timestamped signatures.

Revocation of intermediate certificates:

There is no need for a different section for intermediate certificates.

The RFC shows a reference algorithm for certificate path building and verification.

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

The basic path processing actions to be performed for certificate i
   (for all i in [1..n]) are listed below.

      (a)  Verify the basic certificate information.  The certificate
           MUST satisfy each of the following:

         (1)  The signature on the certificate can be verified using
              working_public_key_algorithm, the working_public_key, and
              the working_public_key_parameters.

         (2)  The certificate validity period includes the current time.

         (3)  At the current time, the certificate is not revoked.  This
              may be determined by obtaining the appropriate CRL
              (Section 6.3), by status information, or by out-of-band
              mechanisms.

         (4)  The certificate issuer name is the working_issuer_name.

(3) specifically spells out certificate revocation in addition to certificate validity ((1) signature and (2) time).

This means that every certificate in the chain from trust anchor (aka root) to leaf certificate must not be revoked at the time of the check.

Revocation reason:

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:

If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
   then the revocation status has been determined, so return
   cert_status.

Example:

Given the following simple path: root -> intermediate -> myexample.com.

If intermediate is found to be revoked in a CRL published by root, it will be considered invalid for all paths it is a part of. Since intermediate is invalid, I cannot verify the certificate for myexample.com, rendering it invalid it a well.

Answers to OP's take:

1. Depends on revocation reason code: it really doesn't. If a certificate was revoked, it can no longer be used to verify other certificates. It does not matter if the CA went out of business or leaked its private key.

2. there is a problem with issuing new CRLs: there isn't, the CRL revoking the intermediate CA is issued by its parent which is still valid. Since the intermediate CA is now revoked, the rest of the path is invalid.

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.