That’s a good report Richard and it shows there is an ongoing need for customers to obtain 2 and 3 year certificates. If we’re going to impact such a large customer set we should have a solid reason for doing so.
I don’t understand this how this is the “single greatest impediment towards improving the security of the Web PKI” or how misissuance decreases with shorter validity periods. While the SHA-1 deprecation was difficult, this primarily was driven by customers technical ability to give up SHA-1 and not with the technical ability of the CAs to change over. We should be able to roll out Web PKI security improvements that don’t involve significant technology updates by customers much more easily (CAA and CT for example). We now have a CT drop-dead date and I would expect CAA is next once we can agree on the details. Let’s work together to make this happen. If there are significant numbers of certificates with invalid/outdated DN information then we need to address this (is this true?), but that does not necessarily mean short validity certificates or shorter re-use periods. Further, when we find such certificates, regardless of validity period, they need to be revoked and the revocation status needs to be respected by the Web PKI. Today the revocation process is broken. As Dean said previously, this was discussed without resolution a while ago and I haven’t seen consensus or constructive discussions on recent proposals to change either the maximum validity period or re-use of vetting data. Assigning across the board values for max validity and vetting data is shortsighted. These should be set based on risk and business processes and not “being consistent for the sake of being consistent”, or “making Web PKI more secure”. We must understand the issues we’re trying to solve and come up with an approach that is acceptable to TLS customers, CAs, Root programs and balance security with usability vs. applying a blanket 13 max across all certificate types “just because”. I’d propose that this be taken up in a working group where the necessary discussions and requirement gathering can be done. Doug From: Public [mailto:[email protected]] On Behalf Of Richard Barnes via Public Sent: Thursday, February 2, 2017 10:24 AM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Richard Barnes <[email protected]> Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates On Thu, Feb 2, 2017 at 6:17 AM, García Jimeno, Oscar via Public <[email protected]<mailto:[email protected]>> wrote: I’d like to give you some numbers of SSL certificates issued by Izenpe. We have DV (1, 2 or 3 years), OV (1, 2 or 3 years) and EV (1 or 2 years) certificates: EV 1 year -> 7,33% EV 2 years -> 92,67% OV 1 year -> 30,93% OV 2 years -> 0,22% OV 3 years -> 68,84% DV 1 year -> 22,54% DV 2 years -> 0,00% DV 3 years -> 77,46% From the Firefox perspective, counting across all certificate types, and in units of validations (not certificates): <= 12 weeks -> ~20% 13 - 52 weeks -> ~11% 53 - 72 weeks -> ~20% 72 - 104 weeks -> ~12% >= 105 weeks -> ~38% https://mzl.la/2kwemdt It’s clear that customers (normally) prefer to have more usability and sacrifice some security; they don’t want to have to renew all their certificates every year. I'm sure customers would *prefer* not to have to deal with certificates at all :) I actually draw the opposite conclusion from these data, namely that it's totally feasible for a lot of web sites to live with lifetimes that are close to a year. 50% of validations that Firefox does are for certificates lasting less than 18 months! In other words, there's a difference between "would prefer" and "can tolerate"; we should be looking toward the latter; and the threshold of viability there seems pretty close to what the draft ballot proposes. --Richard I suppose this situation is the same for every CAs. Of course we need to think about security, that’s because in Izenpe we have defined a policy where we need to validate all documents every time, it doesn’t matter if it’s a new application or a renovation. And it’s not the same a DV than an EV, validations for EVs as you know are much harder. If we force all clients to renew all their certificates every year, probably they would request DVs or OVs instead of EV, because they are easier to get. Therefore I think we would reduce security, reducing the quality of certificates. One possible intermediate solution would be to limit the lifetime of all certificates to 27 months, and restrict some more the reuse of validation information (ballot 186). .eus gara ! horregatik orain nire helbide elektronikoa da: por eso mi dirección de correo electrónico ahora es: [email protected]<mailto:[email protected]> Oscar García CISSP, CISM [Descripción: Descripción: Descripción: firma_email_Izenpe_eus] ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. De: Public [mailto:[email protected]<mailto:[email protected]>] En nombre de Ryan Sleevi via Public Enviado el: miércoles, 01 de febrero de 2017 4:50 Para: CABFPub CC: Ryan Sleevi Asunto: [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]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
