[Servercert-wg] Ballot SC31v2: Browser Alignment

Fri Jun 26 12:46:30 MST 2020

Hello All,

CAs and browsers alike have a common goal for participating in this forum.  We want to improve the security of the internet, to provide a reliable way for people to know which sites to trust, and to make it possible for trustworthy sites to show they are secure. Browsers provide a common platform to show who to trust and CAs make it possible for people to participate through obtaining certificates. In this relationship, browsers have the best view of how certificates are being used and how security needs for end users change. CAs are closer with participants and understand how changes impact the ability to obtain and use certificates. And each CA has a different participant segment they serve, from highly technical people who can generate certificate signing requests and install on their own certificates to completely non-technical people who need a more hands-off solution. There is a delicate balance we strike by ensuring security is weighed against the ability to deliver.
With that understanding and background, there are things we can do to help each other.

  *   By the Numbers: Consider publishing end user and participant focused analysis behind proposed changes.
This will help CAs understand what browsers see from a security standpoint, and browsers to understand what CAs see from a participant standpoint.

What do other compliance focused entities do? The PCI SSC, PCAOB and ICANN publish analysis and white papers on proposed changes so everyone understands the 'why' behind the ask and can make informed suggestions to improve.
  *   Comment Periods: Consider extending comment periods to 30 days.
While there are many groups, forums and conversations, not everyone can attend every meeting. This means when changes finally hit the comment period, companies that cannot participate in every meeting may be seeing it for the first time and only have 7 days to respond. Proposing the changes earlier in the cycle and providing a longer comment period will help to ensure more people can participate.

What do other compliance focused entities do? The PCI SSC has a published guide on the topic showing comment periods are 30 days. Smaller changes have one comment period, significant changes have two.  ICANN provides six week comment periods and the PCAOB follows a similar calendar.
  *   Phase-In Periods: Consider standardizing implementation periods to at least 6 months.
Since CAs come in all sizes, having a standard calendar for implementation of changes will allow for better planning and fewer 'change-over' related incidents. Allowing at least 6 months for changes that do not impact customers, and up to 12 months for changes that impact customers (e.g. term changes) will allow for additional time to analyze the potential change, ensure communications are sent out well in advance, and integrate testing.

What do other compliance focused entities do? The PCI SSC and ICANN have published cycles.  PCI requirements become effective 90 days after publication, but phase in for companies over a 14-month period. ICANN allows 6 months for implementation and the PCAOB allows one full cycle (up to a year).
  *   Purposeful Meetings: Consider clarifying the role meetings play in the rule setting and voting process.
The CA/B forum has more frequent, larger meetings than most other industry groups. This is great to gather feedback and have productive discourse. However, if the purpose of the groups is not completely clear to all members (even those just joining), this level of participation may come with expectations regarding how much consideration is given to various opinions during rule setting and voting. Having very clear roles and objectives for these groups may help to ensure participation is productive and avoid certain pitfalls associated with expectations that come with this level of involvement. If voting is overridden by browsers, maybe use some of these meetings to go into more detail on the first point above (why, what factored into the decision, how does it help the industry).

What do other compliance focused entities do? As stated, the PCI SSC, PCAOB and ICANN don't have this level of participation.  This is at least partially because the number of members just doesn't allow for get-togethers.  CA/B is a much more exclusive community.  Having the meetings is a benefit to gain perspective on what's happening in the community and is definitely worthwhile.  As the community grows, we just need to consider what that means to governing it.
Best,

Daniela Hood
GoDaddy

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Sunday, June 21, 2020 6:58 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Ballot SC31v2: Browser Alignment

Notice: This email is from an external sender.

This begins the discussion period for Ballot SC31v2: Browser Alignment

Purpose of Ballot:

As a regular part of Root Program maintenance, and reflecting the independent nature of each Root Programs' needs and requirements, Root Programs have introduced a number of requirements above and beyond those captured in the Baseline Requirements. For Root Programs, this approach results in a lack of certainty, as the requirements are not independently audited and assessed, unless otherwise provided for. For CAs, this introduces confusion when applying to have the same CA certificate trusted by multiple Root Programs, as the effective requirements that the CA and certificates need to comply with are the union of the most-restrictive policies.

The following ballot attempts to resolve this uncertainty for Root Programs, and ambiguity for CAs, by incorporating Root Program-specific requirements that are either effective or will, in the future, be effective.

This was originally drafted in https://github.com/sleevi/cabforum-docs/pull/10 , and as a pull request is available at https://github.com/cabforum/documents/pull/195

The full description, and motivation, of each change, along with the effective dates, are available at the above pull request.

The following motion has been proposed by Ryan Sleevi of Google and endorsed by Clint Wilson of Apple and Mike Reilly of Microsoft.

The changes since SC31 v1 can be viewed at https://github.com/cabforum/documents/compare/90a7dfe95d32ae8c76a4fa55c7b038d4928872c6...1bb3be897213b21d15b837befa885b0ba34bfd3d . This corrects "Not applicable" to "No stipulation", updates the formatting/markup for Pandoc and provides additional example text to the effective date table for the Chair or Vice-Chair.

--- MOTION BEGINS ---

This ballot modifies "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" ("Baseline Requirements") as follows, based on Version 1.7.0

MODIFY the Baseline Requirements as defined in the following redline:
https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d

This ballot modifies the “Guidelines for the Issuance and Management of Extended Validation Certificates” (“EV Guidelines”) as follows, based on version 1.7.2:

MODIFY the EV Guidelines as defined in the following redline:
https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d

The Chair or Vice-Chair is permitted to update the Relevant Dates of the Baseline Requirements and the EV Guidelines to reflect these changes.

--- MOTION ENDS ---

This ballot proposes two Final Maintenance Guidelines.
The procedure for approval of this ballot is as follows:

Discussion (7+ days)
Start Time: 22-June 2020 02:00 UTC
End Time: 29-June 2020 10:00 UTC

Vote for approval (7 days)
Start Time: TBD
End Time: TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200626/25d66e2e/attachment-0001.html>