[cabfpub] Certificate validity periods

Tue Apr 5 12:30:18 MST 2016

Trustwave supports standardizing the max cert length and  validations.  Specifically the 27/27 version and based on the "_not_after_date"

In the short term, we have all the same issues with changes to system code, update all marketing, legal, sales training, etc.  The flipside is the elimination of the confusion with sales, support teams and customers.  Trustwave tries hard to explain why EV is better and then we have to qualify: except that they don't last as long, except they have to be re-validated more often, except that they don't support wildcard (another topic I know but related in this sense).   I think security is enhanced with more frequent turnover, so that supports standardizing to 2 years rather than to 3.

I also am a believer that getting customers used to more frequent updates (manual or automated, but this will also push automation) will help push the security industry forward.  This just part of the IT world in general.  Microsoft supported XP for over 12 years, but will most likely never support an OS that long again.

Billy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
Sent: Thursday, March 31, 2016 7:24 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: public at cabforum.org
Subject: Re: [cabfpub] Certificate validity periods

On 3/30/2016 3:04 PM, Jeremy Rowley wrote:
Thanks Rich - comments are in-line

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 10:32 AM
To: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] Certificate validity periods

Jeremy,
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 months.
{JR} I'd be okay with that. In fact, I like the proposal.

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.
{JR} 1a was the opposite. It was have validation good for 39 months and just require reissuance of the cert every 2 years.
[RWS] I got that, but it still puts the limit on previous verification into the middle of a term of certificate validity so it amounts to the same problem we have now with EV, just during the 2nd order rather than the first.

>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.
{JR} No hoops. Well, no different hoops than before. It just shortens the validity period of certs, permitting faster changes in industry standards and encouraging key reuse. Fair note that I will likely eventually ask for some limits on key reuse at some point...

-Rich
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<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public<http://scanmail.trustwave.com/?c=4062&d=j5f91u4p2Uyt9dsAzV2XScOPhDRFhIOyTnXtAtVHtw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160405/7236de10/attachment.html 