<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{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:409010328;
mso-list-template-ids:-29091518;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:588806266;
mso-list-template-ids:1537787036;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
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>Hello Clint,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It’s unlikely you will find broad CA support for the ballot as written. A few CAs have chimed in already with their concerns during the discussion period. The “Browser Alignment” ballot has fallen off the rails because some of the included changes go above and beyond “browser alignment”.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To respond to your first question below about how failed ballots get re-addressed: If a ballot fails, more discussion can happen and the fundamental reasons for why the ballot is needed can be discussed. If this still fails to get consensus within the CA Browser Forum and the Certificate consumers/Browsers/Root programs want it, then they can add it to their root program. Remember, the BRs are those set of requirements that the majority of the Browsers AND CAs agree to – this is NOT the Root Program Baseline Requirements.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And to answer your second question, “what role does the CA/B Forum play in ensuring those root programs can rely upon participating CAs to adhere to their individual root program policies”, the answer is easy: None. The BRs and the WebTrust audits of those requirements have no view into or enforcement of Root program specific requirements directly.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Clint: Ever since you announced the 398 validity requirement in Bratislava, I asked you (publicly and privately) for documented reasons for the change and especially that it be added to the published Apple root program policy as an official Apple approved requirement. It’s now been 4 months and the Apple program [1] has not been updated, and the announcement [2] is still not clear that non-compliance is considered a misissuance. We’re driving the entire industry change on a set of emails and meeting notes without solid justification or a referenceable policy (even an official blog) that web site administrators can view to understand this change. This was, imo, a poor way to make such a sweeping industry change, especially since just a few months prior the ballot to limit validity periods failed by a wide margin.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The right way to update root policies it to have an open discussion, much the way Mozilla does when they plan to update their Root policy. A pull request is created against their detailed policy with a reason for the change, it’s discussed on a public mail list, them Mozilla makes the decision they feel is best for their community. The result is included in their Root policy with a compliance date and CAs are notified of a new policy release. While CAs may not agree with the results, it’s an open process. The result is a unique DOCUMENTED requirement that CAs must comply with.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Each year (or so) Mozilla, via the CCADB, sends out checklists or related CA Communications asking CAs to verify their compliance with some or all of the Root policy (generally focused on recent important changes). Mozilla uses this to verify compliance with their policies. Combine that with the WebTrust/ETSI audits against the CAB/F suite of requirements, they receive assurances that CAs comply with their root policy. Mozilla also has a robust misissuance tracking system to track misissuance events with their policy or the BRs. Apple should implement/document a similar approach for their unique program requirements so reported non-compliance can be discussed in an open and transparent forum.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>GlobalSign intends to vote NO on the Browser alignment ballot for 2 major reasons:<o:p></o:p></p><p class=MsoNormal>1) 398 day validity is not part of any formal, documented Browser Root policy. Including statements in F2F meeting minutes, or sending emails on lists is not a sufficient documentation of a Root policy, imo. Microsoft and Mozilla have excellent and clear Root policies and don’t rely on supplemental emails to fill out any missing pieces. Clint, don’t take this the wrong way , but if it’s such a challenge to update the Apple Root policy formally, then are we all sure that this is the Apple corporate position? If Apple mandates and endorses such a change, then certainly it should not be that hard to have it clearly articulated in the Apple Root policy.<o:p></o:p></p><p class=MsoNormal>2) The CRL/OCSP profile changes are not part of any Root policy, yet they are included in the Browser Alignment ballot. Based on discussions between Ryan and Corey, there are remaining open questions about this as a new topic and a new change the BRs. This ballot was supposed to be collecting some of the common Root requirements into the BRs to help improve the BRs and not as a backdoor to add new requirements.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] <a href="https://www.apple.com/certificateauthority/ca_program.html">https://www.apple.com/certificateauthority/ca_program.html</a><o:p></o:p></p><p class=MsoNormal>[2] <a href="https://support.apple.com/en-us/HT211025">https://support.apple.com/en-us/HT211025</a><o:p></o:p></p><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> Clint Wilson <clintw@apple.com> <br><b>Sent:</b> Saturday, June 27, 2020 12:48 PM<br><b>To:</b> Doug Beattie <doug.beattie@globalsign.com>; Chris Bailey <Chris.Bailey@entrustdatacard.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org>; Mads Egil Henriksveen <Mads.Henriksveen@buypass.no>; Enrico Entschew <e.entschew@d-trust.net><br><b>Subject:</b> Re: [Servercert-wg] Ballot SC31 - Browser Alignment<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>Hello all,</span><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>Broadly speaking, I agree and support the messages sent by Google and Mozilla. I think SC31 should proceed as written and I hope that it can find strong support and backing from CAs.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>However, based on the feedback from CAs in this thread, I do have questions that I’m hoping will help me better understand the thoughts and opinions of CAs.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>I think we have come to agreement on a few things, but I want to restate them here to ensure I’m not overly assuming :)</span><o:p></o:p></p></div><ol style='margin-top:0in' start=1 type=1><li class=MsoNormal style='color:black;margin-top:12.0pt;mso-list:l0 level1 lfo1;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>The WebPKI is not perfect statically nor dynamically, necessitating changes to how it operates at times.<o:p></o:p></span></li><div><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>Changes to the WebPKI should be discussed openly, weighing input from the varied stakeholders (both directly and indirectly) affected by such changes.<o:p></o:p></span></li></div></ol><div><ol start=3 type=1><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>The CA/B Forum is a very good place for such discussions to occur and achieving consensus through the ballot process of the CA/B Forum is a valuable way to implement changes to the WebPKI.<o:p></o:p></span></li></ol></div><ol style='margin-top:0in' start=4 type=1><li class=MsoNormal style='color:black;margin-bottom:12.0pt;mso-list:l0 level1 lfo1;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>In situations where a change is identified as profoundly important by a certificate consumer, but where initial consensus in the CA/B Forum is not achieved, it may be necessary for the certificate consumer to independently enforce that change through their root program.<o:p></o:p></span></li></ol><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>A few of the things said here raise additional questions, to which I don’t have a clear understanding of the position of CAs. FWIW, I do have my own position, but at this point I’m more interested in where CAs stand.</span><o:p></o:p></p></div><ol style='margin-top:0in' start=1 type=1><li class=MsoNormal style='color:black;margin-top:12.0pt;mso-list:l1 level1 lfo2;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>If a change is requested within the CA/B Forum, but fails to pass during the ballot process, in what way(s) should that change be brought up in future CA/B Forum discussions or ballots? What, if any, are appropriate ways of revisiting changes represented in failed ballots?<o:p></o:p></span></li><li class=MsoNormal style='color:black;margin-bottom:12.0pt;mso-list:l1 level1 lfo2;vertical-align:baseline;font-variant-ligatures: normal;font-variant-east-asian: normal;font-variant-position: normal'><span style='font-family:"Arial",sans-serif'>In situations like described in #4 above, except instead of a single certificate consumer enforcing the identified change, it’s a majority or unanimous show of support reflected in independent changes to multiple root programs, what role does the CA/B Forum play in ensuring those root programs can rely upon participating CAs to adhere to their individual root program policies?<o:p></o:p></span></li></ol><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>Thank you!</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial",sans-serif;color:black'>-Clint</span><o:p></o:p></p></div><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Jun 22, 2020, at 7:57 AM, Doug Beattie via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Hi Chris,<span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal> <span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal>Yes, I agree. There are some things that CAs and Browsers don’t always agree on. CAs can document these in their CPS and the root programs can define them in their root policies. This is one that should remain in the root policies for those programs that endorse this change.<span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal> <span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal>I like all of the other changes in this ballot and don’t want to see them held up unnecessarily.<span class=apple-converted-space> </span><span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal> <span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal>Doug<span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal> <span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><div><p class=MsoNormal><b>From:</b><span class=apple-converted-space> </span>Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org">servercert-wg-bounces@cabforum.org</a>><span class=apple-converted-space> </span><b>On Behalf Of<span class=apple-converted-space> </span></b>Chris Bailey via Servercert-wg<br><b>Sent:</b><span class=apple-converted-space> </span>Monday, June 22, 2020 10:44 AM<br><b>To:</b><span class=apple-converted-space> </span><a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a><br><b>Subject:</b><span class=apple-converted-space> </span>[Servercert-wg] Ballot SC31 - Browser Alignment<span style='font-size:12.0pt'><o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>There has been discussion for some time in the SCWG of a “browser alignment ballot” that would import certain rules from browser root programs to the Forum’s Baseline Requirements. Entrust Datacard is generally in favor of such a ballot, but with certain limitations.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>The CA/Browser Forum was created in 2005 so that CAs and browsers could work together and agree on industry “best practices” by consensus. We measure “best practices” consensus by our voting rules – no modification can be made to the Baseline Requirements unless it is approved by a majority of browser members and also by 2/3 of CA members. <span class=apple-converted-space> </span><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>Over the years, some browsers have modified<span class=apple-converted-space> </span>their root program<span class=apple-converted-space> </span>rules<span class=apple-converted-space> </span>in ways that affects<span class=apple-converted-space> </span>the ecosystem. We believe<span class=apple-converted-space> </span>root program changes should work their way through the forum first<span class=apple-converted-space> </span>so there is no need for later alignment of<span class=apple-converted-space> </span>these<span class=apple-converted-space> </span>rule<span class=apple-converted-space> </span>changes<span class=apple-converted-space> </span>with the BRs.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>With that introduction, we believe there are two limitations that should apply to any draft browser alignment ballot amending the BRs.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>1. We should not include any browser root program rule in the ballot if it conflicts with policy of another browser root program.<span class=apple-converted-space> </span><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>2. In addition, an alignment ballot should not introduce controversial issues that have already been rejected in the Forum, but should only include non-controversial changes. For this reason, we believe Ballot SC31 should not include Apple’s recent root program rule change reducing maximum certificate lifetimes from the present 825 days (as currently allowed by the BRs) to 398 days. As you all remember, this same change to the BRs was proposed in late 2019 in Ballot SC22 and was highly controversial. The ballot was unanimously approved by those browsers who voted, but failed by a large margin among CAs.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>In addition, at the time of Ballot SC22 it did not appear that the browsers gave any consideration to the concerns of an equally important part of the internet security ecosystem which would also be necessary to establish industry consensus on best practices – the website owners themselves, who are also important customers of the browsers. Poll results from 3,850 website owners (including many enterprise website owners) conducted by three CAs showed that 82% of website owners oppose the reduction in the maximum certificate validity period to 398 days. Many website owners asked at the time what security problems existed with two-year certificates that were solved by moving to one-year certificates and<span class=apple-converted-space> </span>also asked<span class=apple-converted-space> </span>for a cost-benefit analysis from the browsers, but no clear answer was ever provided to them. <span class=apple-converted-space> </span><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>In our opinion, browsers should not ignore the results of an unsuccessful ballot in the Forum, add the rejected provision to their root programs anyway, and then ask the Forum members to reverse their prior votes and add the rejected provision to the Forum’s best practices documents. This would be setting a very bad precedent for collective decision-making for the future.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>For this reason, Ballot SC31’s proposed change to a 398-day maximum validity period does not represent consensus among CAs, website owners, and browsers. This part of Ballot SC31 is not the type of browser root program rule change that should be included in a browser root program alignment ballot. <span class=apple-converted-space> </span><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'>Entrust Datacard will not support Ballot SC31 if it includes this change to the maximum certificate validity period, and we respectfully ask the proposer and endorsers to remove that part of Ballot SC31 so we can vote for it.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><div><p class=MsoNormal>-- <span class=apple-converted-space> </span><span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal>Chris Bailey<span style='font-size:12.0pt'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt'> <o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></span><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>