<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 12:47 PM, Ben Wilson 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"><span class="">Previously Ryan raised several concerns he had regarding Ballot 188.  As discussed below, some of those concerns were not germane to the ballot, but were suggestions for future policy changes because the Working Group endeavored that the ballot be policy-neutral.  I am not arguing that we were perfect in avoiding policy changes or that Ryan didn't spot parts that would have changed policy, but on Monday, March 6, 2017 3:22 PM, Dimitris Zacharopoulos wrote:<br>
<br>
>  The items that were identified as policy changes are listed below:<br>
><br>
>  the fact that Technically Constrained SubCAs that can respond "good" for unknown certificates,<br>
>  comes from 4.9.10. I think Mozilla and Google suggested that the ballot proposed a more relaxed language than the current BRs.<br>
><br>
<br>
</span>Response:  This was not a proposed policy change--it merely removed a double negative.  The present language says,<br>
<br>
"If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures.   Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates."<br>
<br>
Since 1 August 2013 is in the past and we've now had 3+ years for software to become compliant, should we just present a ballot that removes the exception in this last sentence--which would be a policy change?<br>
<span class=""><br>
>  the exceptions for Affiliates to the Issuing CA, also come from various places of the BRs. Google suggested that Affiliates should be<br>
>  handled as externally operated Subordinate CAs. (I am not 100% if I am describing this correctly, but we will discuss it at the WG<br>
>   and the F2F and hopefully Ryan will make it clear).<br>
><br>
<br>
</span>Response:  Requiring Affiliates to be treated as externally operated Subordinate CAs is a change in policy.  Some CA members have acquired other CAs and yet preserved their separate corporate status, and therefore, there are several places in the Baseline Requirements where Affiliates are treated as a single group.  Maybe the best approach, which I think the Policy Review Working Group will undertake, is to prepare an outline/overview of potential changes to policy that will clarify (in advance of any ballot) the various situations in which Affiliates, Externally Operated CAs, Enterprise RAs, Delegated Third Parties, and other similarly situated entities must comply with provisions of the Baseline Requirements such as:  key generation, audit, CA certificate profile, Subscriber Agreements vs. Terms of Use, Reliable Data Sources, etc.<br>
<span class=""><br>
>  For 6.1.1.1, Google suggested that we should always require the auditor to attest that any Key Pairs, for any CA Certificate,<br>
>  be accompanied with a Qualified Auditor attesting that the CA followed its Key Generation Script.<br>
><br>
<br>
</span>Response:  Currently the Baseline Requirements do not require that an auditor witness every single key pair generation.  At the risk of soliciting an antitrust violation, does the Forum want to make a dramatic change in policy and require that its WebTrust/ETSI auditor attend every key generation event?<br></blockquote><div><br></div><div>It sounds like you're attempting to shutdown discussion of policy changes? I'm not sure what makes this special, other than Relying Parties should have reasonable assurance of the key materials.</div><div><br></div><div>Dimitris' summary was not correct here, and apologies that I was unable to join the call this morning. I look forward to discussing this matter more at our F2F, which I suspect can be quite productive and help clear whatever misunderstandings may have arisen, and why the description I provided was highlighting how 188 represented an (apparently unintentional) policy change, rather than suggesting policy changes. </div></div></div></div>