Proposal to Modify the pkix part3 ROOT CA Key Change Protocol

[Trevor Freeman <trevorf@xxxxxxxxxxxxx>]

As part of my work on CA's with multiple algorithms, I believe I have
developed a simplified scheme to enable ROOT CA's to bind certificates
together. ROOT CA's are required to bind certificates together to
establish they are published by the same entity when they:
	wish to replace their own Certificate near the end of its
validity period,
	wish to publish multiple ROOT Certificates with the same
algorithm
	wish to publish ROOT Certificates with different algorithms.

The Method.
The same sequence of certificates is generated as currently proposed in
pkix part3, but a date independent method of determining there purpose
is possible and I believe simpler.
	Cert-A is a  ROOT certificate for subject ROOT-CA, containing
Pub-a, KeyID-a and is signed by Pri-a.
	Cert-B is a  ROOT certificate for subject ROOT-CA, containing
Pub-b, KeyID-b and is signed by Pri-b.
	Where
	Pub-a is Public Key a
	Pri-a is the private key which corresponds to Pub-a
	Pub-b is Public Key b
	Pri-b is the private key which corresponds to Pub-b
	KeyID-a is the Key identifier for the A key pair
	KeyID-b is the Key identifier for the B key pair.

To bind Cert-A and Cert-B together, to establish they are from the same
authority, a pair of Binding certificates is generated. (Sign A with B
and Sign B with A - equivalent to the old with new and new with old as
per pkix)
	Cert-C is a ROOT binding certificate for subject ROOT-CA,
containing Pub-a, KeyID-b and is signed by Pri-b
	Cert-D is a ROOT binding certificate for subject ROOT-CA,
containing Pub-b, KeyID-a and is signed by Pri-a
Options for identifying which certificate is which.

1 Deduction my dear Watson.
This requires some trial and error with certificate validation.
Certificate A and B are from homogeneous key pairs, that is the public
key they publish and the private key used to sign the certificate is the
same key pair. ROOT binding certificate keys are from heterogeneous
pairs, therefore the Public key they contain will not verify the
certificate. This homogeneous/heterogeneous feature can be therefore be
used to distinguish ROOT certificates from Root binding certificates.
Identifying ROOT certificates also identifies the KeyID for the ROOT
Public key pairs. Having identified the KeyID's, the public key in
Cert-B, can be used to verify Cert-C, thus establishing the link between
Cert-B and C. Likewise the KMID in Cert-D shows that the Pub-a key in
Cert-A will verify Cert-D and establishing the link between Cert-A and
D.
2. Extra Key Identifier Extension.
This requires an extra extension in the ROOT binding certificates.
If an extension with the KeyID of the key pair belonging to the public
key in the certificate in addition to the normal Key Identifier of the
signing key, identifies exactly which ROOT binding certificate is which.
You have one KeyID indicating the identity of the Public Key pair
belonging to the public key and another KeyID indicating the identifying
of the key pair used to sign the certificate. Knowing the key pairs in
question, then the correct key should be used to verify each certificate
first time.

As these methods do not rely on dates to identify the purpose of a
certificate. If a CA wishes to publish two or more ROOT certificates,
with the same validity dates with the same or different algorithms, this
is possible under this scheme. The scheme also supports the renewal of
an expiring ROOT certificate.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435