[Servercert-wg] Ballot SC31 - Browser Alignment

Mon Jun 29 04:28:06 MST 2020

Hello Clint,

It’s unlikely you will find broad CA support for the ballot as written.  A few CAs have chimed in already with their concerns during the discussion period.  The “Browser Alignment” ballot has fallen off the rails because some of the included changes go above and beyond “browser alignment”.

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.

Clint: Ever since you announced the 398 validity requirement in Bratislava, I asked you (publicly and privately) for documented reasons for the change and especially that it be added to the published Apple root program policy as an official Apple approved requirement.  It’s now been 4 months and the Apple program [1] has not been updated, and the announcement [2] is still not clear that non-compliance is considered a misissuance.  We’re driving the entire industry change on a set of emails and meeting notes without solid justification or a referenceable policy (even an official blog) that web site administrators can view to understand this change.  This was, imo, a poor way to make such a sweeping industry change, especially since just a few months prior the ballot to limit validity periods failed by a wide margin.

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.

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.   Mozilla also has a robust misissuance tracking system to track misissuance events with their policy or the BRs.  Apple should implement/document a similar approach for their unique program requirements so reported non-compliance can be discussed in an open and transparent forum.

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.  Including statements in F2F meeting minutes, or sending emails on lists is not a sufficient documentation of a Root policy, imo.  Microsoft and Mozilla have excellent and clear Root policies and don’t rely on supplemental emails to fill out any missing pieces.  Clint, don’t take this the wrong way , but if it’s such a challenge to update the Apple Root policy formally, then are we all sure that this is the Apple corporate position? If Apple mandates and endorses such a change, then certainly it should not be that hard to have it clearly articulated in the Apple Root policy.

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.

Doug

[1] https://www.apple.com/certificateauthority/ca_program.html

[2] https://support.apple.com/en-us/HT211025

From: Clint Wilson <clintw at apple.com> 
Sent: Saturday, June 27, 2020 12:48 PM
To: Doug Beattie <doug.beattie at globalsign.com>; Chris Bailey <Chris.Bailey at entrustdatacard.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Mads Egil Henriksveen <Mads.Henriksveen at buypass.no>; Enrico Entschew <e.entschew at d-trust.net>
Subject: Re: [Servercert-wg] Ballot SC31 - Browser Alignment

Hello all,

Broadly speaking, I agree and support the messages sent by Google and Mozilla. I think SC31 should proceed as written and I hope that it can find strong support and backing from CAs.

However, based on the feedback from CAs in this thread, I do have questions that I’m hoping will help me better understand the thoughts and opinions of CAs.

I think we have come to agreement on a few things, but I want to restate them here to ensure I’m not overly assuming :)

1.	The WebPKI is not perfect statically nor dynamically, necessitating changes to how it operates at times.
2.	Changes to the WebPKI should be discussed openly, weighing input from the varied stakeholders (both directly and indirectly) affected by such changes.

3.	The CA/B Forum is a very good place for such discussions to occur and achieving consensus through the ballot process of the CA/B Forum is a valuable way to implement changes to the WebPKI.

4.	In situations where a change is identified as profoundly important by a certificate consumer, but where initial consensus in the CA/B Forum is not achieved, it may be necessary for the certificate consumer to independently enforce that change through their root program.

A few of the things said here raise additional questions, to which I don’t have a clear understanding of the position of CAs. FWIW, I do have my own position, but at this point I’m more interested in where CAs stand.

1.	If a change is requested within the CA/B Forum, but fails to pass during the ballot process, in what way(s) should that change be brought up in future CA/B Forum discussions or ballots? What, if any, are appropriate ways of revisiting changes represented in failed ballots?
2.	In situations like described in #4 above, except instead of a single certificate consumer enforcing the identified change, it’s a majority or unanimous show of support reflected in independent changes to multiple root programs, 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?

Thank you!

-Clint

On Jun 22, 2020, at 7:57 AM, Doug Beattie via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Hi Chris,

Yes, I agree.  There are some things that CAs and Browsers don’t always agree on.  CAs can document these in their CPS and the root programs can define them in their root policies.  This is one that should remain in the root policies for those programs that endorse this change.

I like all of the other changes in this ballot and don’t want to see them held up unnecessarily. 

Doug

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Chris Bailey via Servercert-wg
Sent: Monday, June 22, 2020 10:44 AM
To: servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> 
Subject: [Servercert-wg] Ballot SC31 - Browser Alignment

There has been discussion for some time in the SCWG of a “browser alignment ballot” that would import certain rules from browser root programs to the Forum’s Baseline Requirements.  Entrust Datacard is generally in favor of such a ballot, but with certain limitations.

The CA/Browser Forum was created in 2005 so that CAs and browsers could work together and agree on industry “best practices” by consensus.  We measure “best practices” consensus by our voting rules – no modification can be made to the Baseline Requirements unless it is approved by a majority of browser members and also by 2/3 of CA members.  

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.

With that introduction, we believe there are two limitations that should apply to any draft browser alignment ballot amending the BRs.

1. We should not include any browser root program rule in the ballot if it conflicts with policy of another browser root program. 

2.  In addition, an alignment ballot should not introduce controversial issues that have already been rejected in the Forum, but should only include non-controversial changes.  For this reason, we believe Ballot SC31 should not include Apple’s recent root program rule change reducing maximum certificate lifetimes from the present 825 days (as currently allowed by the BRs) to 398 days.  As you all remember, this same change to the BRs was proposed in late 2019 in Ballot SC22 and was highly controversial.  The ballot was unanimously approved by those browsers who voted, but failed by a large margin among CAs.

In addition, at the time of Ballot SC22 it did not appear that the browsers gave any consideration to the concerns of an equally important part of the internet security ecosystem which would also be necessary to establish industry consensus on best practices – the website owners themselves, who are also important customers of the browsers.  Poll results from 3,850 website owners (including many enterprise website owners) conducted by three CAs showed that 82% of website owners oppose the reduction in the maximum certificate validity period to 398 days.  Many website owners asked at the time what security problems existed with two-year certificates that were solved by moving to one-year certificates and also asked for a cost-benefit analysis from the browsers, but no clear answer was ever provided to them.  

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.

For this reason, Ballot SC31’s proposed change to a 398-day maximum validity period does not represent consensus among CAs, website owners, and browsers.  This part of Ballot SC31 is not the type of browser root program rule change that should be included in a browser root program alignment ballot.  

Entrust Datacard will not support Ballot SC31 if it includes this change to the maximum certificate validity period, and we respectfully ask the proposer and endorsers to remove that part of Ballot SC31 so we can vote for it.

--                  

Chris Bailey

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto: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/f3de2029/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5688 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200629/f3de2029/attachment-0001.p7s>