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