[Servercert-wg] Ballot SC31 - Browser Alignment

Mon Jun 29 11:53:45 MST 2020

In the context of this, and all other (crucial) conversations, i think it would help if there was consensus around the definition of “'industry' consensus”. Who are we referring to?

When we know what is meant by “industry” we can better decide whether consensus has been reached. 

As far as I’m aware, and I might be wrong, this forum is mostly certificate providers and certificate consumers. If one half doesn’t agree to something, consensus has not been reached - irrespective of who agrees/disagree.

Separately, I obviously agree that browser vendors have the right to mandate whatever they like of CAs and other third-party suppliers. Can we separate these instances from times when feedback is going to be actioned? Feedback for the sake of it results in mistrust and frustration. 

Warmest regards,
Paul

> On Jun 29, 2020, at 8:11 AM, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> 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 <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 <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/20200629/679041ef/attachment-0001.html>