<div dir="ltr"><div>Thanks Daniela for this thoughtful reply.</div><div><br></div><div>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.</div><div><br></div><div>On the <b>comment periods</b>, 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 <a href="https://archive.cabforum.org/pipermail/servercert-wg/2019-October/001189.html">https://archive.cabforum.org/pipermail/servercert-wg/2019-October/001189.html</a> when discussion was started.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>Phase-in periods are interesting</b>, 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.</div><div><br></div><div>The questions about <b>whitepapers for proposed changes</b>, and for <b>more purposeful meetings</b>, 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The CA/Browser Forum is a useful place for us to collaborate on requirements, like the W3C or IETF, but as discussed in <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html</a> , 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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 26, 2020 at 3:46 PM Daniela Hood <<a href="mailto:dxhood@godaddy.com">dxhood@godaddy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-1715557183867817561WordSection1">
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">Hello All,<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:7.5pt"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-bottom:7.5pt"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">With that understanding and background, there are things we can do to help each other. <u></u><u></u></span></p>
<ul type="disc">
<li class="MsoNormal" style="color:rgb(68,68,68);margin-bottom:12pt">
<b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif">By the Numbers: </span></b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif">Consider publishing end user and participant focused analysis behind proposed changes.<br>
This will help CAs understand what browsers see from a security standpoint, and browsers to understand what CAs see from a participant standpoint.<br>
<i><br>
What do other compliance focused entities do?</i> 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. <u></u><u></u></span></li><li class="MsoNormal" style="color:rgb(68,68,68);margin-bottom:12pt">
<b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif">Comment Periods:</span></b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif"> Consider extending comment periods to 30 days.<br>
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.<br>
<i><br>
What do other compliance focused entities do?</i> 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.<u></u><u></u></span></li><li class="MsoNormal" style="color:rgb(68,68,68);margin-bottom:12pt">
<b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif">Phase-In Periods:</span></b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif"> Consider standardizing implementation periods to at least 6 months.<br>
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.<br>
<i><br>
What do other compliance focused entities do?</i> 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).<u></u><u></u></span></li><li class="MsoNormal" style="color:rgb(68,68,68)">
<b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif">Purposeful Meetings:</span></b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif"> Consider clarifying the role meetings play in the rule setting and voting process.<br>
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).<br>
<br>
<i>What do other compliance focused entities do?</i> 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.<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">Best,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">Daniela Hood<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(68,68,68)">GoDaddy<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ryan Sleevi via Servercert-wg<br>
<b>Sent:</b> Sunday, June 21, 2020 6:58 PM<br>
<b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> [Servercert-wg] Ballot SC31v2: Browser Alignment<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:4.5pt solid rgb(166,166,166);padding:0in 0in 0in 14pt">
<p class="MsoNormal" style="background:rgb(235,235,235)"><span style="font-size:9pt;font-family:Tahoma,sans-serif">Notice:</span>
<span style="font-size:9pt;font-family:Tahoma,sans-serif">This email is from an external sender.
</span><u></u><u></u></p>
</div>
<p> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">This begins the discussion period for Ballot <span class="gmail-m_-1715557183867817561gmail-il">SC31v2</span>: Browser Alignment<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><b><span style="color:black">Purpose of Ballot:</span></b><span style="color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">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.<br>
<br>
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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="color:black">This was originally drafted in </span><a href="https://github.com/sleevi/cabforum-docs/pull/10" target="_blank">https://github.com/sleevi/cabforum-docs/pull/10</a><span style="color:black"> , and as a pull request
 is available at </span><a href="https://github.com/cabforum/documents/pull/195" target="_blank">https://github.com/cabforum/documents/pull/195</a><span style="color:black"><br>
<br>
The full description, and motivation, of each change, along with the effective dates, are available at the above pull request.<br>
<br>
The following motion has been proposed by Ryan Sleevi of Google and endorsed by Clint Wilson of Apple and Mike Reilly of Microsoft.</span>
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">The changes since SC31 v1 can be viewed at <a href="https://github.com/cabforum/documents/compare/90a7dfe95d32ae8c76a4fa55c7b038d4928872c6...1bb3be897213b21d15b837befa885b0ba34bfd3d" target="_blank">https://github.com/cabforum/documents/compare/90a7dfe95d32ae8c76a4fa55c7b038d4928872c6...1bb3be897213b21d15b837befa885b0ba34bfd3d</a> .
 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.<span style="color:black"><br>
<br>
<b>--- MOTION BEGINS ---<br>
</b><br>
This ballot modifies "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" ("Baseline Requirements") as follows, based on Version 1.7.0<br>
<br>
MODIFY the Baseline Requirements as defined in the following redline:<br>
</span><a href="https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d" target="_blank">https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d</a><span style="color:black"><br>
<br>
This ballot modifies the “Guidelines for the Issuance and Management of Extended Validation Certificates” (“EV Guidelines”) as follows, based on version 1.7.2:<br>
<br>
MODIFY the EV Guidelines as defined in the following redline:<br>
</span><a href="https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d" target="_blank">https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...1bb3be897213b21d15b837befa885b0ba34bfd3d</a><span style="color:black"><br>
<br>
The Chair or Vice-Chair is permitted to update the Relevant Dates of the Baseline Requirements and the EV Guidelines to reflect these changes.<br>
<br>
<b>--- MOTION ENDS ---<br>
</b><br>
This ballot proposes two Final Maintenance Guidelines.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The procedure for approval of this ballot is as follows:<br>
<br>
Discussion (7+ days)<br>
Start Time: 22-June 2020 02:00 UTC<br>
End Time: 29-June 2020 10:00 UTC<br>
<br>
Vote for approval (7 days)<br>
Start Time: TBD<br>
End Time: TBD</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div>