[cabfpub] Certificate validity periods

Rich Smith richard.smith at comodo.com
Wed Mar 30 16:32:03 UTC 2016

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 months
> 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?
> Jeremy
> _______________________________________________
> 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/20160330/eec27b62/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4035 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160330/eec27b62/attachment-0001.p7s>

More information about the Public mailing list