[Servercert-wg] Ballot SC31 - Browser Alignment

Wed Jul 1 21:11:53 MST 2020

Dear Ryan,

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.

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.

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.

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.

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.

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.

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.

Sincerely,
Dimitris.
CA/B Forum and SCWG Chair

On 2020-06-29 6:11 μ.μ., Ryan Sleevi via Servercert-wg wrote:
>
>
> On Mon, Jun 29, 2020 at 7:28 AM Doug Beattie via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
>     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.
>
>     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.
>
>
> Thanks for this useful feedback, Doug.
>
> 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.
>
> 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.
>
>     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.
>
>
> 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.
>
> 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.
>
> 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?
>
>     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.
>
>
> 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.
>
>     GlobalSign intends to vote NO on the Browser alignment ballot for
>     2 major reasons:
>
>     1) 398 day validity is not part of any formal, documented Browser
>     Root policy.
>
>
> 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.
>
> 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 
> https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate_lifetimes.md as 
> proof that the statement you made is not correct.
>
>     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.
>
>
> 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?
>
> 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 
> https://aka.ms/rootcert 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.
>
> 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.
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200702/0511b956/attachment-0001.html>