<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 10, 2017 at 11:48 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_8495932502846892726WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ryan,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ballot 194 allow for a temporary roll-back on the use of certificate data (back to 39 months) until March 1, 2018. No other changes are being included.  The “security”
 reverts back to what it was prior to the ballot and we’re not introducing any loopholes or new Renewal processing.</span></p></div></div></blockquote><div><br></div><div>Yes, the security reverts to the insecure and undesirable behaviour, which was fixed.</div><div><br></div><div>The distinction is not subtle. It would be like arguing allowing SHA-1 just "reverts" the security to the previous Forum documents. Same with allowing internal server names. The point is that it was changed to fix the security issue, and so reverting _reintroduces_ it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_8495932502846892726WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><br>
Here are a couple of challenges the CAs face: <u></u><u></u></span></p>
<p class="m_8495932502846892726MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Updating all managed service Org and Domain information that is older than 27 months is a big task.  We normally do this at some point just before expiration
 (prior to 39 months), but now we need to do an entire year’s worth of customer data in a month.  That’s a big task.</span></p></div></div></blockquote><div><br></div><div>That's interesting. Could you clarify where you believe the Baseline Requirements permits what you described?</div><div><br></div><div>Specifically, Section 4.2.1 of the Baseline Requirements only permits reuse of information pursuant with Section 3.2 ("The CA MAY use the documents and data provided in Section 3.2 to verify certificate information")</div><div><br></div><div>Section 3.2 consistently describes the documents and data obtained as pursuant to processing the Applicant's request.</div><div><br></div><div>The term "Applicant" is explicitly defined in Section 1.6.1 as "The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber."</div><div><br></div><div><br></div><div>As such, I don't believe it's valid to do so prior to expiration unless and until there has been an explicit customer request, thereby making them "An Applicant", and thereby triggering the verification process of Section 3.2. As such, what you've described does not sound consistent with the Baseline Requirements, but perhaps there's a section or qualification within them that I've missed.</div><div><br></div><div>Assuming I'm correct, and no such section exists, then the process you've described - updating managed Org and Domain information - only triggers once the Org requests a new certificate. Since that happens regardless of expiring this year or next, I fail to see how that reasonably represents a significant hurdle, although I would be happy if you could describe how it is.</div><div><br></div><div>It seems that, effectively, regardless of _when_ the deadline is set, at some point, a customer is going to request a certificate (thereby becoming an Applicant), and you're going to have to reobtain the data, so that you can use it to reverify every request (as you're required to do, since verification is different than obtaining data and documents, and you MUST reverify the Applicant using those documents for every request).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_8495932502846892726WordSection1"><p class="m_8495932502846892726MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="m_8495932502846892726MsoListParagraph"><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">For all certificates we’ve issued, we typically like to allow customers to receive replacements (reissue).  Since the BRs, unlike the EVGLs, do not
 have a concept of reissue, CAs are forced to 1) disable reissue after 27 months of cert validity for customers with 3-year certificates, 2) come up with a process by which reissues go through the initial reverification process again, or 3) keep updating all
 cert data proactively for all customers for all orders so that none of them is ever older than 27 months.</span></p></div></div></blockquote><div>It is questionable as to whether #3 is permitted under the Baseline Requirements today (see above, Section 1.6.1)</div><div><br></div><div>#1 and #2 are correct. It is important and useful that you've identified that #2 is no different than new certificate issuance. Are you suggesting it's too difficult to obtain certificates today for new customers? That it's easier, and desired, that customers face greater difficulty changing CAs?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_8495932502846892726WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I won’t comment on GlobalSign detailed product plans, but we’ll be compliant by April 22^nd one way or the other.  Our customers are hating us already,
 but that’s life.  Having the ability to re-use the data for 39 months will help  relieve some of the pain even if it comes a month after ballot 194 becomes effective.</span></p></div></div></blockquote><div><br></div><div>My lack of understanding is why customers are hating you, or more aptly, why you believe they would hate you less in a year, given that you'd be undergoing the same process today. If it's because you need time to tell them it's coming, and that is the only reason they wouldn't hate you, it'd be useful to understand how or why that changes anything. If there's something the customer can or should be doing, which so far is unclear to me, it'd be useful to understand how foreknowledge changes things.</div><div><br></div><div>I can buy that customers don't like change. But that's not an argument against change.</div><div><br></div><div>I can buy that customers don't like surprises. But that's an argument against making sure ballots are carefully reviewed if they're put forward for serious adoption. Ballot 193 unquestionably was not.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_8495932502846892726WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">When March 1 comes around, I have no issues with 27 month cert data or max validity periods, although having the concept of reissue would be significant benefit. 
 We’ll probably  ballot the concept of reissue in the BRs later this year to align with the EVGL concepts where you can reissue a certificate using the original cert data as long as the DN and expire date do not change.  It was in a draft of 193 but got removed.</span></p></div></div></blockquote><div><br></div><div>Right, I'd rather see it removed altogether. It has undesirable properties that result in such certificates being less secure. </div></div></div></div>