Hi Steve, Geoff already replied to you and the list. I agree with his points.
I do have one remaining comment though. It seems to me that the algorithm described in section 8 of res-cert is targeting key roll overs for normal operational CAs. Not CAs that want to be used as TAs... I expect that a planned TA 'roll over' in practice requires a long transition period where top-down validation has to work for both the old and new TA. The additional time between step 3 and 4 is probably not good enough for this, or is it? I expect it should be okay for RPs to keep using only the old TA until it expires, and to already start using the new TA (only) as soon as it's published. In other words I think it might be good to think about another algorithm targeting TAs specifically as well. That way we can keep this one as simple as possible. Any TA roll over strategy will likely have strong ties to the TA structure -- which is still under discussion. I would suggest that whatever structure is chosen by the WG we make it possible for normal CAs that *want* to act as TAs to do so, but we do not require CAs that do *not* want to act as TAs to support a TA roll over. Given the two TA proposals I think it should be possible for CAs to add one level of indirection and present a TA that points to their 'normal' CA cert: - The ETA approach can be used to just put the normal cert in a bag - The simpler approach could use an additional TA-CA that signs an additional certificate sharing the same pub key, SIA etc as the 'normal' CA cert. Thus pointing RPs down to the same tree. But.. I guess there is still a lot of stuff to discuss here.. which is again why I would propose to leave the TA roll overs out for now. Finally, below I just want to give some specific answers to us using a hosted set up: On 7/13/10 10:57 PM, Stephen Kent wrote: > At 3:42 PM +0200 7/6/10, Tim Bruijnzeels wrote: <snip> > > I deleted your example in part because it seems to specific to the > remotely managed CA model, as you note later. > >> Upon receiving a new certificate a new ROA object is generated. Strictly >> speaking this is not necessary, but currently our software is not doing >> smart enough checks to determine this. It assumes that a new certificate >> means more resources or a different validity time, so a new ROA object >> is generated automatically. > > I think one should not mandate generating new ROAs when they are not > strictly required. Again, in an up/down protocol model the CA that is > rekeying can't generate ROAs for its children anyway, so ... Sure, I put something on our back-log to prevent this unnecessary re-issuance. This is a bug related to an over-active propagation of the internal eventing mechanism that is fairly easy to fix. > >> One thing to note is that our implementation is using a fully hosted >> model for the moment. So child CAs are _hosted_ and live in the same >> environment as our production CA. That means that we can actually >> trigger the child CA to request a new certificate, and perform triggered >> effects for itself like re-issuing a ROA object, when the parent has its >> new key 'activated'. > > The fact that your model is based on experience building the hosted CA > approach is worrisome to me. We need to publish standards that are not > biased by this specific model. I'm not saying that what you have done > is wrong, but I don't want SIDR to pursue an approach that is influence > by that model, since it is not the general case (even if it becomes the > most common case). > I understand and agree. The reason that I stressed that we are using a hosted setup is precisely because: a) I can not be as certain whether stuff will be the same for remote b) I want to invite people that do have that experience to jump in.. As it turns out in this specific case there is no problem for child CAs, the parent does not have to wait for a remote child CA when it re-keys to request a new certificate, it can 'push' and just re-issue as described in section 8 of the res-certs draft. Cheers Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
