Thinking about this from a technical perspective, rather than a political one, this seems very similar to a user deciding to add additional certificates to their trust store. I think the primary differences are the need to add a set of certificates and possibly automatically update the list.
If there was a standard for publishing trust lists where the list comes in one file and is signed, then I can imagine an option to "import list" and the list could contain a URL to fetch new versions. Then the user could simply select to use the "EU Trust List", the "China Trust List", or the "US Government Trust List". The browser would periodically fetch new versions of the list, validate the signature (using the key of the previous list), and switch to that list. Microsoft already has their SST format; possibly this could be the starting point for an open format usable by all. This would avoid the need for a vendor to maintain hundreds of trust lists and allow customers to deploy their own trust list policies. Thanks, Peter On Mon, Jul 6, 2015 at 5:30 PM, Richard Wang <rich...@wosign.com> wrote: > According to this clues, as I said in Zurich CABF meeting, China will also > come out a trust list that request browser and OS support. > And other countries will come a list, then Browser and OS need to maintain > hundreds trust list. > Is it a good idea? > > > Best Regards, > > Richard > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On > Behalf Of Ben Wilson > Sent: Tuesday, July 7, 2015 12:45 AM > To: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org > Cc: Tom Ritter; Peter Kurrasch; Eric Mill; Richard Barnes > Subject: RE: Letter from US House of Representatives > > Gerv, > > Thanks. I realize/think that this would require a separate root program. If > you think of it as a Venn diagram there would be Set A and Set B. The user > would then select A, B, A U B or A ∩ B. From a U.S. Government perspective, > I have been told that this is accomplished with a Certificate Validation > Service (CVS) that is maintained by the government, but elsewhere in the > world, there might be the need for multiple Mozilla-distributed trust lists > instead of just one (Sets C, D, E, ...). It's more work, but it avoids > having to address your issues, I think. > > Cheers, > > Ben > > -----Original Message----- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Monday, July 6, 2015 10:29 AM > To: Ben Wilson; mozilla-dev-security-pol...@lists.mozilla.org > Cc: Eric Mill; Peter Kurrasch; Tom Ritter; Richard Barnes > Subject: Re: Letter from US House of Representatives > > On 06/07/15 15:34, Ben Wilson wrote: >> =P7-TA-2014-0282> &language=EN&reference=P7-TA-2014-0282, I was asked >> (by someone in the audience and not by anyone specifically >> representing EU >> governments) to relay a message that some European supervisory bodies >> would like browsers and OS providers to enable and support an >> additional trust list or trust store, specific to the EU, for those >> Trust Service Provider-CA entities that are accredited to issue digital >> certificates in the EU. > > Hi Ben, > > I realise you are just passing on a message, so this should not be taken as > shooting the messenger! I will outline briefly why this request would be, er, > problematic: > > * "specific to the EU" - how do we tell if a particular connection is going > to a website in the EU? On-the-fly IP-based geolocation? This isn't really > possible. Not all websites in EU country TLDs are EU-based, and many in e.g. > .com are EU-based. There is no way to do this; the new CAs would have to be > trusted universally for certs with whatever special marking the EU has in > mind. > > * This proposal would involve Mozilla delegating responsibility for who > Firefox trusts to whoever makes the list of accredited EU TSPs. As we noted > in our letter to the US committee, we value our transparent and open process > for deciding who we trust, and our control of that process is very important > to us. > > Gerv > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
