Re: Self-signed root transport and CA expiration

[Tim Dierks <timd@xxxxxxxxxxxxx>]

At 9:11 AM -0500 11/19/96, David P. Kemp wrote:

>> 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.
>
>
>Tim,
>  I'm missing something in the context of this question - what is the
>purpose of sending the root CA certificate?
>
>Since the receiver of the certificate chain must validate the 2nd
>(1 level down from root) cert with the root's securely-configured
>public key (i.e. not a putative root key received on-the-fly), what
>is the benefit of *ever* sending the root cert as part of a chain?
>
>In 1999 when the Verisign root expires, it's probably best to install
>the new root cert using the same procedure the old one was installed
>with in the first place (verifying fingerprints from a newspaper
>ad, physical transport, or whatever).  Anything else is just
>begging for trouble.
>
>        dpk

Clearly, the root needs to be verified against a trusted database which
contains trusted root certificates; the advantage of having it sent it is
that you are provided with an unambiguous statement as to exactly which key
a certificate has been signed with. The Distinguished Name in the issuer
field of a certificate is insufficient to specify the signing key. As
certificate authorities expire and roll over from old to new, there will be
a period of time when a received certificate may have been signed with the
old key or the new key. During this period (which may be indefinite,
depending on policy), the only way to check the signature is to try all
possible keys.

 - Tim

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