[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

On Mon, Jun 29, 2020 at 7:28 AM Doug Beattie via Servercert-wg <
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200629/a99f2fc7/attachment.html>