<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:"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:12.0pt;
font-family:"Times New Roman",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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Ryan,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Please see the response to your questions below:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'>1) Symantec indicated this required a system that used a sequential serial number. However, Symantec has also demonstrated its ability and willingness to 'manually' issue certificates as part of its issuance pipeline, such as for SHA-1. Was that an option Symantec explored here - that is, generating a random number using an approved method, and 'manually' constructing a TBSCertificate with that, and then signing it?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> a) If yes, could you explain more why you opted not to go down this route?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> b) If no, could you explain more why it wasn't considered?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#44546A'>In prior SHA-1 exceptional issuances, we did incorporate a random number from an HSM. However, those were done on our primary system. This certificate needed to be issued from a legacy system (no longer used for certificate issuance) on which we had never attempted to override the use of sequential serial numbers. We ruled this option out given the time sensitivity of the need, the additional QA required to ensure no negative effects, and the fact that it was presented to us on Thanksgiving day, appealing for an immediate turn-around due to the criticalities mentioned.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif'>2)</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'>This situation appears, at least, to be customer-inflicted related to pinning. </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> a) What guidance does Symantec provide regarding pinning - either via HPKP or otherwise?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> b) Was the shutdown of this CA communicated with the customer in advance?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> c) Does Symantec provide public resources, timelines, or commitments regarding the operation of its intermediate CAs?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#44546A'>For the past several years we have made a point to communicate to both customers and partners that they should avoid hard coding or otherwise constraining the CA’s supported by their applications given the increasing frequency of changes. In this case it is also explicitly called out in our CPS.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif'>3)</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:black'>Symantec is 'notable' for its continued attempts to view misissuance as exceptional. This is true regarding SHA-1 sunsetting (and the subsequent exception process developed), it's true in this case, and it's true in past instances as well (such as Pitney Bowes - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966350">https://bugzilla.mozilla.org/show_bug.cgi?id=966350</a> ). At this point, it is questionable as to whether these misissuances are exceptional anymore, or whether they're part of a service that Symantec offers their larger customers, perhaps at a premium - "BR violations available for a fee". Could you share more details about what criteria Symantec uses to determine whether or not it is acceptable for Symantec to knowingly violate the Baseline Requirements?</span><o:p></o:p></p><p class=MsoNormal><span style='color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#44546A'>As the longest-running CA with the largest base of the largest customers, we, more than other CA’s, have customers with unique use cases. In each case where we have had exceptions, we weigh the security risks, the operational realities, and the customer impact to inform our decisions. In this case, we assessed the impact to thousands of SMB merchants during the busiest shopping season of the year to be a greater negative impact than the instance of issuing a 60 day certificate compliant in all respects other than the serial number. We recognize that the common theme across the exceptions is that</span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:red'> </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#44546A'>certain merchant</span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#44546A'>customers have been using the same certificate hierarchies in apps and devices as those that are trusted by browsers. We have been actively counseling these customers to choose our Private CA options for these applications instead. </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><span style='font-size:10.5pt;font-family:"Calibri",sans-serif;color:#44546A'>In the course of supporting these limited exceptions we are strongly encouraging the transition to alternative non-browser trusted hierarchies for these customers.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks,<br>Dean<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Tuesday, November 29, 2016 7:31 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Cc:</b> Dean Coclin <Dean_Coclin@symantec.com><br><b>Subject:</b> Re: [cabfpub] Notice of Certificate Issuance<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Sun, Nov 27, 2016 at 5:32 AM, Dean Coclin via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>On November 24, 2016 (Thanksgiving Day), an emergency situation arose whereby mobile application users of Barclays Bank would no longer be able to conduct transactions due to the pinning of an obsolete intermediate certificate in the application. The bank, through its application provider Axsy, urgently contacted Symantec to request a new certificate for *.</span><a href="http://payliquid.com/" target="_blank"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>payliquid.com</span></a><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'> chained to the older intermediate CA. Symantec determined while this was possible, it could only be accomplished by issuing a certificate with a sequential serial number, in violation of CA/B Forum Baseline Requirements Section 7.1. This certificate issuance was issued from a legacy system that has since been replaced in part because it only supported certificate issuance using sequential serial numbers.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>---------------------------</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><u><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Background and options explored (from Barclays)</span></u><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>“The recent change to the intermediate certificate negatively impacted Barclay’s SSL pinning solution. As a result, connection to our mobile application will fail for all users imminently. The only other option to fix this issue is underway and requires us to modify our existing iOS and Android mobile application code. This will take several weeks, including security testing, app store submission, approval and rollout. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><u><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Merchant and consumer impact</span></u><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Without this exception, the impact on Barclays would be severe and fall mainly on its small and medium enterprise customers who utilise its payment acceptance devices that link to the application that is referred to above. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Several thousand SME customers mainly operating in the UK market would not be able to transact in a key trading period from 8.30am 25/11/16 on ‘Black Friday’ and into the festive trading period they rely on for their businesses to survive. It would impact hundreds of thousands of consumer payment transactions, until the application is updated and then released. It would also result in major reputational damage to Barclays and its business customers impacted.”</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>-----------------------------</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Due to the criticality of this issue and the major impact to consumers and businesses on a significant holiday shopping period , Symantec issued the replacement certificate on the evening of November 24th. This certificate has a relatively short validity period and had been published in CT logs as shown here: </span><a href="https://crt.sh/?sha256=ADF3CF69897EF0F02549D27266D324D61AB5746AB6FAB0D89C122616B68B7441" target="_blank"><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>https://crt.sh/?sha256=ADF3CF69897EF0F02549D27266D324D61AB5746AB6FAB0D89C122616B68B7441</span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>Dean Coclin<br>Symantec</span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Dean,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>First, thanks for providing the public incident report. I think for CAs that find themselves in such situations, this is the sort of minimal thing necessary to avoid further sanction. That's not to say it's a free pass, but transparency helps far more than hiding.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have a few questions related to this - both related to the specific instance, but also the general question of what can we, as the Forum, do better.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1) Symantec indicated this required a system that used a sequential serial number. However, Symantec has also demonstrated its ability and willingness to 'manually' issue certificates as part of its issuance pipeline, such as for SHA-1. Was that an option Symantec explored here - that is, generating a random number using an approved method, and 'manually' constructing a TBSCertificate with that, and then signing it?<o:p></o:p></p></div><div><p class=MsoNormal> a) If yes, could you explain more why you opted not to go down this route?<o:p></o:p></p></div><div><p class=MsoNormal> b) If no, could you explain more why it wasn't considered?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The goal with this question is to better understand if there are opportunities here, as the industry, to provide guidance and 'expectations' for system designs. By understanding why this could or could not have been done with a manual ceremony, at least from Symantec's point of view, we can hopefully hear from other CAs about how they might try to handle such a situation, and through that shared knowledge, figure out if there's process to improve ease or reduce risk in such options.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2) This situation appears, at least, to be customer-inflicted related to pinning. <o:p></o:p></p></div><div><p class=MsoNormal> a) What guidance does Symantec provide regarding pinning - either via HPKP or otherwise?<o:p></o:p></p></div><div><p class=MsoNormal> b) Was the shutdown of this CA communicated with the customer in advance?<o:p></o:p></p></div><div><p class=MsoNormal> c) Does Symantec provide public resources, timelines, or committments regarding the operation of its intermediate CAs?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The goal with this is to understand what steps Symantec has already taken to mitigate self-inflicted damage. If there were good faith efforts already on Symantec's part regarding this, and the customer ignored it, that suggests one possible issue. However, if Symantec didn't publish any of this information, or have a communications channel for it, then it seems likely that both Symantec and other CAs will encounter this in the future.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>3) Symantec is 'notable' for its continued attempts to view misissuance as exceptional. This is true regarding SHA-1 sunsetting (and the subsequent exception process developed), it's true in this case, and it's true in past instances as well (such as Pitney Bowes - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966350">https://bugzilla.mozilla.org/show_bug.cgi?id=966350</a> ). At this point, it is questionable as to whether these misissuances are exceptional anymore, or whether they're part of a service that Symantec offers their larger customers, perhaps at a premium - "BR violations available for a fee". Could you share more details about what criteria Symantec uses to determine whether or not it is acceptable for Symantec to knowingly violate the Baseline Requirements?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The goal with this question is to understand why Symantes continues to run in to these situations - and, notably, it seems primarily only Symantec. By understanding what factors are unique to Symantec here, and why they seem to be the only one regularly and intentionally doing it (as opposed to the myriad BR violations stemming from accidents, oversight, or ignorance that we see across the CA ecosystem), we can try to better mitigate the risk and damage. For example, is this something that should be incorporated into Subscriber Agreements / Terms of Service - the expectation that if there's a self-inflicted wound (failing to update terminals, improper pinning), the CA bears no responsibility and will adhere to the BRs? Alternatively, as explored with SHA-1 and payment terminals/cable boxes, should there be encouragements from the CA/Browser Forum to find 'alternate' PKIs? Alternatively, how can browsers better communicate the risk to CAs that find themselves in such ecosystem-harming situations, so that CAs can fully appreciate the direct and indirect consequences of continued intentional misissuance?<o:p></o:p></p></div></div></div></div></div></body></html>