<div dir="ltr">While this addresses one part of Dean's request, it's worth noting he listed examples outside the financial services industry, such as cable and set top boxes as also being potential beneficiaries from a 'generalized exception' approach.<div><br></div><div>Which is unsurprising - once you have a generalized mechanism, a whole variety of use cases come forward; much as we've unfortunately seen with things like certificate blacklists being proposed as a 'consequence free' means to misissue, when they were designed from the start to prevent and mitigate misissuance in the first place.</div><div><br></div><div>So I think we still need specific parties to come forward before the Forum before being willing to entertain the discussions.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 4:51 PM, Tim Hollebeek <span dir="ltr"><<a href="mailto:THollebeek@trustwave.com" target="_blank">THollebeek@trustwave.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>For those who are worried about the possibility of stasis, transition is inevitable (and already occurring) because of PCI DSS.</p>
<p>For example, SHA-1 was banned in new point of sale devices about five years ago.</p>
<p><br>
</p>
<p>Also, X9.24 part 1, which should finally come out this year, bans any usage of SHA-1 whatsoever under any circumstances.  So ATM operators will soon be getting failed audits if they don't transition.</p>
<p><br>
</p>
<p>The systems, standards, audits and regulatory requirements here are about two orders of magnitude more complex than the CA/Browser world, which is part of the problem.</p>
<p><br>
</p>
<p></p>
<p>-Tim</p>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> on behalf of Richard Barnes <<a href="mailto:rbarnes@mozilla.com" target="_blank">rbarnes@mozilla.com</a>><br>
<b>Sent:</b> Monday, March 7, 2016 6:29 PM<br>
<b>To:</b> Ryan Sleevi<br>
<b>Cc:</b> Dean Coclin; CABFPub<span class=""><br>
<b>Subject:</b> Re: [cabfpub] SHA1 options for payment processors</span></font>
<div> </div>
</div>
<div>
<div dir="ltr"><br><div><div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 7, 2016 at 6:18 PM, Ryan Sleevi <span dir="ltr">
<<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Mon, Mar 7, 2016 at 7:37 AM, Dean Coclin
<span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Background</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">:</span><br>
</p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">When building security into their devices, some manufacturers included public roots from various CAs as far back as the 1990s. The CA/B Forum did not exist
 until 2006 and the first set of SSL/TLS Baseline Requirements didn’t become effective until 2012. Most of these manufacturers, who do not participate in the web PKI, were unaware that (1) these roots came under the domain of the Forum and (2) were subject
 to conditions of the Baseline Requirements. All customers of Symantec were made aware of the SHA-1 deprecation via numerous communication venues including many emails, snail mail, webinars and white papers. These customers are not the device manufacturers,
 but rather the payment processors (as an example) who use these devices in their payment clearing process.</span></p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>To be fair, these roots have always been subject to the Browser's policies on root acceptance and behaviour - so the problem was certainly anticipated that, in order to continue to participate in the browser programs' root stores, there did need to be
 some degree of compliance to browser's policies. This goes back to the very first recognition of CAs - by Mozilla, then Microsoft, then others.</div>
<div><br>
</div>
<div>I only provide this to make sure it's clear that even then, there was a distinction between different use cases. This distinction - and the need to comply to the policies of an increasingly disjoint set (Palm, Sun/Oracle, Adobe, etc) that gave rise, in
 part, to the CA/Browser Forum.</div>
<div><br>
So this problem existed, in some form, since the beginning.</div>
<span>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> These merchants include small shops, gas stations, dry cleaners, etc. and are located all over the world. While many users of SHA-1 certificates were able
 to request all they needed prior to the deadline, there were a number that either missed certain certificates, or did not understand that renewal of existing certificates was not permitted. This occurred despite repeated warnings about the SHA-1 deadline.</span></p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>So these merchants are, in effect, asking the Internet to bear the collective risk of all of their secure communications, and, at least with some of these options, asking anyone who wishes to make secure connections to subsidize their insecurity, by requiring
 relying parties develop and support mechanisms for blacklists.</div>
<div><br>
</div>
<div>I highlight this because you've presented a very emotional justification for this, and so it's important that in examining those very compelling emotional appeals, that we also maintain the broader context.</div>
<span>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I don’t have permission to use specific company names at this time, however, we have had extensive discussions with many of them and have explored options such
 as checking who else might be in device root stores (again, these are made by many manufacturers with a variety of ROMs, firmware, release dates), checking for revocation, checking for expiration, checking for poison extensions, name constrained intermediates,
 updating root stores, etc. While many use cases were solved by using “retired” roots, there exists a population that is not helped by that solution. The fact of the matter is, many *<b>only</b>* trust one particular Symantec/Verisign root.  Of course, we are
 advising these customers not to use public roots for this purpose but sadly we don’t have a time machine handy to undo what exists today.</span></p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>And this is really the crux of the matter.</div>
<div><br>
</div>
<div>I don't think it's reasonable or fair to ask the Forum to re-open a topic which was extensively discussed and debated, particularly when it would appear (at least in part) to be solely Symantec customers, without more data to share to the conversation.</div>
<div><br>
</div>
<div>If we allow ourselves to be swept up in the emotional pleas, then we sacrifice our objectivity, and our ability to reliably set standards that the Internet community moves forward with. Millions of organizations went through transitioning away from SHA-1,
 some at great expense and effort, and to suggest that we ignore all of that for the few who were unaware or ignored warnings is a difficult proposition that seems to be a smack in the face of all those who did it right.</div>
<div><br>
</div>
<div>To that end, if we're even going to entertain the topic, then it simply MUST be necessary for those parties who failed, and are thus asking the entire Internet community to accept an ever-increasing risk, to come to the conversation as full participants,
 rather than hiding behind a shield of anonymity that may, in part, be motivated by shame for failing to meet the deadlines or in being scared to reveal the technical insecurity of their sytems.</div>
<span>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Each payment processor that I’ve spoken with will need anywhere from 3-7 SHA1 certs to cover their existing base of terminals. I was hoping to find one or two
 general solutions that could help all of them.</span></p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I am explicitly opposed to this approach of trying to find a general solution. As I tried to highlight above, such a solution is to ignore the millions of site operators who did the work necessary, and it is to ignore what is a unique opportunity to understand
 why, in the midst of what was otherwise a safe and orderly transition off of SHA-1, a CA and its users are proposing that all of this be undone.</div>
<div><br>
</div>
<div>This very topic was discussed extensively - in our Mountain View F2F as well - that the inability to set a deadline, and stick to it, with respect to SHA-1, will fundamentally undermine the legitimacy of this organization and its ability to set deadlines.
 Think - if we granted this, as a general exclusion, on the principle that some Symantec customers were inconvenienced, then what about all of the customers of DigiCert, Comodo, Entrust, or any other member or non-member CA in the Forum who moved heaven and
 hell to make the transition on time. What message would they walk away with? That their CA mislead them about how serious the deadline was - and thus future deadlines can be ignored? That there's flexibility in deadlines, if the CA is persistent enough? That
 they'll be granted exceptions from deadlines, if their use case is emotionally compelling enough?</div>
<div><br>
</div>
<div>There are very real impacts to our ability to collectively make the Internet more secure, and must be taken into context not just for the direct risks of continuing SHA-1 issuance, but also to the overall ecosystem.</div>
<div><br>
</div>
<div>To that end, I would reiterate - to have a productive discussion of this, if there is to be a productive discussion at all, these customers need to be able to come forward and publicly discuss their issues, so that we can make an informed, data-driven
 decision on a case-by-case basis as to how best to mitigate the risks - to the ecosystem, to policies, to these customers - rather than trying to generalize it with a papered-over solution that allows an untold number of SHA-1 certificates to be issued, particularly
 if it favors a single CA.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I am in complete agreement on this latter point.  Any action that is taken here needs to be limited, fully transparent, and ultimately directed toward transition rather than stasis.<br>
<br>
</div>
<div>--Richard<br>
</div>
<div><br>
 </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="http://scanmail.trustwave.com/?c=4062&d=0o7e1pXIv0x_EERHxnLgy1Fb_HsdGi1MMVF8Y7CAJQ&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div></div></div>
</div>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
 contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</div>

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