“It would be helpful for a wide range of users (enterprises, non-profits, educational institutions, partners, resellers, device manufacturers) to provide input into this discussion to help the community formulate opinions on this major change.”
In an enterprise scenario, 1-year certs would make things better. We restricted all enterprise issuance to a max of 2 year certs simply because it was the minimum of the max-validity of EV and DV. What we later found is that sometimes, even after only 2 years, the people that originally installed/configured the certs did not remember how to install the cert on their platform, or aren’t on the same team anymore (and if they aren’t, they may not know who should be responsible). Most of that is easily corrected with documentation and process, but for the vast majority of people, certs aren’t their day to day life, and restricting to 1-year would assist in keeping the memories of installation and renewal at least a little fresher in their minds, help with budgeting, and of course, help the ecosystem overall. To Doug’s earlier question, “If the cert is 1 year vs. 3 is there a difference?” Yes, (trying not to be too tongue and cheek..) there is. It’s a difference of 2 years of waiting before the browsers, CAs, and site operators can be assured that certificates that don’t meet standards/baselines are phased out, it allows everyone to move forward with more agility. In just one example, it’s a difference of knowing that in October of 2018, all publicly trusted certs (valid in Chrome) will be in CT logs, rather than waiting until October of 2020 to be in a place where a site operator can rely on that detective control for misissuance. -Carl From: Public [mailto:[email protected]] On Behalf Of Dean Coclin via Public Sent: Wednesday, February 01, 2017 3:02 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Dean Coclin <[email protected]> Subject: EXTERNAL: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates We’ve discussed certificate lifetimes at several F2F meetings and I especially recall the Zurich meeting where I tried to see where folks stand by putting up a chart with different options for cert lifetimes. As I recall , there was no consensus. Some CAs were in favor of extending EV to 3 years but browsers made it clear that was not on the table. Some browsers talked about reducing all certs to 1 year but many CAs said that would not be welcome by the vast majority of businesses that purchase and use certificates in various applications. I seem to recall some CAs reaching out to enterprise customers to get their opinions. I have to dig a little deeper to find that information but maybe someone on the list has that readily available. Is there some rationale for the 12/13 month selection? Why wasn’t 6/9/14/18 months considered? It appears a balance is being sought but it is unclear what parameters are being weighed in this decision process. It would be helpful for a wide range of users (enterprises, non-profits, educational institutions, partners, resellers, device manufacturers) to provide input into this discussion to help the community formulate opinions on this major change. Dean From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Tuesday, January 31, 2017 10:50 PM To: CABFPub <[email protected]> Cc: Ryan Sleevi <[email protected]> Subject: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates I'm looking for two endorsers to publicly endorse this ballot. 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 ___ of ___ 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 twelve (12) months. 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 twelve (12) months. EV Certificates issued prior to 1 May 2017 MUST NOT have a Validity Period greater than twenty seven (27) months. """ -- MOTION ENDS --
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
