<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 4:53 PM, Kirk Hall via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)" class="">
<style class=""><!--
/* 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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@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]-->

<div lang="EN-US" link="blue" vlink="purple" class="">
<div class="WordSection1"><p class="MsoNormal"><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; font-size: 11pt;" class="">Peter made an interesting suggestion that we keep layering on transition rules into the BRs themselves – here is his example:</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D" class=""><o:p class=""> </o:p></span></p><p style="margin-left:.5in" class="MsoPlainText">In section 7.1.4.2, replace the last sentence (which currently reads " CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in Sections 3.2.2.4 or 3.2.2.5.”) with something
 like:<o:p class=""></o:p></p><p style="margin-left:.5in" class="MsoPlainText"><o:p class=""> </o:p></p><p style="margin-left:.5in" class="MsoPlainText">“CAs MUST NOT include Domain Name or IP Address in a Subject Attribute unless it has been verified using a procedure covered in section 3.2.2.4 or 3.2.2.5 of the Baseline Requirements that were in effect at the
 time of verification,  Such verification MUST have occurred no more than 39 months prior to certificate issuance if the issuance occurs before 1 March 2018.  Such verification MUST have occurred no more than 825 days prior to certificate issuance if the issuance
 occurs on or after 1 March 2018.”<o:p class=""></o:p></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D" class=""><o:p class=""> </o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D" class="">Yes, that will resolve ONE set of transition rules from ONE ballot – but what do we do when we have another ballot that amends the same section?  And then another? 
 (Gerv gave a good example of this possibility this morning relating to the .well-known validation rule as you recall).  Do we keep adding transition rules and effective dates over and over again to the same section?  That makes no sense, and is not generally
 how rule sets are amended and codified.</span></p><div class=""><br class=""></div></div></div></div></blockquote><br class=""></div><div>Adding rules for changes is exactly what I’m proposing.  There is exactly one version of the BRs in effect at any given point.  That version needs to contain all the rules that CA must follow if they apply a signature on a certificate at that point.  We can simplify things somewhat if we want by having changes that are merged into the BRs automatically on a given date (“effective date”), but transition rules are always going to be complex.</div><div><br class=""></div><div>This is rather different from how American legislative publishing works.  For example, the Oregon Revised Statutes explain in their docs (<a href="https://www.oregonlegislature.gov/lc/ORSupdate/instructions.pdf" class="">https://www.oregonlegislature.gov/lc/ORSupdate/instructions.pdf</a>), the “master” copy of the laws is only updated periodically.  Someone wanting to get the current status of the ORS has to check through hundreds of changes in a table to determine where to look to find the current text of a statute.  </div><div><br class=""></div><div>On the other hand, many “living" technical specifications are updated every time a change is approved.  Someone wanting to get the current status simply has to get the specification and read it.  There are no tables of changes that have to be merged by hand.</div><div><br class=""></div><div>I know I prefer the latter approach, even if it means the text gets a little complex.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div></body></html>