[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 3:21 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> 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.
>>
>
> 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
> https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001993.html
>
>
>
> 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.
>
> 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.
>

Everyone doesn't accept that, which is exactly why this thread is so
spirited.

Consider these unambiguous statements about the primality of the Forum, in
the linked message:

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.

> 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.

Followed by this statement
> 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.

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
1) The Forum should be consulted first
2) If the Forum rejects something, it should not be added to Root Programs

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.

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.

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
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001996.html ,
show a substantial expansion of what and how things are audited.

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
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html .
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200702/cd672b5d/attachment.html>