> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy > <[email protected]> wrote: > > 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.
Distributing WebPKI roots in infrequently updated software is a bad idea and leads to disasters like the issues around the SHA-1 deprecation. > - Used to (indirectly) sign items of long validity, such as e-mails > (Thunderbird!), timestamps and software. I don’t know much about S/MIME, but this doesn’t sound right. Of course certificates used to sign emails expire! That’s obviously expected, and I’d hope that the validation takes that into account. > - 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). This isn’t Mozilla’s problem, and one can come up with a variety of straightforward workarounds. >> - 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. I’m having trouble seeing how sharding roots based on compliance type is a problem. Not doing so complicates reasoning about compliance unnecessarily. >> - 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. Obviously this is completely false. Ridiculous diversions about “real” CAs aside, many other CAs issue certificates to automated management systems and this is obviously the way forward. Humans should not be managing certificate lifecycles. > 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. This is not true. Readers of this list are almost certainly quite familiar with the events that caused Google and Mozilla to protect their users from Symantec’s failures: https://wiki.mozilla.org/CA:Symantec_Issues Jonathan _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
