<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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;}
/* 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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        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;}
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;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
.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:243492130;
        mso-list-template-ids:857782134;}
@list l0:level1
        {mso-level-start-at:2;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1
        {mso-list-id:2028168233;
        mso-list-template-ids:-1658915902;}
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="color:black">Entrust Datacard votes no on Ballot SC31 v3, for two reasons.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span style="color:black">A “browser alignment” ballot to add root program provisions to the BRs should only include non-controversial issues that everyone supports by consensus.  However, Ballot SC31 also includes Apple’s recent
 program rule limiting certificates to 398 days, which was rejected by the Forum last fall.  This root program rule covers a controversial issue, and so should not be included in a simple “browser alignment” ballot.  See our prior position stated here: <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001993.html"><span style="color:#954F72">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001993.html</span></a>    <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="color:black">We also agree with the Chair’s message to Forum members on June 29, <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/002029.html"><span style="color:#954F72">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/002029.html</span></a>,
 pointing out this statement from Sections 1.1 and 1.3 of our Bylaws: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">“Members of the CA/Browser Forum have worked closely together in defining the guidelines and means of implementation for best practices as a way of providing a heightened security for Internet
 transactions and creating a more intuitive method of displaying secure sites to Internet users. ***<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black">“The historic goal of Forum activities (including development of proposed requirements and guidelines and voting on all matters) has been to seek substantial consensus among Forum Members
 before proceeding or adopting final work product, and this goal will remain for the future. Members shall not use their participation in the Forum either to promote their own products and offerings or to restrict or impede the products and offerings of other
 Members.”  <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in"><span style="color:black">The Forum’s Baseline Requirements are not intended to be just a compilation of browser root program rules, but instead are intended to be a collection of industry “best practices” that
 have been adopted by consensus in the Forum among CAs and browsers.  In our opinion, there is no consensus in the Forum that the maximum certificate validity period for certificates should be limited to one year, and so this root program rule should not be
 added to the BRs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span style="color:black">No browser root program currently includes any “revocation reason” rules for end-entity certificates.  Ballot SC31 includes new provisions on this issue, and so should not be included in this “browser
 alignment” ballot but should instead be presented and discussed in its own ballot.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="color:black">Chris Bailey <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Servercert-wg <servercert-wg-bounces@cabforum.org> on behalf of Ryan Sleevi via Servercert-wg <servercert-wg@cabforum.org><br>
<b>Reply-To: </b>Ryan Sleevi <sleevi@google.com>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Date: </b>Thursday, July 9, 2020 at 1:01 PM<br>
<b>To: </b>CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Subject: </b>[EXTERNAL][Servercert-wg] VOTING BEGINS: Ballot SC31v3: Browser Alignment<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><strong><span style="font-family:"Calibri",sans-serif;color:red">WARNING:</span></strong> This email originated outside of Entrust Datacard.<br>
<strong><span style="font-family:"Calibri",sans-serif;color:red">DO NOT CLICK</span></strong> links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">This begins the voting period for Ballot <span class="gmail-il">SC31v3</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"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The changes between SC31v1 and SC31v2 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.<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">The changes between SC31v2 and <span class="gmail-il">SC31v3</span> can be viewed at<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><a href="https://github.com/cabforum/documents/compare/1bb3be897213b21d15b837befa885b0ba34bfd3d...a9a7814da2328c3d3d54d8355eff6fe398354af8" target="_blank">https://github.com/cabforum/documents/compare/1bb3be897213b21d15b837befa885b0ba34bfd3d...a9a7814da2328c3d3d54d8355eff6fe398354af8</a> .
 This addresses an issue with certificate suspension for pre-existing, non-TLS certificates from TLS-capable subordinate CAs, and attempts to clarify the expectations around the use of CRL reason codes by requiring they be documented in the CA's CP/CPS. This
 also shuffles a requirement already present in the BRs and the RFCs, regarding Delegated Responders being conflated with TLS-capable CAs, into the "Cleanup and Clarification" ballot.<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>
<a href="https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8" target="_blank">https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8</a><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>
<a href="https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8" target="_blank">https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8</a><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.<o:p></o:p></span></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: 2-July 2020 00:00 UTC<br>
End Time: after 9-July 2020 00:00 UTC<br>
<br>
Vote for approval (7 days)<br>
Start Time: 9-July 2020 17:00 UTC<br>
End Time: 16-July 2020 17:00 UTC<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>