[cabfpub] Certificate validity periods

Jeremy Rowley jeremy.rowley at digicert.com
Wed Mar 30 20:06:48 UTC 2016

What about the proposal Rich stated? 27 month certs with 27 month
re-validation requirements? 


The value is more rapid key change over and shorter periods where we have
security risks associated with weak keys, hash algorithms, etc. Pretty sure
the financial industry's inability to move to SHA2 certs illustrates why
this is a good idea.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Doug Beattie
Sent: Wednesday, March 30, 2016 10:41 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Certificate validity periods




I'm also against making any changes.  I don't see the value of this change
exceeding all the work on communications, system updates and operational
procedure changes needed to make this happen.




From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>
[mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
Sent: Wednesday, March 30, 2016 12:32 PM
To: public at cabforum.org <mailto:public at cabforum.org> 
Subject: Re: [cabfpub] Certificate validity periods


I'm not sure Comodo would support any change at this point, but if we were
to change I'd like to propose, let's call it 1c;
Set all max validity to 27 months; Require re-validation for all at 27

I'm against your proposal of 1a for the same reasons I don't like 27/13 for
EV  It puts us in position of having to redo validation of a replacement
request by the customer.  In this case, the customer would get the DV or OV
for 27 months, be able to replace at will, renew the cert for an additional
27 months, but be subject to revalidatiion half way through the 2nd when
trying to get a replacement/re-issuance.  This is bad enough with EV
already, and I'm very much against extending it to OV/DV.  If we can't find
a reasonable path to match up the re-validation requirement with max
validity then I'm against making any changes.

>From the customer perspective, they expect to have to jump through hoops at
the point of placing a new order.  We don't generally get push back on that.
What they don't expect, and what it is very difficult to make them
understand is having to jump through the hoops again during the validity
period of the same order.  The customer doesn't understand these
requirements and it causes a bad customer experience, for which they blame
the CA.


On 3/30/2016 11:04 AM, Jeremy Rowley wrote:

Hi everyone, 


I'd like to resurface the certificate validity period discussion and see if
there is a way to move this forward.  I'm still keen on seeing a
standardized maximum validity period for all certificate types, regardless
of whether the certificate is DV, OV, or EV. I believe the last time this
was discussed, we reached an impasse where the browsers favored a shorter
validity period for OV/DV and the CAs were generally supportive of a
longer-lived EV certificate (39 months). The argument for a shorter validity
period were 1) encourages key replacement, 2) ensures validation occurs more
frequently, 3) deters damage caused by key loss or a change in domain
control, and 4) permits more rapid changes in industry standards and
accelerates the phase-out of insecure practices. The argument for longer
validity periods: 1) customers prefer longer certificate validity periods,
and 2) the difficulty in frequent re-validation of information. 


So far, there seems to be two change proposals with a couple of variations:


1)      Set all certificate validity periods to no more than 27 months

a.       Require re-validation of information for OV/DV certificates at 39
months OR

b.       Require re-validation of information for all certs at 13 months

2)      Set all certificate validity periods to 39 months

a.       Require re-validation every 13 months

b.       Require re-validation of information for OV/DV certificates at 39


What are the objections to 1a? With all the automated installers abounding,
1a seems to capture the simplicity and customer convenience of 39 months
with the advantages of shorter-lived certs. Who would oppose/endorse a
ballot that does one of these? 



Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160330/2f982c98/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160330/2f982c98/attachment-0001.p7s>

More information about the Public mailing list