<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 20, 2022 at 3:33 PM Doug Beattie via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7485935950370298754WordSection1"><p class="MsoNormal"><span style="color:windowtext">Do we really want to permit an older version of the BRs to be considered valid and auditable when there are newer versions?   That goes against “CAs must comply with the latest version of the BRs”.  I’d much prefer a single stream of updates where CAs are audited against the latest one only as we have done historically.</span></p></div></div></blockquote><div><br></div><div>+1 to this. This was very much the concern I was trying to capture in our previous discussions, about making sure there's a smooth transition. This is also why the current draft shows how we can accomplish this for future-dated requirements, so that things can be seamless.<br></div><div><br></div><div>There had been discussion, but never any concrete proposal, for a "mix and match" solution, but no one could show how that worked.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7485935950370298754WordSection1"><p class="MsoNormal"><span style="color:windowtext">Could we consider placing the new section 7 in a new appendix, Appendix C, and keeping the current section 7?   We could state that this becomes effective on <date> and CAs are encouraged to start complying with this sooner.  CAs may be compliant with section 7 and/or Appendix C during this time.  O the effective date we have a new ballot that moves Appendix C into Section 7.</span></p></div></div></blockquote><div><br></div><div>I'm not sure I understand this. Is this proposing two different profiles within the BRs?</div><div><br></div><div>Is the suggestion here that the profiles work would need a forward dated requirement? Are there specifics you could share about that? Every time we've discussed this in the past, it's been difficult to get specifics about the elements of concern.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7485935950370298754WordSection1"><p class="MsoNormal"><span style="color:windowtext">Another alternative is to highlight each and every “material” change with specific effective dates - ugly</span></p></div></div></blockquote><div><br></div><div>The conversation for nearly a year has been asking whether folks believe there are 'material' changes that have impact. Where there are changes, they are either annotated with effective dates (the same as we do for the BRs, today) or they are seen as "low risk" and can be effective immediately (e.g. offline ceremonies).</div><div><br></div><div>I can understand in the abstract, but we've already punted so much to V2 precisely to defer this question, but it sounds like you're concerned that there's still a significant amount?</div><div><span style="color:windowtext"> </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7485935950370298754WordSection1"><p class="MsoNormal">If this is worth discussing (again), then could we add this to the agenda for this week’s call?</p></div></div></blockquote><div><br></div><div>I do think this would be hugely valuable and a productive use of time.</div><div><br></div><div>I think, as with the past discussions (and if it's useful, happy to dig up the references), that folks highlight anything that they believe is a problematic change and explain why. We've had some discussions about <i>existing</i> requirements (e.g. from the intersection of the BRs and RFC 5280, or requirements from RFC 5280) being unclear. I think that if we can, similarly, set aside the debate about SHOULD/MAY and focus on MUST/MUST NOT, it could be really productive. </div></div></div>