<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ryan,<br>
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.<br>
- the core CA system that actually provisions the certs<br>
- the suport systems that are used for certificate verification
which have had the current timeframes coded in<br>
- the retail systems which are used to sell the certificates to the
customers<br>
<br>
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.<br>
<br>
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.<br>
<br>
-Rich<br>
<br>
<br>
<div class="moz-cite-prefix">On 3/30/2016 11:56 AM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvY9vJoEinSoNZWSSdqUidPx1E+o0rs4NLbNmy6gy1qhug@mail.gmail.com"
type="cite">
<p dir="ltr">Doug,</p>
<p dir="ltr">Forgive my ignorance, but could you perhaps expand on
this, and explain a bit more about the challenges your
organization would face?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Mar 30, 2016 9:41 AM, "Doug Beattie"
<<a moz-do-not-send="true"
href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" link="#0563C1" vlink="#954F72"
lang="EN-US">
<div>
<p class="MsoNormal"><span style="color:#1f497d">Jeremy,</span></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="color:#1f497d">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.</span></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="color:#1f497d">Doug</span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="m_6213666863749989854__MailEndCompose"><span
style="color:#1f497d"> </span></a></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="color:windowtext">From:</span></b><span
style="color:windowtext"> <a
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Rich Smith<br>
<b>Sent:</b> Wednesday, March 30, 2016 12:32 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:public@cabforum.org"
target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] Certificate
validity periods</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Jeremy,<br>
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;<br>
Set all max validity to 27 months; Require
re-validation for all at 27 months.<br>
<br>
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.<br>
<br>
>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.<br>
<br>
-Rich<span style="font-size:12.0pt"></span></p>
<div>
<p class="MsoNormal">On 3/30/2016 11:04 AM, Jeremy
Rowley wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi everyone, </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">So far, there seems to be two
change proposals with a couple of variations:</p>
<p class="MsoNormal"> </p>
<p><span>1)<span style="font:7.0pt "Times New
Roman"">
</span></span>Set all certificate validity periods
to no more than 27 months</p>
<p style="margin-left:1.0in">
<span>a.<span style="font:7.0pt "Times New
Roman"">
</span></span>Require re-validation of information
for OV/DV certificates at 39 months OR</p>
<p style="margin-left:1.0in">
<span>b.<span style="font:7.0pt "Times New
Roman"">
</span></span>Require re-validation of information
for all certs at 13 months</p>
<p><span>2)<span style="font:7.0pt "Times New
Roman"">
</span></span>Set all certificate validity periods
to 39 months</p>
<p style="margin-left:1.0in">
<span>a.<span style="font:7.0pt "Times New
Roman"">
</span></span>Require re-validation every 13
months</p>
<p style="margin-left:1.0in">
<span>b.<span style="font:7.0pt "Times New
Roman"">
</span></span>Require re-validation of information
for OV/DV certificates at 39 months</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Jeremy</p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times
New Roman",serif"><br>
<br>
<br>
</span></p>
<pre>_______________________________________________</pre>
<pre>Public mailing list</pre>
<pre><a moz-do-not-send="true" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a></pre>
<pre><a moz-do-not-send="true" href="https://apac01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcabforum.org%2fmailman%2flistinfo%2fpublic&data=01%7c01%7cdoug.beattie%40globalsign.com%7c5f587960e07541e1515308d358b8f658%7c8fff67c182814635b62f93106cb7a9a8%7c0&sdata=yOHEryG9SRTd7oLAmRab7nnkt%2bFY4%2fmbzXPzoGGDS0U%3d" target="_blank">https://cabforum.org/mailman/listinfo/public</a></pre>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif"> </span></p>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true" href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>