<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 3:21 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>This is the Forum's added value and how this Forum
works, without preventing any Root Program setting its own
rules and policies independently, outside the Forum. These
are the rules we all accepted.</div>
</blockquote>
<div><br>
</div>
<div>This is, frankly, a deeply troubling statement. I cannot
help but suggest it borderlines dishonest, in that the very
proposal that started this thread, and which was being
discussed, was exactly such a prohibition, as you can
clearly read in <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001993.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001993.html</a> </div>
</div>
</div>
</blockquote>
<br>
I can't connect this with the prohibition you claim. Entrust made a
statement about their desire not to see requirements included in
SC31 unless they are agreed in all Browser Root Programs, and then
made a special reference to the 398 days validity period which did
not pass in SC22. They even made a reference to Certificate
Subscribers which was missing from most of these discussions.
Overall, I didn't find a statement that discourages or prevents Root
Programs from setting policy independently of the SCWG.<br>
<br>
It is quite possible I overlooked something, so apologies in
advance. Bottom line is that Browsers remain independent to make
independent policy decisions via their Root Programs, this is
reality and I think everyone excepts that. If these policies need to
go into the BRs or other Guidelines, then they need to get consensus
from both Voting Member categories.<br></div></blockquote><div><br></div><div>Everyone doesn't accept that, which is exactly why this thread is so spirited.</div><div><br></div><div>Consider these unambiguous statements about the primality of the Forum, in the linked message:</div><div><br></div><div>First, there is this statement that everything should begin in the Forum. This might seem like a "start work" in the Forum, but the second half of that makes it clear that the express goal is that there is "no need for later alignment" - i.e. because they are perfectly aligned.</div><div><br></div><div>> <span style="color:rgb(0,0,0);white-space:pre-wrap">Over the years, some browsers have modified their root program rules in ways that affects the ecosystem. We believe root program changes should work their way through the forum first so there is no need for later alignment of these rule changes with the BRs.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Followed by this statement</span></div><div>> <span style="color:rgb(0,0,0);white-space:pre-wrap">In our opinion, browsers should not ignore the results of an unsuccessful ballot in the Forum, **add the rejected provision to their root programs anyway**, and then ask the Forum members to reverse their prior votes and add the rejected provision to the Forum’s best practices documents. This would be setting a very bad precedent for collective decision-making for the future.</span></div><div><br></div><div>You might be wishing to interpret that as aligned with the seeming spirit of Doug's message: that anything that the Forum votes against should not (ever) be introduced again into the Forum. But that's not the (emphasis added) statement. The objection, which is not new in this thread and has been raised before, is very much that</div><div>1) The Forum should be consulted first</div><div>2) If the Forum rejects something, it should not be added to Root Programs</div><div><br></div><div>You can't reach another conclusion with those statements, because if you take the view that there is no need for later alignment, you have to take the view that it is because they remain aligned. And if Root Programs both introduce in the Forum first, and cannot reintroduce what Browsers have added to their Root Programs, then they fundamentally can't add to their Root Programs, because that would cause them to be unaligned with the Forum. This is the essence of the "collective decision-making" appeal being made, which fundamentally cannot exist if Browsers continue to make independent changes to the BRs.</div><div><br></div><div>This isn't ambiguous, because it's also not a new statement from the right honorable representatives of Entrust, especially around this topic. Discussions about "ignoring" the Forum highlight the primacy of the Forum as the deliberative body, but it's not that, and it's never been that.</div><div><br></div><div>Again, the only reason that Google accepts, say, a WebTrust for SSL BRs audit or an ETSI x19 4xx audit, is because we believe that such audits, for the time being, provide sufficient assurance that our security needs are met by the CA. It is not because we're members of the Forum and that is what the BRs say to accept, but because such audits are seen as a way of making it easier for us to evaluate a CA against our requirements. As noted, The ETSI ESI audits are considerably failing in that deliverable, and as shared at our recent F2F, have gotten to the point where we are contemplating no longer accepting such audits because the level of assurance they provide is so limited. The WebTrust audits, while useful, have seen considerable room for improvement, and which the WebTrust TF recently shared in <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001996.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001996.html</a> , show a substantial expansion of what and how things are audited.</div><div><br></div><div>I don't at all dismiss the need for consensus, as currently defined by our Charter, in order for something to be adopted. But that doesn't change the reality that the failure to adopt a requirement we view as necessary and do require only serves to undermine the value provided, as just described. The value lost is so signfiicant, precisely because of how fundamental this debate is, that it may eliminate any of the perceived value from the BRs, compared to the alternatives outlined in <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html</a> . And if the BRs lose their value, so does the Forum, who for us the only value is two-fold: as a shepherd for the BRs, which we presently value, and as a mailing list to solicit feedback. And we can run a mailing list ourselves, if needed.</div></div></div>