> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy > <[email protected]> wrote: > > On 17/01/2018 21:14, Jonathan Rudenberg wrote: >>> 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. > > But what should then be done when that infrequently updated software is > in fact a general end user web browser (as opposed to the previously > discussed special cases of certain payment terminals)? Remove TLS > support? Trust all certificates without meaningful checks? Pop up > certificate warnings for every valid certificate?
Don’t ship browsers that don’t get updates. The surface area is huge and there are many security bugs that are fixed regularly. Shipping browsers in a way that prevents them from being updated frequently is deeply irresponsible. > The way the SHA-1 deprecation was done, with no widely implemented way > for TLS clients to signal their ability to support stronger algorithms, > has in fact created a situation where unreliable hacks are needed to > support older mobile browsers, including feeding unencrypted pages to > some of them. The public stigma attached to this makes this something > that is rarely discussed in public, but is quietly done by webmasters that > need to communicate with those systems. This is false. TLS clients absolutely signal their ability to support specific algorithms, and there are several implementations of serving SHA-1 certificates to insecure clients. > >>> - 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. > > The mechanisms vary by recipient software. But a typical technique > combines a known-unmodified-since date (such as the date of reception or > a date certified by a cryptographic timestamps) to compare the relevant > validity dates in certificates against. > > This obviously needs continued trust in the root certificates > that were relevant at that earlier time, including the ability > if the corresponding CAs to publish and update revocation > information after the end certificates expiry date. (Consider the > case where an e-mail sender's personal certificate was > compromised 1 day before expiry, but that fact was not reported > to the CA until later, thus requiring the CA to publish changed > revocation information for an already expired certificate in > order to protect relying parties (recipients) from trusting > fraudulent signatures made with the compromised key. If this is correct, I don’t see anything that precludes the regular replacement of root certificates. >>> - 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. > > The big problem is that the formats for communicating the certificate > chain from the certificate holder to the relying parties are quite > limited in how they can accommodate different relying parties trusting > different roots from each CA. Requiring CAs to set up extra workarounds > just to satisfy an arbitrary policy like yours is an unneeded > complication for everybody but Mozilla and Chrome. The workarounds are for the root programs that move slowly, not the other way around. >>>> - 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. > > Open the root certificate management interface in most non-Mozilla > software. It's typically a flat list which is already too long for most > people to work with. Recent Mozilla products put the certificates into > a hierarchy by organization, but with some mistakes (for example, Google > is not part of Geotrust, Geotrust is part of the Symantec/Digicert > portfolio). Most people never see that list, and it’s not designed to be useful for people that don’t understand what’s going on, so this point is irrelevant. >>>> - 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 fact is that human site operators DO manage certificates manually. > Outside Let's encrypt and certain other large automated environments > this is the normal situation. If automation had already been the norm, > there was no need for Let's encrypt and its sponsors to develop the ACME > protocol and tools, as they could just have reused the existing tools > you seem to think everybody is using. This is faulty reasoning. There are many non-standard tools and APIs in use, ACME exists to allow consolidation and optimization around a single protocol instead of the proliferation of obscure bespoke APIs and tools with a lot of potential for security flaws. > Humans also manage their personal client/e-mail certificates, unless > tricked into using key-escrowed services. Given that the primary users of S/MIME are Enterprise, this is incorrect. Such certificates are typically centrally managed by an IT department using some level of automation. > Furthermore certificates that are fully validated (OV, EV etc.) > generally involve humans at the subscriber end in the validation > process. The EV BRs give some key examples of such procedures. This is yet another reason why EV/OV is bad, not an argument against automation. > An additional manual process is the "simple" act of paying for a > certificate application, which involves not just the transaction done > during the ordering process, but also the subsequent book-keeping job of > putting the transaction into the correct part of the company accounts. Luckily computer programs are very good at tracking transactions and doing bookkeeping. > You are assuming a level of automation that just isn't there in the real > world. I’m not assuming anything. It’s a fact that this automation already exists, and it’s very clear from the benefits that it will be even more common in the future. Jonathan _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
