Digital Signatures validity when changing Certificate Authority

Question

An enterprise has its internal PKI-1 (Root CA) that issues certificates to sign document using CAdES-C (CAdES-LT); with Complete Validation Data References and revocation references.

Now this enterprise has to switch to new external PKI-2 (new Root CA) for the issuing of digital signing certificates. The private keys will not change.

The plan is:

1. As as soon as PKI-2 goes live is to revoke all certificates from PKI-1. And any new signatures from that point onwards will be using new PKI-2 certificates.

2. Any previously signed documents with PKI-1 certificates do we need to sign them again with new certificates and add old PKI as the revocation references?

Is this plan sensible or not at all? Am I missing anything? Thanks

Answer 1

There are two problems here.

• will the old certificates still useable without re-signing with the new authority?

  AFAIK the answer is no. As soon as a parent authority is revoked, all the certificates that it validated directly or indirectly are no longer valid. If you did not respect that, and if a certificate immediately below the revoked authority was to be compromised, it would be impossible to sign a new revocation list with the already revoked parent...

• are documents signed with a now revoked authority still valid?

  On a legal point of view, the answer is yes on most country. Because the signature was applied at a moment when the certificate was still valid. In the real world, old laws for which the signer is now long gone still apply unless they are explicitely revoked, so there is no reason for digital signatures to behave differently.

  On a technical point of view things are unclear. Many signature validation software can only test whether the certificate is currently valid. Else, they should consult eventually outdated revocation lists to see when the certificate was revoked. So any automatic verification of such a document will raise a red warning for being signed with a revoked certificate. Ideally, this is the point where a normally intelligent human being should be able to say I know that at signature time the certificate was valid. The organization still exists so the signed document is valid. But if we only rely on automatized verifications...

Answer 2

I'm presuming the following things:

• the key pairs of the trusted root CA's will be regenerated;
• the root certificates in PKI-2 will have a new Distinguished Name;
• the private keys of the issued certificates won't be changed;

That however means that you'd still have to renew each certificate directly below the root certificates. If those certificates retain their original identification (subject distinguished name) then the certificates directly below those do not have to change, as the issuer identification of those certificates can remain unaltered. Also, the algorithm output of any of these certificates will remain valid.

This will still leave you with a problem though. Generally we use specific protocols to generate signatures. Let's use CMS as an example. These signature protocols will also include a list of certificates, so any verifier is able to create a valid chain up to a trusted root certificate. If these remain identical then the certificate chain cannot be build, as the new certificates below the root are not available. So you'd have to include those or source them from outside the CMS message. And - obviously - the verifiers also need to update their trust store with your new root.

Generally software should always try and build chains until they find a certificate that is in the trust store. However, I'm not sure if all software will always do that. It may be that it finds a partial chain using the old certificate and give up at that point. So if possible you should also remove the old certificates from the certificate store inside the signature container.

Note that there are serious issues with key pair reuse. I would at least make sure that they keys are not thrown away once the certs expire, and that the validity date in the new certificates doesn't expand past their original due date. I'd strongly suggest going through the original CA policy and check if they key pair reuse is allowed by it (in your case, as it is an internal policy, you may have some slack there).