> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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 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. - 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. - 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. 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
