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? Roque.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
