On Mon, May 22, 2017 at 4:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I'm not certain that I accept the premise that TCSCs fundamentally or > substantively change that dynamic. Particularly if the validity period of > the TCSC is limited in much the same manner as an EE certificate, it would > seem that there's a sufficiently limited time window to changing any needed > aspect of the restrictions in a TCSC. >
Right, but I reject that :) The window of change is not simply the validity window of the extant certificates. That is, you cannot, at T=1, necessitate some change from T=0. The approach that has been used has been to phase in - e.g. after T=[some point in the future], all publicly trusted certificates need to change. The success or failure of the ability to make those changes has been gated upon the diversity of the ecosystem. That is, technically diverse CAs - those that operate on diverse infrastructures, perhaps over the course of several years of acquisitions - have been the most difficult to adapt to changing requirements. Those with homogenous infrastructures have demonstrated their willingness and ability to change in a timely fashion. When you extend that to TCSCs, it simply doesn't scale. Changing an algorithm like SHA-1, on the extreme side, is no longer a centralized problem, but a decentralized one. That's the benefit being argued for TCSCs, but its also the extreme detriment. On the other side, things that should be 'simple' changes - like the proper encoding of a certificate, which apparently CAs find remarkably hard, are now matters of coordinating between ISVs implementing, organizations deploying, testing, etc. In today's world, this is a problem, but not an overwhelming one. In a world of TCSCs, it certainly is. > > > > > Consider, on one extreme, if every of the Top 10000 sites used TCSCs to > > issue their leaves. A policy, such as deprecating SHA-1, would be > > substantially harder, as now there's a communication overhead of O(10000 > + > > every root CA) rather than O(# of root store CAs). > > I definitely concede that there would arise risks in having more TCSCs in > deployment, with respect specifically to compatibility, if and only if an > expectation of lax timelines and enforcement were required. > > I think the key issue which held back the SHA-256 migration was not CA > readiness as much as server administrator and consuming application > (generally proprietary non-browser stuff on dual-propose (web + proprietary > interface) shared endpoints) pushback. > Unfortunately, this is not an accurate summary :) The SHA-256 migration was very much held back by CA readiness, moreso than server administrator unreadiness. Many CAs were simply not capable of issuing SHA-256 certificates as recently as late 2014/early 2015, either directly or through their APIs. And we're talking LARGE CAs. > I think part of the right balance would be to presume that those who are > advanced enough to use TCSCs will do what maintenance is necessary to > continue to comply with technically enforced browser requirements, assuming > there is reasonable notice of those changes. Ultimately, it should also be > a burden of the sponsoring CA to communicate to their TCSCs about impending > changes. > There is no such evidence to support such presumption, and ample evidence (as from the BRs) to suggest it doesn't work. While I agree it should be the burden of the sponsoring CA, the externalities are entirely incorrect to ensure that happens. That is, if a CA fails to communicate, much like SHA-1 saw, then it becomes an issue with a site operator/TCSC operator being ill-prepared for a browser change, and the result is a broken site in the browser, which then further increases warning fatigue on the user. In an ideal world, it'd work like you describe. The past decade of CA changes have shown the world is anything but ideal :) > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
