<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Dear Ryan,<br>
<br>
Apologies for sending this out a bit late. After discussing this
issue with Dean and Wayne, I realized that this thread is one of
those "spirited" discussions and hope it doesn't escalate out of
proportion. You are passionate and sensitive and when having these
discussions it is not uncommon to receive push-back from other
Members. <br>
<br>
Your response to GlobalSign was written very elegantly but the word
"GlobalSign" was used 15 times in your response to Doug which is
indicative of putting a Member "on the spot". Suggesting a CA to
change venue because you think there is no collaboration, is a step
on the edge of triggering our CoC and so was the comment about
GlobalSign's development process and where can you send pull
requests and asking about whether their documentation is online. We
all know the answer to these questions. Threatening to leave the
Forum could be seen by some Members as another form of intimidation.<br>
<br>
My overall sense after reading your entire response to Doug, was
fairly negative and I can imagine others had a similar sense as well
(other Browsers included). This behavior doesn't promote the spirit
of our Bylaws and is certainly intimidating, preventing other
Members from further contributing. Imagine how "smaller" CAs feels
(especially the non-native English speaking ones) when they see
these "elegant attacks" which cause frustration and invite more
counter-attacks, regardless of how polite and professional they seem
to be. The most common response to these strong messages is for
Members to just remain silent.<br>
<br>
I can also understand strong responses when a Members is being
provoked (several examples in the past) but this doesn't seem to be
one of those cases. I read Doug's email several times and came to
the conclusion that he stated his opinion on a number of things,
without provoking or demeaning anyone. There might also be some
misunderstanding because Doug meant to say about including
revocation reason on end-entity certificate revocation, where
Microsoft only requires it for Issuing CAs.<br>
<br>
As the Forum and SCWG Chair, with Dean's and Wayne's valuable help,
we've all tried our best to increase the level of participation and
contributions from CA Members, and we made very good progress so
far. Just look at the work that's been done at the SCWG NetSec and
Validation SC, the Bylaws and so on, and compare that to previous
years. Of course, this email thread is more focused on the SCWG but
applies to other Working Groups as well because the Forum-level
Bylaws describe the consensus-driven process.<br>
<br>
The CA/Browser Forum is a voluntary group where participants see
some value to interact with, contribute with ideas and expertise and
reach decisions based on consensus. In consensus-driven processes,
compromises are inevitable, and processes are slower than if you
were to have all that in a Root Program. However, these decisions
not only bring a wider industry consensus but also the experience
and expertise of all participants (even individuals). 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.<br>
<br>
I truly hope we can take a step back, re-evaluate the situation more
calmly, and avoid aggressive behavior that causes pain and
frustration to all of us.<br>
<br>
<br>
Sincerely,<br>
Dimitris.<br>
CA/B Forum and SCWG Chair<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 2020-06-29 6:11 μ.μ., Ryan Sleevi
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZedT8ix8rxvZ-LcrWJoGta+x3+4qTd1ieLCdAc-F+02A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 29, 2020 at 7:28
AM Doug Beattie via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true">servercert-wg@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 lang="EN-US">
<div class="gmail-m_-3968126881743549957WordSection1">
<p class="MsoNormal">To respond to your first question
below about how failed ballots get re-addressed: If a
ballot fails, more discussion can happen and the
fundamental reasons for why the ballot is needed can
be discussed. If this still fails to get consensus
within the CA Browser Forum and the Certificate
consumers/Browsers/Root programs want it, then they
can add it to their root program. Remember, the BRs
are those set of requirements that the majority of the
Browsers AND CAs agree to – this is NOT the Root
Program Baseline Requirements.<br>
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">And to answer your second question,
“what role does the CA/B Forum play in ensuring those
root programs can rely upon participating CAs to
adhere to their individual root program policies”, the
answer is easy: None. The BRs and the WebTrust audits
of those requirements have no view into or enforcement
of Root program specific requirements directly.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for this useful feedback, Doug.</div>
<div><br>
</div>
<div>Considering that the value in these documents is aligning
in the "Root Program Requirements", it sounds like you'd
prefer if browsers collaborate in existing standards fora,
such as the W3C/WICG, for future development of their Root
Programs. CAs can continue to use the CA/Browser Forum to
propose self-interested proposals, while Root Programs can
work to develop criteria that suitable for their assurance
needs elsewhere.</div>
<div><br>
</div>
<div>I cannot see any other possible option, given the stance
above. If the Baseline Requirements are, indeed, not meant
to be the Root Program Baseline Requirements, then we can
only conclude this is an unmet need of the industry that CAs
such as GlobalSign are not interested in collaborating on,
and are thus better suited for other venues.</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 lang="EN-US">
<div class="gmail-m_-3968126881743549957WordSection1">
<p class="MsoNormal">The right way to update root
policies it to have an open discussion, much the way
Mozilla does when they plan to update their Root
policy. A pull request is created against their
detailed policy with a reason for the change, it’s
discussed on a public mail list, them Mozilla makes
the decision they feel is best for their community.
The result is included in their Root policy with a
compliance date and CAs are notified of a new policy
release. While CAs may not agree with the results,
it’s an open process. The result is a unique
DOCUMENTED requirement that CAs must comply with.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is convenient as a scapegoat, but seems to not
reflect industry consensus. Of the Root Programs that
participate in the CA/Browser Forum, only one follows the
model you describe. While there are certainly benefits to
the Mozilla model, I think it would be a fairly serious
misrepresentation, especially from a CA, to suggest
otherwise. For example, Microsoft has a host of contractual
obligations which you will not find publicly documented. The
Root Programs of Microsoft, Google, and Apple, among others,
do not have discussion groups for CAs to define the product
direction or requirements, much like they many of their
other products.</div>
<div><br>
</div>
<div>As an open-source project, it's admirable that Mozilla
gives the public input into its product direction. However,
I think it would be grossly misrepresenting the status quo
to suggest that the right way to develop a product is fully
in public, much like it'd be deeply problematic to suggest
it's the wrong way. At the end of the day, vendors develop
their products as they see fit, including the development of
their Root Programs.</div>
<div><br>
</div>
<div>If it's not clear that different methods of developing
products are suitable for different needs, perhaps you can
clarify where GlobalSign does its development, and where to
submit pull requests for new features and/or to remove
support of insecure features? Is the training material
available online?</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 lang="EN-US">
<div class="gmail-m_-3968126881743549957WordSection1">
<p class="MsoNormal">Each year (or so) Mozilla, via the
CCADB, sends out checklists or related CA
Communications asking CAs to verify their compliance
with some or all of the Root policy (generally focused
on recent important changes). Mozilla uses this to
verify compliance with their policies. Combine that
with the WebTrust/ETSI audits against the CAB/F suite
of requirements, they receive assurances that CAs
comply with their root policy. </p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm afraid GlobalSign is deeply confused about what
"assurance" means here. They receive representations from
the CA, certainly. However, if you can highlight where that
involves an independent third-party assessing the veracity
of these statements, that'd be great. I'm happy to point out
a number of misrepresentations by CAs that have materially
mislead Relying Parties, but which could have been detected
with independent assurance.</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 lang="EN-US">
<div class="gmail-m_-3968126881743549957WordSection1">
<p class="MsoNormal">GlobalSign intends to vote NO on
the Browser alignment ballot for 2 major reasons:</p>
<p class="MsoNormal">1) 398 day validity is not part of
any formal, documented Browser Root policy. </p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This is, of course, false, but is part of a broader,
seeming deliberate, campaign to spread confusion, because
there's been many good-faith efforts to correct GlobalSign
here on the expectations. I think, consistent with the below
remarks, this is an attempt to both have cake and eat it
too; to pretend to be interested in a collaborative and open
model, but to resist that collaborative model when they
disagree and suggest the "right" way is through independent
action. This inherent conflict is tellingly inconsistent,
but also deeply inaccurate.</div>
<div><br>
</div>
<div>GlobalSign's committment seems to be that a Browser Root
policy is not a real Browser Root policy unless it meets all
the terms GlobalSign has set forth. If GlobalSign feels that
way, they're welcome to request removal from any Root
Program that they don't feel has a Browser Root policy that
is suitable. However, despite the claims here of No True
Scotsman that show how intellectually suspect these
arguments are, you can refer to <a
href="https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md"
moz-do-not-send="true">https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md</a> as
proof that the statement you made is not correct. </div>
<div> <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 lang="EN-US">
<div class="gmail-m_-3968126881743549957WordSection1">
<p class="MsoNormal">2) The CRL/OCSP profile changes are
not part of any Root policy, yet they are included in
the Browser Alignment ballot. Based on discussions
between Ryan and Corey, there are remaining open
questions about this as a new topic and a new change
the BRs. This ballot was supposed to be collecting
some of the common Root requirements into the BRs to
help improve the BRs and not as a backdoor to add new
requirements.</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You do realize that, as an objection, this has no merit
and directly conflicts with your preferred workmode above,
right? Is this an argument made out of ignorance, bad faith,
or is there a meaningful distinction you've failed to
highlight?</div>
<div><br>
</div>
<div>In the above reply, you've highlighted that your
preferred workmode is that of Mozilla, in which changes to
Root Programs are made through pull requests to solicit
feedback from CAs. As GlobalSign has known since Bratislava,
these requirements were already incorporated into <a
href="https://aka.ms/rootcert" moz-do-not-send="true">https://aka.ms/rootcert</a>
some time ago, and which CAs had questions about. Some of
these other requirements (SHOULD level) date back to Google
for 8 years. If GlobalSign has difficulty remembering these
requirements, that's a clear argument for including them in
the Baseline Requirements. If GlobalSign feels that the
existing requirements should be specified via a pull request
to allow CAs to comment on, that's clearly what is
happening.</div>
<div><br>
</div>
<div>It seems the difference here, to GlobalSign's view, is
that if Root Programs do try to introduce precise auditable
technical requirements, in comity and collaboration with
CAs, that CAs should be able to object to such changes
and/or dictate their timeframes. This is in stark contrast
to the "ideal work mode" described earlier in GlobalSign's
message, which would have Root Programs develop
independently, solicit feedback, but ultimately decide the
timeframe and implementation. It seems the only difference,
between making such changes in individual Root Programs,
ignoring the Forum entirely, and in collaborating in the
Forum, is that GlobalSign feels it should be able to veto
changes to Root Programs. That's not how it works in
GlobalSign's preferred "ideal", and so either the argument
is that the Forum should be disbanded (or at least, browsers
leave), or it's a disingenuous attempt by GlobalSign to
attempt to stall or block progress. Either would seem
non-ideal.<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>