Hi Nick, 1. Indeed, manual "SECURE MIRROR BOOTSTRAP" file installation by the user would help. But is it different from the current situation when I manually installed a government-authorized root certificate? A) XX millions of people did not even try to do it because it is very complicated for them B) I do not know how many have installed the fake certificate as a result The government in my country has a so-called "multi-functional service center", typically within walking distance. It is a "unified window" for the great majority of government services. MFS is already doing many-many government-related services that need a physical presence (like receive a passport or get credentials to the government portal) or if the old lady is not capable of doing something on the portal/application herself. It is probably a good idea to ask MFS for an additional service for the root certificate installation. Unfortunately, not everything (refrigerator? washing machine?) is possible to bring to this center. Hence, the trusted root certificate movement procedure "from smartphone to anything else" is a good feature (I am not sure that it should be in a browser). It is probably good even for smartphones to exchange it with each other (if owners trust each other). Of course, social engineering would break such a mechanism, but social engineering could break many things anyway. The compromised user could visit MFS again to refresh the trust. People could change their trust anchor on the business trip (to a different country). The principal thing here is that people trust physical people (that is even more reliable if the source is an official), not the hacker on the Internet. Block the possibility for easy remote trust establishment (professionals would find a way anyway - it does not matter). Hence, my proposal: give people the possibility to easy exchange the root trust anchor on physical contact (WiFi, Bluetooth, etc). They would sort everything else themselves. Such an application on a smartphone should probably ask for acceptance about every root certificate shared if many are available on the source smartphone. 2. I do not understand why you believe that filtering starting from the Browser_Vendor is not possible. IMHO: it is perfectly possible to properly negotiate with the Browser_Vendor to exclude the sources traced to unwanted certificates. Eduard -----Original Message----- From: Nick Lockheart <lists@xxxxxxxxxxxxxx> Sent: Thursday, August 15, 2024 22:39 To: ietf@xxxxxxxx Subject: Re: Near-Real-Time TLS and DNS Validation using a Multi-Vantage-Point Network of Secure Mirrors > 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.
