Self-signed root transport and CA expiration

[Tim Dierks <timd@xxxxxxxxxxxxx>]

There's been some discussion recently on whether it is appropriate to
include self-signed root CA certificates in a certificate chain being sent
to support a particular certificate. (I've seen this both with respect to
S/MIME and SSL.) One point in support of sending roots, which I haven't
seen mentioned, is the question of resolving CA keys.

Is it guaranteed that there is at most one key for a particular CA's
distinguished name? Given that key identifiers do not seem to be widely
used (for example, none of the Verisign root CAs have key identifiers),
this seems necessary. Given that fact, does this imply that when CA
certificates expire, the CA must choose to either generate the new CA with
a new distinguished name or to use the same key; there is no way to use the
same DN with a new key.

The solutions seem pretty clumsy: either construct some heuristic to
determine which key a certificate was issued with (based on validity times,
perhaps), or require that validating applications iterate across potential
issuers with identical names, attempting to verify the signature with each
key (which would be very expensive).

Of course, transporting root CAs with certificates would solve this
problem: it would provide a well-defined binding between the two
certificates (the fact that they were delivered together).

Given that the Verisign root CAs expire at the end of 1999, this problem
isn't indefinitely far away. You could have the same difficulties if a CA
key had to be replaced for some other reason (such as the private key being
destroyed in an accident).

 - Tim Dierks

[Please forgive my submitting this to ssl-talk, smime-dev, and ietf-pkix]

Tim Dierks - timd@consensus.com - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite