Hi Steve, On 7/14/10 4:48 PM, Stephen Kent wrote: > At 12:27 PM +0200 7/14/10, Tim Bruijnzeels wrote: >> 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... > > are you referring to a CA that uses the WG-selected method to publish > info to make it accessible as a TA, or are you referring to the local TA > management mechanisms that are described in draft-reynolds-rpki-ltamgmt-00? >
No, I was still referring to the remark made by Roque that the algorithm in section 8 (res-cert) would cause problems for RPs that choose to use a CA cert somewhere in this chain as their TA. Top-down will break for the old key's certificate. The extra time between step 3 and 4 was proposed to give these RPs a little more time to adjust. I believe that this extra time should be good enough. It's an algorithm that in my experience is implementable and I am very much in favour of preserving the AIA one level down. I regret proceeding to go into too much detail about possible other *TA* roll overs. I was thinking about 'draft-iets-sidr-ta' and 'draft-weiler-sidr-trust-anchor-format' as possible ways for any CA to publish their own certificate as TAs. I am afraid I confused the discussion by going into the how and why this is more difficult. My main point is that it is, in my mind, a different ball game and therefore I would suggest to not place additional constraints on normal key roll overs except for the extra time between step 3 and 4 already proposed. It may be interesting to discuss possible roll over scenarios for the two TA drafts I am referring to as well, but probably that should be done in its own thread. It may also be interesting to discuss this in Maastricht. I hope this makes my point more clear. Cheers Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
