Hi Tim, > > 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. >
yeah you are right, that would work. I would also add a time period between 6 and 7 to allow the new material to be fetch before revoking the old cert. > 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.. But you cannot tell to the RP who to trust. Roque > > Cheers > Tim > > >> Roque. >> >> >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
