On Monday, May 22, 2017 at 2:21:41 PM UTC-5, Ryan Sleevi wrote: > > > Regarding specifically the risk of the holder of a technically > > > constrained subCA issuing a certificate with an SHA-1 signature or > > > other improper signature / algorithm, my belief at this time is that > > > with respect to the web PKI, we should be able to rely upon the > > > modern client software to exclude these certificates from > > > functioning. My understanding was that IE / Edge was the last > > > holdout on that front but that it now distrusts SHA-1 signatures. > > > > So your proposal is that technical requirements should be enforced > > in-product rather than in-policy, and so effectively there's no need for > > policy for the EE certs under a TCSC. > > > > This is not an unreasonable position. > > > > I think it may be based on an incomplete understanding of the evolution of > the Web PKI. While it's certainly correct that we've been able to > technically mitigate many risks, it's not been without issue. The historic > path to deprecation has been on the basis of establishing some form of > sunset date or requirements change, either within the CA/Browser Forum or > through policy, with the understanding and appreciation that, on or after > that sunset date, it can be technically enforced without any breakage (save > for misissued certificates).
I set forth that there are absolutely limitations to my knowledge, but feel that I have a fair grasp as to the history and to the evolution. > > TCSCs substantially change that dynamic, in a way that I believe would be > detrimental towards further evolution. This is already a concern when > thinking about requirements such as Certificate Transparency - despite the > majority of commercial CAs (and thus, equally, commercially-managed managed > CAs) - TCSCs that are in existence may be ill-prepared to handle such > transition. We saw this itself with the imposition of the Baseline > Requirements, which thankfully saw many enterprise-managed CAs become > commercially-managed CAs, due to their inability to abide by the > requirements, so we can reasonably conclude that future requirements will > also be challenging for enterprise-managed CAs, which TCSCs effectively are. 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. > > 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. Indeed, many mis-issuances which occurred (WoSign, Startcom, Symantec) seem to have been attempts to improperly satisfy end-customer demand for certificates in those kinds of use cases. > > It may be that the benefits of TCSCs are worth such risk - after all, the > Web Platform and the evolution of its related specs (URL, Fetch, HTML) > deals with this problem routinely. But it's also worth noting the > incredible difficulty and friction of deprecating insecure, dangerous APIs > - and the difficulty in SHA-1 (or commonNames) for "enterprise" PKIs - and > as such, may represent a significant slowdown in progress, and a > corresponding significant increase in user-exposed risk. 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. > > This is why it may be more useful to take a principled approach, and to, on > a case by case basis, evaluate the risk of reducing requirements for TCSCs > (which are already required to abide by the BRs, and simply exempted from > auditing requirements - and this is independent of any Mozilla > dispensations), both in the short-term and in the "If every site used this" > long-term. If individual case basis assessment requiring anything more than a "this sunCA certificates meets rule specification XYZ123 and thus requires no CCADB publication and entities below this cert are not subject to audit". then the utility of a distinct TCSC classification become severely limited in usefulness, as it would naturally have a very high barrier to deployment in terms of time-to-approval, time-to-creation, time-to-delivery, etc. It would also necessarily increase the price for the buyer of the TCSC and necessarily increase the cost for the sponsoring CA in man-hours dedicated to the process. It may in fact be that there are risks of TCSCs that I've failed to account for which might well justify such an outcome. 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." Thanks, Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
