> In your case below, the officer of the respective agency would call > the Browser_Vendor office and ask to immediately delete the > particular IP-CA pairs from the SECURE MIRROR BOOTSTRAP file that > could be traced through a chain of SECURE MIRRORS to the target > SECURE MIRROR, Then some SECURE MIRRORS could be reconnected back > when they confirm manually that they have no downstream trace to the > target SECURE MIRROR. I think there was a misunderstanding about how the SECURE MIRROR BOOTSTRAP works. I also didn't go into full details about the process. The Browser Vendor does not get to pick the SECURE MIRRORS it will use. It pulls a sample of the network from the SECURE MIRRORS NETWORK following the same rules and uses secure channel to pre-install it. Any attempt by the browser vendor to remove or "curate" the SECURE MIRROR BOOTSTRAP would be futile, as the second step in the process is the browser using that BOOTSTRAP to contact all the SECURE MIRRORS listed, and ask all of those SECURE MIRRORS for the full list of SECURE MIRRORS known the them. Once the SECURE MIRROR BOOTSTRAP process is complete, the browser maintains a list of all the SECURE MIRROR known to it. In future updates to the IP-CA list, the browser does not use the SECURE MIRROR BOOTSTRAP from the vendor, but rather contacts an assortment of the SECURE MIRRORS already known to it to get updated data. Further, browser users can specify a SECURE MIRROR BOOTSTRAP source in the browser, just as they can now specify their local DNS provider. In short, the browser vendor does not dictate which SECURE MIRRORS are used. It just provides a small sample of them in a one time startup process, so the browser can find all of them on the entire network. After that, SECURE MIRROR communications and updates do not go through the browser vendor, but directly to the network.
