<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=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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:34815780;
mso-list-type:hybrid;
mso-list-template-ids:1302263028 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:41.4pt;
text-indent:-30.6pt;
mso-ansi-font-weight:normal;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:77.4pt;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:113.4pt;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:149.4pt;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:185.4pt;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:221.4pt;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:257.4pt;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:293.4pt;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:329.4pt;
text-indent:-9.0pt;}
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="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attendees: <span lang=EN style='color:black'>Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Curt Spann (Apple), Dean Coclin (Symantec), </span><span lang=EN>Dimitris </span>Zacharopoulos (Harica), <span lang=EN style='color:black'>Doug Beattie (Globalsign), Erwaan Abalea (Docusign), </span>Geoff Keating (Apple)<span lang=EN style='color:black'>, Jeremy Rowley (Digicert), Jody Cloutier (Microsoft), Josh Aas (Let’s Encrypt), Josh Purvis (Cisco), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Moudrick Dadashov (SSC), Neil Dunbar (Trustcor), Patrick Tonnier (OATI), Peter Bowen (Amazon), Peter Miscovic (Disig), Philip Hallam Baker (Comodo), </span><span style='color:black'>Robin Alden (Comodo), </span><span lang=EN style='color:black'>Ryan Sleevi (Google), Tim Hollebeek (Trustwave), Tyler Myers (GoDaddy), </span>Virginia Fournier (Apple), Wayne Thayer (GoDaddy). Special guests: Amy Zirkle (Electronic Transactions Association), Charles Bretz (FS-ISAC), Eric Mill (Independent).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Roll Call completed.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Antitrust Statement was read by Dean<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Agenda Reviewed – no changes<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Minutes of F2F of May 26, 2016 – Minutes were approved and will be posted to the public list. Minutes of June 9, 2016 – approved and will be posted.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Ballot Status: Ballot 170 failed. Ben commented that he felt those that didn’t understand the subject matter should abstain rather than voting no. Dean said there was a bigger issue at hand with regard to the mission of the Policy Working Group, which was chartered by ballot 128 (<a href="https://cabforum.org/2014/07/09/ballot-128-cp-review-working-group/">https://cabforum.org/2014/07/09/ballot-128-cp-review-working-group/</a>). Kirk commented that folks were questioning whether we need to fill in all provisions and suggested that the group send out pre-ballots to give people more time to comment. Jeremy thought this was superfluous as those that are interested should be part of the working group. Kirk thought that for complex issues, it doesn’t hurt to have others look at it. Peter said the forum approves everything and not everyone wants to be involved in the minutiae discussions. Jeremy wondered if we should have the discussions at the forum level instead of the working group. Patrick asked if the comment period was the time when questions should be answered. Ben said he answered every question during the comment period. Patrick said that the process worked as designed. Ben and Jeremy said we should start the discussion on the main list. Dean read the original charter (see link above). Ryan said the issue was not the charter or scope. He said Gerv had raised a concern about the priority of the changes. Google said the ballot itself was not a good ballot; some language was not auditable and was too broad which created a set of subjective interpretations which in the end, were meaningless. Jeremy again said we should surface the issue to the main mailing list. Ryan disagreed, saying that would be too much for the main mailing list, would likely be ignored, and the details should be discussed in the working group. He didn’t think doing this would change the participation. Kirk said the Validation working group used the “pre-ballot” model successfully. Ben said we will take this back to the working group for further review. Dimitris asked if we would no longer have SHOULDS in the document as they are not auditable. Ben said he would like to hear from others on this. Kirk thought that many requirements were already in WebTrust for CAs and should be transferred from there. Dean called time on this subject and said it would be taken up in the working group.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;text-indent:0in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>6.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>SHA-1 Issue: Dean recapped the invited guests for this segment were Amy, Charles and Eric. Each introduced themselves and their organization: Charles and Amy representing two different payment processor trade associations. Ryan said they had circulated their proposal, discussed comments but have made no changes to the proposal. Hence the proposal as written, stands. Geoff from Apple said they had not formulated an opinion on the procedure. Dean stated they have heard from Microsoft, Google and Mozilla but input from Apple is critical to CAs that are contemplating issuing under this procedure.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Amy Zirkle from ETA stated they are a non-profit trade association based in Washington, DC, representing the payments technology industry. Their 500+ members include CABF members, Amazon, Apple, Google and Microsoft. They have become more involved as members have expressed concern about the SHA-1 issue. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Charles Bretz from Financial Services Information Sharing Analysis Center (FS-ISAC), stated they are a nonprofit whose goal is to protect the financial services industry from cyber threats and enhance business continuity. They have 6800 members worldwide. Charles concentrates on payment risk activities and represents a council of payment processors who represent 90%+ of North American merchant processing volume and over 50% in Europe as well as significant volume in Asia-Pacific and South America. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Eric Mill was representing himself but stated his interest in policy work as a US Government employee. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Charles commented on the current proposal on behalf of the processors. The main objection was to the disclosure requirement which they felt was not necessary and would lead to something similar to the Worldpay situation. Charles proposed an alternative whereby if a processor wanted to request a SHA-1 certificate under the current proposal, that they be allowed to submit the application to FS-ISAC and FS-ISAC would redact the name of the processor and insert “Payment Processor #X” into that field. This would then be submitted to the CA and then the forum. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Amy said their members also reviewed the document. They take the security issues very seriously and are working diligently to insure all merchants have upgraded terminals. They want to insure all are aware of the significant and critical impact to the ecosystem of not allowing continued use of SHA-1 for a longer time than what the forum has prescribed. But there are too many terminals in the field and there isn’t enough time to do it in the window as it currently stands. Amy agreed with Charles’ proposal and didn’t believe branding an organization in a public shaming (i.e. Scarlet letter) would further the cause of fixing this issue.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><br>Ryan clarified that this is an ecosystem issue. He understood that they payment industry is significantly behind on security issues which is unfortunate. This issue really gets to the heart of trust online. Medical data, personally sensitive data, emails, financial transaction are all protected by the same technology. SHA-1 is no longer safe to continue issuing. Google has had the academic community review their proposal and they said it was too big a risk but Google decided to go forward anyway as they understand there is a balance to the ecosystem. However, the payment services industry is asking to put the whole Internet at risk. Hence it is necessary to understand why this is and what we can do to protect it and this needs to happen in the public. The issues extend beyond FS-ISAC, CABF and ETA. They need to understand what went wrong, how we can do better. The risk is borne by everyone. The suggestion that this was meant to be punitive is not correct. FS-ISAC’s suggestion wouldn’t work to help understand how the problems were created. The need for public disclosure and have a communication channel is paramount. The transparency has a functional purpose. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><br>Eric stated he participated in the Worldpay thread and can understand why some might see this as a “public shaming” but the intention here is to make fewer experiences like this, not more. In that case, it was unexpected and out of context, which is different now. It also was focused on one browser where this procedure is intended to be more universal. He thought it was unlikely that processors would see a repetition of the Worldpay (“Scarlet letter”) experience. Eric also stated that making one thing secret tends to spread to other things and that it spreads “like a cancer” within an organization. Second order redactions would come next. Overall Eric feels this proposal mitigates any public shaming while benefiting all involved. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Philip gave a historical perspective stating that the web PKI was originally a browser initiative and that the roots were embedded in the OS, not the browsers. But that changed later. However now the web PKI is being used for things beyond browser application and no one ever told the other users that this was a bad thing to do. We need to think about what is the best for Internet and payment infrastructure as a whole. Academics will tell you that things are really bad and that caution is usually the best approach however, the cost and security benefit must be weighed when asking the question. The context must be part of the question (impact to consumers/merchants). Is it possible to create a certificate that doesn’t conflict with browser uses? (i.e. rejected by browsers). Browser vendors can shut off SHA-1 anytime they choose. The question then becomes is the non-shutoff of these certs in browsers more important than the continued use cases of the payment terminals that can’t be updated?<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Peter said that he had heard not only from payment processors but others that have come forward and that perhaps we should just lump together the lessons learned from the different industries. Dean clarified that this specific request was for payment processors but there had been rumblings about cable boxes and medical devices.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Geoff said in Apple’s case they are an operating system (not just a browser) and they have one root store and one TLS implementation. When they turn SHA-1 off (just like they did for RC4), it goes off in the browser, email, API calls from apps, everything. Exceptions mean they can’t turn it off and hence the ecosystem issues become a problem. Payment devices could be impacted if Apple were to make this change. It’s important to understand the consequences. This is part of the reason they don’t have a policy on exceptions yet. They very much want to know what went wrong. It’s been 10 years since NIST put out a SHA-1 deprecation policy. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Charles addressed Ryan’s comment on what went wrong. He suggested he be given a list of CABF questions on how we got here and FS-ISAC would create a questionnaire for their members. They would then aggregate those answers and publish them for all to see. This would help show how the industry got here but not one particular company. This would cover a large share of the payment processors. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Ryan said this doesn’t address their need or use case. It is vitally important to understand who the subscriber is for further comment and to prevent abuse. Part of this addresses a potential to mount attacks. At a minimum, the entire certificate must be disclosed – this is non-negotiable. From this info, the “who” can be ascertained. The idea for redaction is not something they are willing to consider. The need for public discussion is a critical part for Google to grant an exception.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><br>Eric said that once you redact some info, this will lead to other redactions. The example he gave is someone’s legal counsel looking at the application and trying to insure that in no way they can be identified—this will lead to further redactions which will not even permit the cert name to be disclosed; something that is just unacceptable and dilutes the quality of the answers. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Charles asked if the processor submitted the proposal and if questions came back, would the answers then go back to the forum in a transparent way? Ryan said yes, the proposal asks a set of initial questions and includes a 10 day consultation period. This gives time for cryptanalysis and weighs risk to the ecosystem as a whole. Google has been opposed to SHA-1 issuance and this represents a balance to assist processors. It also gives CAs a “pass” to issue these IF they follow the procedure.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Amy clarified that some members have done the SHA-1 to SHA-2 migration successfully and do not have an issue. She asked if there is a way to convene discussions where there is some level of security/confidentiality to take into account security concerns and risks with a subset of the group. There are instances where ETA has meetings with subset of members to discuss security issues in private. Would such a discussion be possible given sensitive business issues? Eric said the CABF list isn’t the same as the Mozilla list (i.e. only members and Interested Parties can post). Ryan clarified that the Forum can’t grant this exception and this is up to the browser part of the CAB forum. What Amy is really asking then is if each individual browser members would entertain such meetings. For Google, this is not an option. Ryan also said that security concerns were separate from the transparency concerns and hoped to understand what those security concerns were. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>Dean thanked everyone for participating and apologized for not getting to other scheduled topics. He said he would put Philip’s topic of Quantum Computing as the first item on the next call. Philip said he needed to discuss this before the Berlin IETF meeting in July. Peter suggested Philip post this on the public list to generate a discussion. <o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'>The next call is on July 7<sup>th</sup>.<o:p></o:p></p><p class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto'><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>