<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 27, 2016 at 5:32 AM, Dean Coclin via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8988791497451434611WordSection1"><p class="MsoNormal"><span style="font-size:9pt;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 *.<a href="http://payliquid.com/" target="_blank">payliquid.com</a> 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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;font-family:arial,sans-serif;color:black">---------------------------</span><span style="font-size:12pt;font-family:"times new roman",serif;color:black"><u></u><u></u></span></p><p class="MsoNormal"><u><span style="font-size:9pt;font-family:arial,sans-serif;color:black">Background and options explored (from Barclays)</span></u><span style="font-size:9pt;font-family:arial,sans-serif;color:black">:</span><u><span style="color:black"><u></u><u></u></span></u></p><p class="MsoNormal"><span style="font-size:9pt;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><span style="color:black"><u></u><u></u></span></p><p class="MsoNormal"><u><span style="font-size:9pt;font-family:arial,sans-serif;color:black">Merchant and consumer impact</span></u><span style="font-size:9pt;font-family:arial,sans-serif;color:black">:</span><u><span style="color:black"><u></u><u></u></span></u></p><p class="MsoNormal"><span style="font-size:9pt;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><span style="color:black"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;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.”<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;font-family:arial,sans-serif;color:black">-----------------------------<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;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: <a href="https://crt.sh/?sha256=ADF3CF69897EF0F02549D27266D324D61AB5746AB6FAB0D89C122616B68B7441" target="_blank">https://crt.sh/?sha256=<wbr>ADF3CF69897EF0F02549D27266D324<wbr>D61AB5746AB6FAB0D89C122616B68B<wbr>7441</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;font-family:arial,sans-serif;color:black"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:9pt;font-family:arial,sans-serif;color:black">Dean Coclin<br>Symantec</span></p></div></div></blockquote><div><br></div><div>Dean,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div>  a) If yes, could you explain more why you opted not to go down this route?</div><div>  b) If no, could you explain more why it wasn't considered?</div><div><br></div><div>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.</div><div><br></div><div>2) This situation appears, at least, to be customer-inflicted related to pinning. </div><div>  a) What guidance does Symantec provide regarding pinning - either via HPKP or otherwise?</div><div>  b) Was the shutdown of this CA communicated with the customer in advance?</div><div>  c) Does Symantec provide public resources, timelines, or committments regarding the operation of its intermediate CAs?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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?</div></div></div></div>