<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \,serif";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ryan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Rich summed it up pretty well without getting into the gory details – making certificates is a bit like making sausages, the details are better left out.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">From my perspective there is little benefit – some customers like longer validity period certificates so they don’t need to change them as often (not everyone
is fully automated), and we don’t mind selling them when asked. It’s a lot of work with sales, marketing, legal, compliance, vetting and development teams to make changes like this and I don’t see the much of a gain in security from going from a max of 39
months to 27 months. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Perhaps I’m not understanding the implications behind your statement “…reducing validity times and revalidation times is a big win for security and the ability
to change”. I think we’re actually contemplating increasing EV validation times. Regardless, if there are things we need to change, let’s start moving out on making the changes sooner rather than later and leave the current validity period options unchanged.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- Start making SCTs mandatory in DV (or in all certs with validity period of over 27 months)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- Allow short lived certs to omit OCSP/CDP because nobody checks them anyway<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- Encourage the move to ECC-384 or RSA-4096, or whatever security changes you see coming<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><br>
Doug<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></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="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Rich Smith<br>
<b>Sent:</b> Wednesday, March 30, 2016 1:44 PM<br>
<b>To:</b> public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Certificate validity periods<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 3/30/2016 11:56 AM, Ryan Sleevi wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p>Doug,<o:p></o:p></p>
<p>Forgive my ignorance, but could you perhaps expand on this, and explain a bit more about the challenges your organization would face?<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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?<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<p>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.<o:p></o:p></p>
<div>
<p class="MsoNormal">On Mar 30, 2016 9:41 AM, "Doug Beattie" <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">Jeremy,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">Doug</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_6213666863749989854__MailEndCompose"><span style="color:#1F497D"> </span></a><o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext">
<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a 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 href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] Certificate validity periods</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;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<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 3/30/2016 11:04 AM, Jeremy Rowley wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi everyone,
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So far, there seems to be two change proposals with a couple of variations:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p>1)<span style="font-size:7.0pt"> </span>Set all certificate validity periods to no more than 27 months<o:p></o:p></p>
<p style="margin-left:1.0in">a.<span style="font-size:7.0pt"> </span>Require re-validation of information for OV/DV certificates at 39 months OR<o:p></o:p></p>
<p style="margin-left:1.0in">b.<span style="font-size:7.0pt"> </span>Require re-validation of information for all certs at 13 months<o:p></o:p></p>
<p>2)<span style="font-size:7.0pt"> </span>Set all certificate validity periods to 39 months<o:p></o:p></p>
<p style="margin-left:1.0in">a.<span style="font-size:7.0pt"> </span>Require re-validation every 13 months<o:p></o:p></p>
<p style="margin-left:1.0in">b.<span style="font-size:7.0pt"> </span>Require re-validation of information for OV/DV certificates at 39 months<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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? <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Jeremy<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Times New Roman ,serif",serif"><br>
<br>
</span><o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a 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><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Times New Roman ,serif",serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://apac01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcabforum.org%2fmailman%2flistinfo%2fpublic&data=01%7c01%7cdoug.beattie%40globalsign.com%7cba7ce886fc6045b91c1e08d358c30573%7c8fff67c182814635b62f93106cb7a9a8%7c0&sdata=4LbANF2qs1RN%2brGGK6HvVNb9VTFGrNLKtpy77MpNNMw%3d" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://apac01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcabforum.org%2fmailman%2flistinfo%2fpublic&data=01%7c01%7cdoug.beattie%40globalsign.com%7cba7ce886fc6045b91c1e08d358c30573%7c8fff67c182814635b62f93106cb7a9a8%7c0&sdata=4LbANF2qs1RN%2brGGK6HvVNb9VTFGrNLKtpy77MpNNMw%3d">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>