[cabfpub] Certificate validity periods

Wed Mar 30 13:11:26 MST 2016

I'm not so sure a lack of desire to change code is a great reason to avoid
something that increases security. However, I do like the 27/27 proposal as
a great step forward. Are the browsers opposed to 27/27? The only thing in
EV really impacted by the longer validity times is domain validation thanks
to the reuse section of the EV Guidelines.  

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rich Smith
Sent: Wednesday, March 30, 2016 11:44 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Certificate validity periods

Ryan,
I won't speak for Doug, but what I see is that any change at this point will
require every CA to make a lot of code changes to a lot of systems.
 - the core CA system that actually provisions the certs
 - the suport systems that are used for certificate verification which have
had the current timeframes coded in
 - the retail systems which are used to sell the certificates to the
customers

Not to mention communications to partners and major stakeholders of the
upcoming change, and their inevitable surprise and unhappiness when the
changes actually go into effect because they failed to pay attention.
Another bad customer experience, even though in this example, one of their
own making.

IMO, Jeremy's proposal of option 1a gives CAs zero incentive to support all
of the above.  I'm aware of and agree with the security incentive a shorter
max validity offers, but as you are well aware, end users/customers don't
LIKE security, unless it comes at ZERO cost to them in time, money,
inconvenience, etc.  If that wasn't true, all the browsers would be doing
revocation checks on every certificate encountered.  I'm not certain my
proposal of 27/27 max validity/revalidation is enough incentive to get
support for it, but at least it does offer some incentive.

-Rich

On 3/30/2016 11:56 AM, Ryan Sleevi wrote:

Doug,

Forgive my ignorance, but could you perhaps expand on this, and explain a
bit more about the challenges your organization would face?

>From the browser perspective, reducing validity times and revalidation times
is a big win for security and the ability to change. The ability to make
changes one year sooner is a HUGE win. I can understand and appreciate that
you may value that increased security differently, but where I would like to
understand better is what impact this would have from the CAs side, and why
this would be undesirable.

To that end, would you be willing to explain in more detail what would have
to happen on the CA's side to bring this in? Can you "sell me" on the
difficulty, by perhaps providing more concrete explanations of the changes
necessary, and not just the abstract categories? My ideal response to such
an email from you would ideally be "Wow, that's so much, I didn't realize" -
so can you fill in that blank and help me have that reaction?

Ultimately, the goal is to better understand the concrete concerns and
objections, as well as have a better understanding of the overall
challenges, so that if and when we revisit this topic, we can make sure to
fully consider the impact and perhaps explore solutions.

The challenge that I have with your current response is that it doesn't
share enough detail to really see if there is any room for changes or
compromise, nor does it really help form a picture other than "This is hard
because I say it's hard," and I suspect there's much more subtlety and
nuance than the broad stroke I just painted it as.

On Mar 30, 2016 9:41 AM, "Doug Beattie" <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> > wrote:

Jeremy,

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.

Doug

From: public-bounces at cabforum.org <mailto: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

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.

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.

-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
<https://apac01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcabforum
.org%2fmailman%2flistinfo%2fpublic&data=01%7c01%7cdoug.beattie%40globalsign.
com%7c5f587960e07541e1515308d358b8f658%7c8fff67c182814635b62f93106cb7a9a8%7c
0&sdata=yOHEryG9SRTd7oLAmRab7nnkt%2bFY4%2fmbzXPzoGGDS0U%3d> 

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160330/39a1231f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160330/39a1231f/attachment-0001.bin 