<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 27, 2017 at 4:00 PM, Jeremy Rowley via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</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_-746991336449772298WordSection1"><p class="MsoNormal">Ben let me know that there were questions about Ballot 190. The ballot was withdrawn and hasn’t gone to vote yet because of Section 2:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-family:"Times New Roman",serif">“This provisions of Ballot Section 1 will apply only to the validation of domain names occurring after this Ballot 190’s effective date.  Validation of domain names that occurs before this Ballot’s effective date and the resulting validation data may continue to be used for the periods specified in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in compliance with the BR Section 3.2.2.4 validation methods in effect at the time of each validation.”<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I couldn’t tell if the objection to this section was the section not being part of the Baseline Requirements or a general concern that CAs may have issued certificates using the “any other method” that will remain valid for potentially four years (for a re-issue that relies on a previous validation). <u></u><u></u></p><p class="MsoNormal">                              <wbr>                              <wbr>                             <u></u><u></u></p><p class="MsoNormal">Assuming the first issue is the primary concern, the following language was proposed in the validation working group for inclusion in the BRs:<u></u><u></u></p><p class="MsoNormal"><span style="color:black">“Note: </span>The changes to BR 3.2.2.4.1 through 3.2.2.4.10 will apply only to the validation of domain names occurring on or after [insert Ballot 190’s effective date if it passes and completes its Review Period].  Validation of domain names that occurs before [insert Ballot 190’s effective date if it passes and completes its Review Period] and the resulting validation data may continue to be used for the periods specified in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in compliance with the BR Section 3.2.2.4 validation methods in effect at the time of each validation.”<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Rather than go through multiple iterations and have this ballot potentially fail, can we do a quick straw poll? <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="1" type="1"><li class="m_-746991336449772298MsoListParagraph" style="margin-left:0in">Does the proposed language resolve the previous concern with Ballot 190?<u></u><u></u></li><li class="m_-746991336449772298MsoListParagraph" style="margin-left:0in">If not, should section 2 be dropped entirely. <u></u><u></u></li><li class="m_-746991336449772298MsoListParagraph" style="margin-left:0in">If section 2 remains, would you vote against the ballot?<u></u><u></u></li><li class="m_-746991336449772298MsoListParagraph" style="margin-left:0in">If section 2 was dropped, would you vote for the ballot? <u></u><u></u></li><li class="m_-746991336449772298MsoListParagraph" style="margin-left:0in">Is there other language you’d prefer to see included instead?</li></ol></div></div></blockquote><div>Hi Jeremy,</div><div> <br></div></div>I'm not sure I fully understand your questions 1/2. It sounds (from Kirk's reply) that this would go into 3.2.2.4 - is that correct?</div><div class="gmail_extra"><br></div><div class="gmail_extra">And your questions 3-5 relate to adding that to 3.2.2.4.</div><div class="gmail_extra"><br></div><div class="gmail_extra">While I think the introduction of the validation methods is good, I think we've been quite clear now over several Forum meetings that we desire to see all new certificates issued using the methods of 3.2.2.4. I think we've made great progress in the Forum, over the past two years, ensuring that everyone's use cases are met, but I must say I'm shocked and saddened to see some members so opposed to the security improvements they bring, since this would prevent their reliable deployment by at least 5 years.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I'm also appreciative that some Browser Members may not share those concerns about security, or may not be seeing the same level of misissuance we are from CAs improperly validating, and thus be comfortable with these lower limits.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the general language proposal is a bit awkward - I would rather see it pegged to an explicit minimum version (for example, BRs 1.4.1) and explicitly forbid using a previous "any other method" validation. Is that problematic?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Assuming that some members will be so opposed to transparency and measurable security that they would oppose requiring basic validation using the non-"any other method" methods, can we consider requiring that any new certificates issued expire no later than (effective date + 6 months)? This would permit CAs who have acted in good faith to adopt the methods of 3.2.2.4, as Google clearly indicated, to be unaffected, while those who have used the many delays in discussion to postpone security improvements have time to transition (simply by revalidating their certificates).</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think if we're still unable to agree on a timeline such as that - requiring revalidation consistent with the current-3.2.2.4 for anything that was validated under a previous-3.2.2.4 that is no longer permitted - my only other suggestion would be to require an explicit expression within the certificate that it complies with the current version of 3.2.2.4 at the time of issuance. This would help give Relying Parties the necessary assurances that the CA is committed to security.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Given that the discussions here have gone for so long, I hope that any of these small tweaks that move us to a more consistent standard, and provide a strong attestation on the CAs part about their commitment to security, benefit everyone, and minimize any disruption to CA workflows due to the improved security.</div></div>