>> - Key roll-over algorithm >> >> Our software currently implements a specific way to do roll-overs. At >> the time we implemented this it wasn't 100% clear to us how this >> *should* be done, and indeed whether there should be some prescribed way >> to do this. > > I believe that we need to have a single, prescribed way to do this; each CA > needs to know what is expected of it by its subordinate CAs and by all RPs. I > believe we should have a separate document that clearly articulates what a CA > is required to do. There are CA-local aspects to this procedure, as Geoff's > text notes. The parameters for those belong in the CPS for the CA. The > current description is not normative and I think that needs to change. >
You are proposing that the procedure as described in section 8 of draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its own document? The addition noted in the WG mail thread was the addition of a delay between steps 3 and 4, to allow Relying Parties to collect the new CA and add it to their local repository caches. Is there a suggested period for local RPs to refresh their local repository cache at this point? >> >> Currently our software implements key roll-overs using the following >> approach: >> - it uses stable publication directory for a 'logical CA' >> - a 'logical' CA publishes CRLs and manifests for *each* of its keys >> - but it only publishes child objects for the 'active' key >> - old keys only publish a CRL and a manifest containing just this CRL >> - child certificates have a stable URI based on their public key > > I don't understand this description based on the language above. After a lot > of careful reading I believe that I understand what Geoff described in > Section 8 of the res-certs I-D. Since Geoff later said that your description > matches his text, I won't worry about my lack of understanding above :-). I can confirm that I believe that the description matches the text in the draft. > >> I guess the big assumptions here are: >> a) It's okay that two keys share a publication directory. The manifest >> for a key (using a strict filename pattern: keyhash.mnf*) tells you what >> to expect for the specific key. >> >> *: we plan to change the extenstion .mnf to .mft as specified by the >> latest repos draft later.. This was implemented before the draft >> contained this recommendation.. > > I feel strongly that the repository structure document needs to mandate the > file extensions, not make them recommendations. MUST not MAY? > But, that aside, I agree that it's OK to have two manifests and two CRLs at > the same pub point, associated with the old and new CA instances. The naming > convention for manifests and CRLs (which also needs to be a standard to make > this work), accommodates this nicely. I agree here. >> I think option B is the more elegant of the two in that this offers the >> least surprises to the child. On the other hand option A has a possible >> use case for un-planned roll-overs. It allows for a re-key followed by >> revocation of the old production key. In principle this should not >> affect the child unless the child is using its old certificate out of band. > > I think it's appropriate for the rekeying CA to reissue certs for its > children, i.e., option A above. But, it may not be OK to delete the old cert > immediately. I worry about race conditions for RPs. "delete" or "revoke"? The procedure describes "overwriting" at the repository publication point (in order to preserve the integrity of the AIA pointer of subordinate products), but does NOT propose revocation of the overwritten subordinate products of the CA with the old key. > > So, to summarize, I suggest: > > - the design notes in section 8 of res-cert (that deal with key > rollover) need to be removed and made into a separate, standards track > document document. As Geoff has already noted, that text needs to be updated > to insert delays in the process to minimize the likelihood that an RP will > acquire an inconsistent set of repository objects. I am still concerned that > such delays may not suffice, but I'll need to make a case for that when we > have a revised description. agreed > > - we do not assume strict top-down tree walk for RPs when we analyze > possible race conditions re rekeying. specifically, it may be useful to consider RPs performing AIA "walks" as described in Tim's note, in which case preservation of the integrity of the AIA chain during the process is of importance. > > - the respos-struct document needs to mandate file extensions and > naming conventions, rather than merely proposing them as recommendations. If > we say that we can have two manifests and two CRLs in a directory, one per CA > key instance, then it seems important that we all agree on how the names for > these files are generated. this seems appropriate to me > > Finally, I am concerned that we have made almost no progress on the top-level > questions I posed about alg migration. Geoff responded to my message, I > replied to him, and then the discussion stopped. my apologies - other circumstances have arisen that take my attention. > > My concern is that we could adopt a simple key rollover scheme and associated > repository structure that is very different from what we may determine that > we need for alg migration. If so, then when we add support for alg migration, > we probably will impose an overlay on the repository system that makes the > overall system much more complex. Moreover, I anticipate that we will gain a > lot of experience with key rollover in 2-3 years. But, alg migration may not > begin for 5 years or longer. if we use the same procedure for both, we will > have experience from the key rollover process that translates directly into > alg migration. If not, then we will have little basis for confidence when it > comes to alg migration. That may not satisfy the goal that Tim set for us, > and it may cause us terrible problems down the road. My concerns, as noted in the rpki-algs draft, is to avoid what could be construed as gratuitous duplication in the RPKI on the basis that what would be highly undesireable was an outcome where a ROA could be validated with algorithm A, but an equivalent assertion could not be validated in the realm of algorithm B. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
