On Monday, May 22, 2017 at 3:50:30 PM UTC-5, Ryan Sleevi wrote: > Right, but I reject that :) >
I hope to better understand your position. In transitioning from a long time lurker to actively commenting on this list, it is my hope to contribute what that I usefully can, bow out gracefully when I can not, but above all to learn at least as much as I contribute. > > Having said that, I think that future compatibility concerns in the face > > of the potential of more TCSCs being deployed can be headed off by taking a > > firm stance toward the necessity of those entities reliant on TCSCs keeping > > their infrastructure and practices up to date. > > > > Deployment in this mode should probably be regarded as "This is for the > > advanced class. If that isn't you and/or you encounter problems, go back > > to working with a CA for your EE certificates." > > > > A firm stance to use users as hostages in negotiations? Browsers undertake > that with fear and trembling - because as much as you can say it, and the > end of the day, the user is going to blame the most recent one to change - > which will consistently be the browser. It is within the above that I can see a real problem in making more broad use of TCSCs problematic. If the browser community does not effectively move in the fashion of a single actor with a breaking change when necessary for addressing a security concern, I would agree that frankly anything which adds additional field deployment scenarios into the ecosystem will only make things worse. On the other hand, perhaps the lesson to be learned there is that better concensus as to scheduling of impact of breaking changes should be negotiated amongst the browser participants and handed down in one voice to the Root CAs and onward to the web community. The user can't blame Chrome if Safari and Firefox break for the same use case in quite near term. When there is no one left to blame for a broken website BUT the broken website, the blame will be taxed where it is deserved. One particular hesitation that I have in fully accepting your position is that it would seem that your position would recommend a Web PKI with a very few concentrated actors working subject to the best practices and with minimal differentiation. (Say, for example, a LetsEncrypt and 3 distinct competitors diverse of geography and management but homogenous as to intent and operational practice.) The 4 CAs could quickly be communicated with and could adapt to the needs of the community. Extrapolating from LetsEncrypt's performance also suggests it would be technologically feasible for just a few entities to pull this off, too. Yet, I don't see a call for that. Where's the balance in between and how does one arrive at that? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
