On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote: > Setting aside even the 'damage' aspect, consider the ecosystem impact. > Assume a wildwest - we would not have been able to effectively curtail and > sunset SHA-1. We would not have been able to deploy and require Certificate > Transparency. We would not have been able to raise the minimum RSA key > size. That's because all of these things, at the time the efforts began, > were at significantly high rates to cause breakages. Even with the Baseline > Requirements, even with ample communications and PR blitzes, these changes > still were razor thin in terms of the breakages vendors would be willing to > tolerate. Microsoft and Apple, for example, weren't able to tolerate the > initial SHA-1 pain, and relied on Chrome and Firefox to push the ecosystem > forward in that respect. >
I don't disagree with the ecosystem impact concept to which you have referred. Where I diverge is in my belief that we already do have a wild west situation. There are LOTS of Root CA members and lots of actual roots and way way more unconstrained intermediates. So many that SHA-1 was already a nightmare to deprecate and move forward on. As a brief aside, let's talk about SHA-1 migration and the lessons that should have been learned earlier and how they weren't and how I don't see anything to suggest that it will be better next time, regardless of whether my humble proposal even got consideration -- much less that someone should take up the torch and carry it to adoption. History already provided a great example of urgent need for deprecation of a hash algorithm in the Web PKI. The MD5 deprecation. Not having been a participant other than as an end-enterprise in either of these slow moving processes, I can not say for certain... but... A few Google searches don't make me believe that the SHA-1 migration was any smoother or more efficient than the MD5 migration. As I read, it appears to be arguable that the SHA-1 migration to SHA-256 was even slower and messier. The point I come around to is that in most ecosystems, there's a "criticality" of size at which everything gets harder to coordinate changes. In many such ecosystems, once you cross that boundary, increased size of that ecosystem and number of unique participants has a diminishing effect on the overall difficulty of coordinating changes. What rational basis makes you believe that the next hash algorithm migration will be better than this most recent one? The way I see it, absent some incredible new mitigating circumstances, the next time a rotation to a new hash algorithm is needed, the corpus of Root CA participants and Root CA Certificates / Issuance systems will be larger than it was this time. It seems to get larger all the time, as a trend. My argument is: as probability of smooth transition asymptotically approaches 0, taking actions which ensure that the probability still more closely approaches 0 will have increasingly lower practical cost, as we can just admit it's not going to be a smooth transition. At this point, I feel I should back away. I feel I've made a fairly compelling case (at least, I shall say, the best case for it that I could make) for the limited impact that the specific changes as to Mozilla policy pertaining to audit & disclosure for TCSCs compliant to certain guidelines would have. I also accept that this isn't really the place to lobby for baseline requirements changes. A CA will have to carry that torch, if any are interested. I have very much enjoyed this dialogue and hope that I've contributed some useful thoughts to the discussion. Thanks, Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
