On 08/07/2010, at 9:44 PM, Roque Gagliano wrote: > Hi Geoff, >> I disagree here Roque. You may want to think carefully about the AIA >> pointers of the subordinate certificates, and think about why the documented >> procedure says: >> >> 5. The CURRENT CA will generate new certificates for >> all existing subordinate CA and EE certificates, >> and publish those products in the same repository >> publication point and with the same repository >> publication point name as the previous OLD >> subordinate CA and EE certificates. The keys in >> these reissued certificates must not change. >> > > The use case that I presented refers when a RP uses (for whatever reason) the > OLD CA cert as TA and performs TOP-DOWN validations using the OLD CA SIA > information. > > Between step 5 and 7 (i.e. since I generate the new material signed by the > CURRENT CA and until I revoke the OLD CA cert), when accessing the OLD CA > publication point (following Tim example), the RP will only be able to > validate a manifest and a CRL. All the rest of the material in that > publication point is signed by the CURRENT CA that the RP cannot validate as > its TA is the OLD CA cert. It should be expected that the RP will eventually > change its TA to the CURRENT CA cert sometime before step 7. > > I agree that having the OLD and CURRENT signed subordinate certs/signed > materials in the same publication point generates a problem with AIA pointers > downstream. > > What do you think about this particular case?
I said in an earlier posting on the same topic that what was _not_ documented in the notes in the res-certs drafts was for the entity performing the key rollover to wait for <a period> between steps 3 and 4 to allow the NEW CA certificate to be published and to allow Relying Parties to collect this certificate and load it into their local cache. That way, when the NEW CA executes step 5, relying parties will be in a position to recognise these subordinate objects as valid. Some previous thoughts of the appropriate value of the period was 24 hours, assuming that Relying Parties use a refresh cycle of a similar or shorter duration. 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>. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
