[cabfpub] Lifecycle of EV certs
bruce.morton at entrust.com
Fri Mar 20 06:36:17 MST 2015
We have a similar position to lifecycle of EV as we do for wildcard. The shorter lifecycle means that EV will be updated sooner to avoid risks of old technology.
However, shortening the life of OV and DV may take away an option for users to use a long lifecycle and decrease maintenance time.
Frankly, I would like consistency and have the same timeframe for all certificates. But again, I do think that we need EV certificates to be better than OV and DV. The shorter validity time and non-wildcards are statements to that fact.
As such, we would be against lengthening the validity time for EV. Would also prefer to not shorten the validity time of OV/DV.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, March 19, 2015 6:33 PM
To: public at cabforum.org
Subject: [cabfpub] Lifecycle of EV certs
Per the call today and discussion during the face-to-face, I'd like to start a public discussion on doing one of two things. Either:
1) Extending EV certificates to a 39 month validity period or
2) Reducing the validity period of all certificates to 24 months.
Personally, I like the idea of a maximum lifecycle of 24 months. The lower validity period ensures CAB Forum and industry changes take less time to implement (fewer MD5/SHA1 situations), and we encourage more frequent rekeying and validation.
On the other hand, we are only about to lower the maximum to 39 months. Considering the opposition to the 39 month limit, I expect getting a consensus will be very difficult. Also, server operators with a medium amount of certs might be significantly hurt since they would be doing cert changes more regularly and, unlike many large organizations, might not have automated processes.
Therefore extending EV to 39 months might be more reasonable. Extending EV to 39 months will help promote EV adoption and put EV on equal footing with OV/DV. Of course, this would extend the validation time by a year. One way to deal with this extra time is adopt the Mozilla approach and require revalidation every X months (where X is mostly likely 13). If the validation fails, the cert would be revoked. I'm not a big fan of this revalidation approach since there's no affirmative act that signals the revalidation occurred (such as issuance) and there's a strong incentive to simply let the cert stand. Plus, it'll require some reworking for many CAs to ensure validation is tied to a timeframe (13 months) instead of an event (issuance). Although revalidation will be covered in the audits, we might just recognize that the validation will only happen every 39 months and go with that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public