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
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
