[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
sleevi at google.com
Fri Aug 23 14:35:54 MST 2019
I've attempted to address the concern from some CAs with respect to the
March timeline, by moving it to April, in
Note: I've *not* yet circulated an updated ballot, as I wait for the
co-endorsers to review these changes.
Explanation for the Changes:
This attempts to address the concerns raised by some CAs that there would
be substantial confusion with a March date, by moving it to April.
In addition, some CAs have suggested that they have customers for which no
certificate profile changes can be made during a holiday freeze (e.g. from
the period beginning October-November through a period of February-March).
This helpfully ameliorates and addresses that concern. However, it's worth
emphasizing that such lack of flexibility is an existential threat to the
security of the Web PKI, by undermining the inherent agility. As the past
decade of compromises and misissuances have shown, CAs and their customers
must be prepared for changes in certificate profiles and expectations, and
should be careful as to what assumptions they place upon the certificate
profile. Customers that wish to control or restrict the certificate
profile, or are limited in their ability to make or respond to changes, may
be better suited through transition to Private/Internal PKIs, to better
accommodate that risk.
Unfortunately, for the Web PKI, we can't expect that no ecosystem impacting
events will respect our schedules, and thus the best way to prepare for
that is to routinely execute these changes, throughout the year, so that we
know emergency procedures are well-tested and well-functioning. This is
very similar to testing of the emergency broadcast system, fire drills, or
disaster preparedness exercises, such as those the CAs are required to
exercise regularly. By having playlists and checklists that are well
understood and well-tested, we all improve security.
In addition to the change to April, it was pointed out that an attempt at
providing clarity in the EV Guidelines with respect to the Baseline
Requirements inadvertently had the effect of undermining all of the
security gains, at least under a malicious interpretation of the
requirements. A current CA could read the EV Guidelines and determine that,
having once validated a domain name or an organization name, they would
never be required to revalidate again, even in the presence of a revoked
certificate! It was even pointed out that the issuing CA could perform no
validation themselves! This is a similar sort of loophole to one which
Ballot 190, and then the subsequent work of the Validation WG, was trying
to close, so I'm sure this was entirely accidental.
Specifically, this *allows* a CA to reuse certain EV Validation
information, as described in 11.14.1, for the period described in 11.14.3.
It *does not* allow 11.14.1 to override 11.14.3, and it *does not* allow
11.14.3 to override the Baseline Requirements. Additionally, it allows an
EV certificate to be reissued, pursuant to 11.14.2, without requiring
additional EV validation, provided that such validation still complies with
the Baseline Requirements.
I would greatly appreciate focused attention on these three sections -
11.14.1 - 11.14.3 - and the proposed change, both individually and within
the overall context of https://github.com/cabforum/documents/pull/138 .
Hopefully, there's wide agreement and consensus that the EV Guidelines do
not override the Baseline Requirements, and in the value of ensuring the
information is fresh and accurate for EV certificates, just as we do for OV
and DV. I can't imagine it was intended to create a certificate profile
that was weaker than DV or OV, and thus would appreciate review to ensure
that EV remains an improvement upon existing validation processes, and not
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg