On Mon, May 22, 2017 at 12:50 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 22/05/17 16:43, Matthew Hardeman 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). 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. 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). 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. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
