Subject: [sidr] key rollover details (long)

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jun 2010 15:43:22 -0400

>The choice of a design note was to delineate the standard 
>specification component of the draft, namely that of a standard 
>profile of fields for certificates, CRLs and certificate requests, 
>from the descriptions of procedures and constraints that were not 
>necessarily an integral part of the standard specification.
>
>With respect to algorithm migration migration, there is an imposed 
>requirement for some level of coordination of actions over an 
>extended period, and also a need for duplication of actions, which 
>is not necessarily the case in key rollover. In one form of the key 
>rollover algorithm (the one documented in draft-ietf-sidr-res-certs) 
>the entity performing the key rollover firstly requests a 
>certificate for the new key, while leaving the old certificate in 
>place. The entity can then wait for replying parties to "catch up", 
>by giving relying parties some time to retrieve the new certificate.

So, the old and current certs for the rekeying CA are simultaneously 
present in the directory of the parent CA at the beginning of the 
rollover but there are no signed products in the rekeying CA's 
directory, yet, right?

>  After this time it is an option for the entity to reissue the 
>subordinate products using the new key, and it is possible to have 
>the old set of subordinate products be overwritten (or replaced) 
>with the new set.

The name generation convention described in the repository structure 
doc causes a new cert file to replace an old cert file whenever the 
public key in the cert remains constant. So I think the design makes 
replacement mandatory (vs. "possible").

Step 8 of the design note on key rollover says that the OLD CA signed 
products are removed at that time. But removal really happens in 
steps 5 & 6, because new instances of the signed products overwrite 
old instances (based on the name generation conventions described in 
the repository structure doc).

I also find the text in Step 5 confusing. I agree with the notion 
that each subordinate CA cert has to be reissued without changing its 
public key, but this step says that the same rule applies to EE certs 
(single and multi-use?) issued by the rekeying CA. This implies that 
a ROA will be replaced by a new ROA that has a new EE cert, but with 
the same public key. That could be a nice feature in that it does not 
require a CA to generate a new key-pair for each ROA and re-sign the 
ROA. But then Step 6 seem to contradict that notion, saying that 
single-use EE certs and associated data structures must be resigned, 
using a new key pair.  That's confusing to me.

The repository publication point discussion introduces the notion of 
OLD, CURRENT, and FUTURE CAs and keys. I like that sort of state 
description. But, the subsequent key rollover discussion fails to 
refer to any CA as FUTURE. I think the text for key rollover needs to 
better adopt this terminology to be complete.

The repository publication point also discussion says that the OLD CA 
will continue to publish a CRL and a manifest covering the OLD signed 
products. But, is also says that new signed products will be issued 
only under the NEW CA. I worry that this might cause problems for 
RPs.  For example, if the rekeying CA generates a new ROA and issues 
it only under the new CA cert, that might cause problems for RPs that 
have not yet fetched the new CA cert. The document says that the CA 
waits a suitable interval before replacing its old signed products 
with new ones, issued under the new CA.  The rationale is to allow 
enough time for all RPs to acquire the new CA cert.  If the CA issues 
any new signed product during the interval before it replaces the old 
products, that seems to imply that the CA can't be confident that all 
RPs will have retrieved the rekeyed CA cert. Similarly, what if a 
child (subordinate) CA requests a rekey during this interval? The 
text seems to say that the new child cert would be issued only under 
the rekeying CA's new cert.  That might pose problems for the child, 
who may have a different notion of how long the overlap interval 
should be. Then there's the case of an emergency rekey for a child. 
if the child wants the old cert revoked immediately and a new cert 
issued in its place, is it OK to issue the new cert only under the 
new CA key?

I think I understand your overall proposal for rekeying, but I am 
concerned about corner cases of the sort mentioned above. The old and 
new certs for the rekeyed CA can overlap in the parent's directory, 
because they have different public keys and thus different file 
names.  The signed products for the rekeyed CA need not overlap 
because RPs have been given enough time to retrieve the new CA cert 
before the new signed products are published, wiping out the old 
signed products. AN RP will not b confused by the presence of the new 
CA cert, because the AIA extension in each CA or EE cert points to 
the old CA cert. (Of course the RP is supposed to use AKI/SKI 
matching to find the right parent CA cert anyway. so even if the AIA 
extension pointed to the directory of the parent CA, the SKI/AKI 
matching would avoid any ambiguity.)

Steve