[cabfpub] Draft Ballot 185 (2) - Limiting the Lifetime of Certificates

[Ryan Sleevi]

Changes in this draft compared to the last draft (
https://cabforum.org/pipermail/public/2017-January/009373.html )
- Changed 12 months to 398 days, following the recommendation in
https://cabforum.org/pipermail/public/2017-February/009449.html
  - Why: As Peter Bowen pointed out, utilizing a days-based approach offers
the benefit of being a consistent duration, whereas 13 months could vary
from being 365 + 28 days (Jan 1 -> Feb 28) to 366 + 28 days (Jan 1 of a
leap year -> Feb 28) to being 365 + 29 days (Jan 1 -> Feb 29). Further, by
utilizing days as the unit of measure, it allows for easier implementation
of those measuring compliance (e.g. whether Feb 28 -> March 31 = 13 months)
and for issuance (What day is 13 months from Jan 31?).
  - I understand and appreciate Kirk's concerns in
https://cabforum.org/pipermail/public/2017-February/009450.html , but I do
not agree with the analysis; as this is a fully technically quantifiable
measure, it does not require human vetters to make sense of it, and for
those CAs that employ human vetters, it allows sufficient flexibility to
address this via that individual CA's CP/CPS
  - I understand and appreciate Scott's concerns in
https://cabforum.org/pipermail/public/2017-February/009485.html , but the
argument that 400 days is easier for humans to calculate has no evidence of
support, and there's no technical argument provided. While I acknowledge
it's aesthetically appealing, we should focus our efforts on substance over
style.

>From the non-CA, non-browser participants on the list - and those
requesting reposting - I believe we've seen support for this.
  - Eric Mill:
https://cabforum.org/pipermail/public/2017-February/009484.html
  - Carl Mehner:
https://cabforum.org/pipermail/public/2017-February/009433.html
  - Walter Goulet:
https://cabforum.org/pipermail/public/2017-February/009492.html

We've seen analysis about what is the 'floor' for the ecosystem to affect
change ( https://cabforum.org/pipermail/public/2017-February/009483.html ),
but luckily, this ballot focuses on new certificates. By targeting 1 May
2017, any potential impact on subscribers does not manifest until June
2018. As to practical impact, we know that 56% of the sites most used by
Relying Parties are already compliant with, or more aggressive than, this (
https://cabforum.org/pipermail/public/2017-February/009437.html ), so we
know that it is both technically and humanly possible.

The remaining substance of the opposition largely centered around the
argument that "customers prefer X", without any representation from CAs on
behalf of the far more numerous Relying Parties, which Browsers are
effectively responsible for proxying and who are disproportionately
affected by such CA practices. Given how we see Browser members
differentiating themselves on their security properties, and
correspondingly see that reflected in both the media reports on browsers
and through user surveys, we can quite reasonably conclude that security is
important to relying parties.

This ballot improves security two-fold:
First, it allows the CA/Browser Forum to continue its careful deliberations
about when new changes will be effective and required, while also providing
greater assurance to Relying Parties that these changes can actually be
technically enforced - regardless of what those changes are.

Second, by more closely aligning with the annual audit period, it allows
Relying Parties to be confident that if an issue is noted during an annual
audit, the duration of 'impact' from that issue will be limited to, at
most, 13 months (for certificates issued on the last day of the period of
audit), or less (for certificates issued closer to the start of the period
of audit), rather than the current possibility of 39 months (for new
certificates), or the possibility that it's been ongoing for years (and
that previous audits failed to detect it, but those certificates are still
valid). This allows for more targeted and careful remediation steps than
have been necessary in the past, thereby allowing a broader deployment of
such steps, thus better protection for more users.


At this point, I believe I've addressed all meaningful objections or
concerns raised, and would like to see this proceed. I've had several
offers for endorsement privately, but to avoid any misinterpretations, I'll
let them re-confirm on the list and we can proceed to a vote.


Background:
The validity period of certificates represents the single greatest
impediment towards improving the security of the Web PKI. This is because
it sets the upper-bound on when legacy behaviours may be safely deprecated,
while setting a practical lower-bound for how long hacks and workarounds
need to be carried around by clients.

Further, in the event of misissuance related to internal control failures,
rather than external security failures - for example, misissuance due to
failing to properly vet subject information - the validity period
represents the risk and exposure to customers and relying parties in the
absence of revocation information (for example, constrained environments).

To keep this vote simple, it avoids any discussion of the reuse of
validation information, described in Section 4.2.1 of the Baseline
Requirements and Section 11.14.3 of the EV Guidelines.



The following motion has been proposed by Ryan Sleevi of Google, Inc and
endorsed by Josh Aas of ISRG and ___ of ___ to introduce new Final
Maintenance Guidelines for the "Baseline Requirements Certificate Policy
for the Issuance and Management of Publicly-Trusted Certificates" and the
"Guidelines for the Issuance and Management of Extended Validation
Certificates"

-- MOTION BEGINS --
Modify Section 6.3.2 of the "Baseline Requirements Certificate Policy for
the Issuance and Management of Publicly-Trusted Certificates" as follows:

Replace Section 6.3.2 with:
"""
6.3.2. Certificate Operational Periods and Key Pair Usage Periods

Subscriber Certificates issued on or after 1 May 2017 MUST NOT have a
Validity Period greater than three hundred and ninety-eight (398) days.

Subscriber Certificates issued prior to 1 May 2017 MUST NOT have a Validity
Period greater than thirty-nine (39) months.
"""

Modify Section 9.4 of the "Guidelines for the Issuance and Management of
Extended Validation Certificates" as follows:

Replace Section 9.4 with:
""""
9.4 Maximum Validity Period for EV Certificate
EV Certificates issued on or after 1 May 2017 MUST NOT have a Validity
Period greater than three hundred and ninety-eight (398) days.

EV Certificates issued prior to 1 May 2017 MUST NOT have a Validity Period
greater than twenty seven (27) months.
"""
-- MOTION ENDS --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170208/2649107a/attachment-0002.html>