On 17/01/2018 16:13, Jonathan Rudenberg wrote:
On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy <[email protected]> wrote: Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance.
I would say, that to limit the danger that such an essentially unused CA operator turns rogue, only CAs that provide certificates for public trust should be admitted in the future, more on that in another post.
I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis.
This may be fine for TLS root CAs that are distributed in frequently updated browsers (such as Firefox and Chrome). It is absolutely fatal for roots that are also used for any of the following: - Distributed in browsers that don't get frequent updates (due to problems in that distribution channel), such as many browsers distributed in the firmware of mobile devices, TVs etc. - Used to (indirectly) sign items of long validity, such as e-mails (Thunderbird!), timestamps and software. - Apply for inclusion in other root programs with slow/costly/ inefficient distribution of new root certificates (At least one major software vendor has these problems in their root program).
- Make all certificates issued by CAs under a root that is trusted for TLS in scope for the Baseline Requirements, and don’t allow issuing things like client certificates that have much more relaxed requirements (if any). This helps avoid ambiguity around scope.
Again this would be a major problem for roots that are used outside web browsers, including roots used for e-mail certificates (Thunderbird). The ecosystem already suffers from the need to keep multiple trusted root certificates per CA organization due to artifacts of existing rules, no need to make this worse by multiplying this with the number of certificate end uses.
- Limit the maximum validity period of leaf certificates issued to a sane upper bound like 90 days. This will help ensure that we don’t rust old crypto and standards in place and makes it less likely that a CA is “too big to fail” due to a set of customers that are not expecting to replace their certificates regularly.
This would be a *major* problem for any end users not using Let's encrypt, and would seemingly seek to destroy a major advantage of using a real CA over Let's encrypt. The only "too big to fail" problem we had recently was when the oldest, and biggest CA ever was forced out of business by some very loud people on this list. And the problem was that those people demanded rushed punishment in the extreme with little or no consideration for who would be hurt in the process. All in all, such a requirement would do nothing but harm.
I think with these and other similar requirements, we move closer towards ensuring that the roots accepted are operated with the high level goals described by Alex in mind, and allow more agility at the root store level to respond to issues. Jonathan
Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
