[Servercert-wg] Ballot SC31v2: Browser Alignment

[Ryan Sleevi]

Thanks Daniela for this thoughtful reply.

These are definitely things to think about, and although many of them have
been addressed in the past already, it might be good to formalize. First
though, a minor quibble: certificates don't establish trustworthiness or
which sites to trust. They help make sure a user is talking to the domain
of the URL they loaded, but questions about trustworthiness open up
questions of expectations and reliability of content and facts that are
really beyond the ken of technology. Certificates are simply an alternative
technology to help associate a domain name and a key, for which a variety
of tools and techniques exist.

On the *comment periods*, this doesn't seem related to SC31, since this has
been circulated in some form for over half a year. Indeed, you can see from
the very branch name that this ballot was formed from,
"2019-10-Browser_Alignment" that this effort has been happening for some
time. You can see this at
https://archive.cabforum.org/pipermail/servercert-wg/2019-October/001189.html
when
discussion was started.

If you meant specific to certificate lifetimes, then as other commenters
have highlighted, this has been discussed for half a decade now, with the
goal of moving towards 1 year clearly signaled. CA/Browser Forum Ballot 185
(2017-02), for example, made it clear the goal, as did SC22 (2019-09), but
those themselves were the result of years of discussion beforehand. I can
totally appreciate that, for new participants in the Forum, years of
discussion can be much to catch up on, but I don't think much can be said
that the signals have not been there. Any existing CA has the free ability
to follow the CA/Browser Forum, even if they're not a member, and so can
make sure their staff are adequately prepared for discussions and changes.
New CAs already go through lengthy onboarding, and of course, anyone
wanting to become a CA would benefit from following these discussions
anyways.

As such, I think the suggestion of 7 day discussion doesn't have really any
basis in the work mode of the Forum. These aren't ballots that spring from
nothing. Even the recently proposed SC32 from Ben Wilson, which is the very
first time the SCWG at large is hearing about, has at least some evidence
of lengthy discussion in the NetSec WG. Of course, it's certainly possible
that not every ballot can point to such a long and storied discussion, and
I agree, that'd be concerning as well. Ultimately, though, if the
discussion isn't long enough, CAs can vote NO. However, particularly for
ballots in which the same requirements exist regardless of the ballot, that
doesn't seem to be much of a concern.

*Phase-in periods are interesting*, but I think they're misguided both to
the general role the CA/Browser Forum plays, and to the specific provisions
of SC31. CAs operate in a important security role, and agility for
trustworthy CAs should be measured on the orders of hours, days, and weeks,
certainly not months and years. A CA is, in this role, much like any other
Internet service provider, and exposing a "security vulnerability" for a
prolonged period of time is disastrous. PCI SSC is, perhaps, the case study
in poor security decisions, as their oft-delayed rollout of security
features is known to leave vulnerabilities exposed. I think if we think
more carefully about who CA's customers really are, and the relationship to
them, as I get into below, it might be clearer why such a phase-in isn't
needed.

The questions about *whitepapers for proposed changes*, and for *more
purposeful meetings*, are definitely interesting. The comparison here to
PCI is interesting, but perhaps not in the way it was intended. While the
PCI SSC has a defined voting structure and approach, it's important to
remember that ultimately, each of the Payment Networks sets their own
security requirements for merchants on their network, and similarly direct
things via the Executive Committee. While assessors and merchants provide
valuable input, the relationships are still managed individually, and
decisions are still made unilaterally. To that end, we could certainly
consider restructuring the SCWG voting to better reflect that; for example,
for proposals from browsers, require 50% + 1 of browsers to agree on the
proposal. For proposals from CAs, require 2/3 of CAs to vote in favor, and
50% + 1 of browsers to do so. This would still support the self-governance
goals of CAs, and the interoperability goals of browsers, while also better
reflecting the product goals and needs of browsers. CAs could provide such
whitepapers to analyze the changes they propose, in order to explain them
better to browsers.

However, the comparisons to PCI SSC, PCAOB, and ICANN may end there. To
some extent, the CA/Browser Forum is better aligned with other SDOs like
the W3C WICG or the IETF. In those models, "rough consensus and running
code" is what ultimately wins the day. The IETF and W3C WICG provide
valuable venues to discuss proposals and put pen to paper to arrive on
interoperable solutions. However, as voluntary standards, whether or not a
given vendor implements an IETF RFC or a W3C proposal is dependent upon
that product's use cases and needs. Not every feature a vendor considers
goes through these SDOs, and the acceptance or rejection of a feature
doesn't really alter much of the outcome if a vendor sees a product need.
For example, consider how TLS 1.3 and QUIC has evolved in the IETF, and
despite them not yet having assigned RFCs, there was already wide,
interoperable deployment of these protocols by clients and servers. Or
consider the many features we take for granted on the Web, that still
remain in incubation or candidate drafts in the W3C, yet are widely
implemented and shipped by browsers.

Ultimately, our view of the relationship between browsers and CAs is that
CAs are suppliers of a service not to websites, but to browsers. Browsers
outsource critical functionality, such as website validation, to CAs,
rather than simply performing this in-house. The reason for this delegation
is that it promotes interoperability among browsers if multiple browsers
end up selecting the same CA or set of CAs, and that interoperability
enables greater browser competition. Throughout the history of the
CA/Browser Forum, no two browsers have completely overlapped in which CAs
they use. This is because the selection of what CAs a browser outsources to
is just like the selection of which cloud/hosting/domain provider, or which
payment processor, a website might choose to outsource to. The decision is
based on what services that vendor provides, how confident the client (the
browser or the website, in this analogy) is in the security of that
provider, and whether or not that company is the kind the client would want
to do business with.

In fact, that analogy is further useful in thinking about why some CAs may
not be trusted, or why these requirements change. If I'm a customer of a
cloud provider, and they're not able to provide features on my desired
timetable, of course I'd look to other cloud providers that have
implemented those features and take my business elsewhere. If I'm looking
for a domain provider, and I find that they're a provider that provides
bulletproof hosting to sites I don't want my business associated with, of
course I'd look for a different domain provider. If I'm looking for a
hosting provider, and they require that any changes be sent via RFC 1149,
of course I'd look for a different provider. The same can be said for CAs
that a browser chooses to contract with to provide service to the browser
vendor: the browser is the client, defining the requirements, and the CA is
the vendor competing with other CAs to meet and exceed those requirements.
If a CA takes longer to adopt a requirement than others, that doesn't mean
we should slow things down for the ecosystem, it just means that CA is less
competitive, less useful, for browsers. If a given CA doesn't meet those
requirements, the browser vendor simply won't contract with them. Consider,
for example, the many CAs that Microsoft has relationships with and that
Google has declined to do the same, because they don't meet our needs, such
as security, and security is an area we actively compete with Microsoft on.
Consider that Microsoft trusts them, in part, because Microsoft competes
with Google on stability of their systems, and that continuing to trust
those CAs, even though Google does not, provides greater stability or value
to Microsoft's customers.

The CA/Browser Forum is a useful place for us to collaborate on
requirements, like the W3C or IETF, but as discussed in
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html ,
it doesn't define the product needs, and instead simply attempts to reflect
them. If the requirements and documents no longer accurately reflect the
needs, particularly on auditable requirements, then as mentioned, it seems
the most likely response is for browsers to adopt approaches that do meet
their needs.

On Fri, Jun 26, 2020 at 3:46 PM Daniela Hood <dxhood at godaddy.com> wrote:

> 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/8d357f9e/attachment-0001.html>