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

[Richard Barnes]

On Thu, Feb 2, 2017 at 6:17 AM, García Jimeno, Oscar via Public <
public at cabforum.org> 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:  o-garcia at izenpe.eus
>
>
>
> *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:public-bounces at cabforum.org] *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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170202/7a52b5c6/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9540 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170202/7a52b5c6/attachment-0003.jpg>