Re: Letter from US House of Representatives
On Tuesday, June 30, 2015 at 2:36:57 PM UTC-4, Richard Barnes wrote: Dear dev.security.policy, I wanted to let you all know of some correspondence that happened recently I understand root certificate bundles that are managed by the browser either as part of the OS keybag, or software keybag. I see that the software, either through pinning, reference to a Markle hash tree, or reference to an authoritative list, or even a well known list, can enable the software to identify self signed roots. In addition any user can add their own root and set the trust bits for themselves. So it appears the users have the ultimate decision in regards to evaluation of trust, and some tools that aid them in that decision. I have also read the Certificate Policy and Practices statements by many of the CA that would typically be found in a browser store. The question to me is how does this scale in terms of the trust model when there is obvious manipulation of code signing certificates with state level use case actor malware threats? I have seen this brought up in terms of the discussion of domain constraints and the implementation in the code. I think this brings us squarely back to 1996 when included bundles were the logical choice for browser users. Make it simple, and don't require mutual TLS, which would then also require client based certificates. Then with the industry groups like CAB promoting enhanced identity verification for the added green indicator, a step in the right direction. But this was already part of X.509v1, previous to the RFC-5280 extensions. However unwieldy the X.509v1 model was for the Internet, in that there was very close binding between a X.500 Directory model, and the authentication to the Directory, e.g. X.509 in the original form...there already was established identity in the Directory. Here in the U.S. that organizational identity is supplied by ANSI which registers Administrative Domains, as opposed to DNS domains. The door that was left open in the security of binding the DNS domain to the certificate, say in the subject alternative field lacked this functionality of the original model in which there was a 1:1 relationship between the identity of the X.500 object, and the user certificate that was bound to that object. Many organizations don't try to bite off the entire internet in terms of scope. We see constraints applied everywhere, and they all feed back to enabling legislation, such as the EU trust list example. We are seeing an unprecedented disruption of the CA PKI model with Let's Encrypt, which does fit the bill of enabling every site that wants to do TLS, the ability to do so. I respect Mozilla's commitment to develop policy artifacts in this difficult area and the work of industry fora to build trusted communities. I do think the problem has to be constrained in some shape or manner, and what has existed as the internet death for CA's that don't do adequate protection of private signing keys discussion is a valid lever that the community can use. Or even put that into the hands of the end user. I don't typically go to web sites that fully leverage the full power of the Internet to connect me to 1:* possible connections. Sometimes. I do know when I tried to engineer in a no-sub CA clause my CA balked. They would not put it into the contract. I do think the DNS is inadequate compared to the original X.509v1 model in establishing identity bound to the subject of the certificate. Does that mean that Mozilla should allow for dynamic updating of certificates in Firefox via LDAP? Or DNS?That seems to already be available through DISA X.500, but I am restrained from using that software add on from Milforge. Or is this already built in? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Letter from US House of Representatives
On 07/07/15 02:02, Peter Bowen wrote: 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. Before adopting any vendor's proprietary format, it's probably worth at least looking at this Standards Track RFC... Trust Anchor Management Protocol (TAMP) https://tools.ietf.org/html/rfc5934 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=ENreference=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 -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Letter from US House of Representatives
On 06/07/15 17:44, Ben Wilson wrote: 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. The trouble with this is that, while it makes sense to you or I, Mozilla is not keen to ask users to make decisions where they have no meaningful understanding or basis on which to make that decision. I cannot imagine a UI for select the lists of CAs you trust which would enable a user to make a meaningful decision, or realise when something breaks that it was a consequence of their previous decision. This is why we have a root program, rather than a startup wizard with 100 CA checkboxes to review :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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=ENreference=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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Letter from US House of Representatives
On 06/07/15 15:34, Ben Wilson wrote: =P7-TA-2014-0282 language=ENreference=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
Re: Letter from US House of Representatives
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=ENreference=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
RE: Letter from US House of Representatives
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=ENreference=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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Letter from US House of Representatives
Thanks for sharing this correspondence, Richard. I'm not sure the committee fully appreciates the scope of the problem but it's good to see them make an effort. I was actually surprised that the committee seems to understand as much as they do so perhaps this will be just a first step in a process. Regarding the specific questions asked and answered I would have liked to see the idea of compatibility addressed in a more straightforward fashion. (I'm assuming this is what the letter had in mind when talking about stability?) As you know, the root store is a fixed component with the browser and the only way to change it is to update your browser. Not everyone updates his or her browser, for reasons good, bad, understandable, and so forth. This situation creates certain challenges for website owners when an important behavioral difference appears between versions. If the different browser versions also contain contradictory information in terms of the trusted roots, the software which validates certs, and compliance with government regulations, the potential exists for good websites to become inaccessible. It certainly doesn't benefit anyone when that happens. Obviously this stuff comes up all the time when we discuss the roots and such, but the committee might not have considered it. The extent to which the committee might like to implement regulations or make changes to them over time, they should keep this in mind. I'm not sure it's a technical limitation but it is a limitation nonetheless. Just some thoughts Original Message From: Richard Barnes Sent: Tuesday, June 30, 2015 1:37 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Letter from US House of Representatives Dear dev.security.policy, I wanted to let you all know of some correspondence that happened recently between Mozilla and the US Congress. On June 9, the House of Representatives Committee on Energy and Commerce sent a letter [1] to Mozilla asking for our opinion on the restricting CAs run by governments to issuing certificates for their own properties within their ccTLDs. Mozilla security and policy staff wrote a reply [2] to this letter, highlighting the importance of our open process, and outlining some of the arguments on both sides of the question that were raised in earlier threads on this mailing list. Our reply was delivered June 23. Obviously, we can't change the letter now, but if you have any thoughts or concerns about this interaction, please feel free to reply in this thread. --Richard [1] https://energycommerce.house.gov/sites/republicans.energycommerce.house.gov/files/114/Letters/20150609Mozilla.pdf [2] http://blog.mozilla.org/netpolicy/files/2015/06/Mozilla-Response-to-Congressional-letter-on-CAs-signed.pdf ___ 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
