<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"Segoe UI";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.gmail-il
        {mso-style-name:gmail-il;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1123647317;
        mso-list-template-ids:1177715252;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">Hello All,<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:7.5pt"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:7.5pt"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">With that understanding and background, there are things we can do to help each other. <o:p></o:p></span></p>
<ul type="disc">
<li class="MsoNormal" style="color:#444444;mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
<b><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif">By the Numbers: </span></b><span style="font-size:10.0pt;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. <o:p></o:p></span></li><li class="MsoNormal" style="color:#444444;mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
<b><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif">Comment Periods:</span></b><span style="font-size:10.0pt;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.<o:p></o:p></span></li><li class="MsoNormal" style="color:#444444;mso-margin-top-alt:auto;margin-bottom:12.0pt;mso-list:l0 level1 lfo1">
<b><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif">Phase-In Periods:</span></b><span style="font-size:10.0pt;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).<o:p></o:p></span></li><li class="MsoNormal" style="color:#444444;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
<b><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif">Purposeful Meetings:</span></b><span style="font-size:10.0pt;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.<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">Best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">Daniela Hood<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#444444">GoDaddy<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org>
<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 <servercert-wg@cabforum.org><br>
<b>Subject:</b> [Servercert-wg] Ballot SC31v2: Browser Alignment<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid #A6A6A6 4.5pt;padding:0in 0in 0in 14.0pt">
<p class="MsoNormal" style="background:#EBEBEB"><span style="font-size:9.0pt;font-family:"Tahoma",sans-serif">Notice:</span>
<span style="font-size:9.0pt;font-family:"Tahoma",sans-serif">This email is from an external sender.
</span><o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">This begins the discussion period for Ballot <span class="gmail-il">SC31v2</span>: Browser Alignment<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><b><span style="color:black">Purpose of Ballot:</span></b><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></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>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The changes since SC31 v1 can be viewed at <a href="https://github.com/cabforum/documents/compare/90a7dfe95d32ae8c76a4fa55c7b038d4928872c6...1bb3be897213b21d15b837befa885b0ba34bfd3d">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">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">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><o:p></o:p></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><o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>