On 09/07/2010, at 1:56 AM, Tim Bruijnzeels wrote: > Hi Roque, > > On 7/8/10 2:56 PM, Roque Gagliano wrote: >> Hi Geoff, >> >> Just considering this case: >> >>> If a RP choses an intermediate CA as a TA then it has to factor in the >>> potential for the CA to perform a key rollover, and it has to perform the >>> switch of the locally chosen TA within <a period>. >> >> Wouldn't it be the case that since the RP perform the locally chosen TA >> switch until the end of <a period> it will not be able to validate the >> subordinate certs? >> > > The way I see it the extra time between steps 3 and 4 should allow the > RP to *add* the new certificate to its TA*s*. By adding the NEW cert to > a list of TAs and treating their subordinate objects cumulatively the RP > could prepare itself for the switch. Then when the switch is activated > the old certificate is effectively phased out, at least for top-down > purposes.
Yes, thanks Tim, I can confirm that this was indeed the intent. > > But I still think that it is an open question whether any CA should be > expected to support the use of its certificates as TAs by others. There > is an existing proposal about the TA structure and discussion about an > alternative. I don't really want to start that whole discussion here > again, but it goes to show that TAs require some special treatment. > > My feeling is that implementation is made a lot more difficult if the > must-be-usable-as-TA requirement is imposed on all levels. In other > words: if a CA actually wants to be able to act as a TA it can take > measures to do so. Use the appropriate format (to be determined) with a > suitable roll-over (phase out?) strategy. If a RP chooses to make a CA > that is not prepared to this a TA, then maybe it's also up to the RP to > just update when that CA rolls over.. Again, I agree with this perspective. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
