Subject: 3280bis: root CA key update (self-issued certificates)

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Nov 2004 08:31:09 +0100

In RFC 2510, there are explanations about the means to update
a root key. These explanations should be incorporated into 3280bis
since they are not part of a "management protocol" but simply the
generation of self-issued certificates that are placed in a repository.

It is proposed to define what a self-issued certificate is:

self-issued certificate: a public-key certificate where the issuer
and the subject are the same CA. A CA may use self-issued
certificates, for example, during a key rollover operation to provide
trust from the old key to the new key.

The following text is a proposal based on the text from section 2.4
of RFC 2510 to be incorporated in 3280bis:

X. Root CA key update

This discussion only applies to CAs that are considered to be
a trust anchor for some relying party.

A graceful, scheduled change-over from one non-compromised CA
key pair to the next (CA key update) must be supported (note
that if the CA key is compromised, re-initialization must be
performed for all relying parties trusting that CA).

The basis of the procedure described here is that the CA protects
its new public key using its previous private key and vice versa.

Thus when a CA updates its key pair using this procedure it must
generate three self-issued CA certificates if these certificates
are made available using a repository.

The data structure used to protect the new and old CA public keys is
a self-issued certificate (which may contain certificate extensions).

X.1 CA Operator actions

To change the root key of the CA using this procedure, the CA operator
does the following:

1. Generate a new key pair;

2. Create a certificate containing the old CA public key signed
with the new private key (the "old with new" certificate);

3. Create a certificate containing the new CA public key signed
with the old private key (the "new with old" certificate);

4. Create a certificate containing the new CA public key signed
with the new private key (the "new with new" certificate);

5. Publish these certificates in a repository and/or via other
means;

The "old with new" certificate must have a validity period starting
at the generation time of the old key pair and ending at the expiry
date of the old public key.

The "new with old" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which all relying parties of this CA will securely possess the new CA
public key (at the latest, the expiry date of the old public key).

The "new with new" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which relying parties will no more be trusting the public key
contained in the self-signed certificate.

This scheme forces relying parties to acquire the new CA
self-signed certificate before the expiry of the last self-signed
certificate they trusted that was signed with the old CA private
key (via the "out-of-band" means).

At a given time a total of four self-issued certificates will exist:
OldWithOld; OldWithNew; NewWithOld; and NewWithNew.

X.2. Relying party actions

All relying parties require secure local access to some information,
at a minimum, the name of a CA which is directly trusted by this
entity and that CA's public key, or a self-signed certificate of
a CA. Such local trusted storage is referred to here as the relying
party's Personal Security Environment (PSE).

A relying party may directly obtain using out-of-bands means the
“new with new" certificate. The PSE will then contain two self-
signed certificates, i.e. “old with old" certificate and “new with
new" certificate.

When “out-of bands means” are or cannot be used, a relying party
which only has “old with old" certificate, will need to obtain from
a repository both, the "new with new" certificate and the "new
with old" certificate. It will then verify the "new with old"
certificate using the old key and after acquiring the new CA public
key will verify the "new with new" certificate. The PSE will then
contain two self-signed certificates: the "old with old"
certificate and the "new with new" certificate.

There may be however cases where it is not possible to update the
PSE (e.g. it is "hardwired" into the end entity's cryptographic
equipment). Such relying parties, will need keep in a secondary
storage the two certificates they have acquired and this will allow
relying parties to continue to check certificates up to the end of
the validity period of the “old by old” self-signed certificate.

Finally it may happen that a relying party is only installed with
the "new with new" certificate. Those relying parties will need to
acquire from a repository the “old with new” certificate so that
they may be able to verify certificates issued using the old key.

Denis