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

Jeremy Rowley jeremy.rowley at digicert.com
Wed Feb 8 20:58:11 UTC 2017


I don’t understand the reluctance for 400 days? For two extra days you get both substance and style. 

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Wednesday, February 8, 2017 1:25 PM
To: CABFPub <public at cabforum.org>
Cc: Ryan Sleevi <sleevi at google.com>
Subject: [cabfpub] Draft Ballot 185 (2) - Limiting the Lifetime of Certificates

 

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/e181d18c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170208/e181d18c/attachment-0001.p7s>


More information about the Public mailing list