On Thu, Feb 2, 2017 at 6:17 AM, García Jimeno, Oscar via Public < [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] > > > > *Oscar García* > > *CISSP, CISM* > > > > [image: 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]] *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] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
