[cabfpub] Notice of Certificate Issuance

Dean Coclin Dean_Coclin at symantec.com
Wed Nov 30 20:45:39 MST 2016


Ryan,

Please see the response to your questions below:

 

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?

  a) If yes, could you explain more why you opted not to go down this route?

  b) If no, could you explain more why it wasn't considered?

 

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.

 

2) This situation appears, at least, to be customer-inflicted related to pinning. 

  a) What guidance does Symantec provide regarding pinning - either via HPKP or otherwise?

  b) Was the shutdown of this CA communicated with the customer in advance?

  c) Does Symantec provide public resources, timelines, or commitments regarding the operation of its intermediate CAs?

 

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.

 

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 - https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ). 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?

 

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 certain merchant 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.  In the course of supporting these limited exceptions we are strongly encouraging the transition to alternative non-browser trusted hierarchies for these customers.

 

 

 

Thanks,
Dean

 

 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, November 29, 2016 7:31 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Dean Coclin <Dean_Coclin at symantec.com>
Subject: Re: [cabfpub] Notice of Certificate Issuance

 

 

 

On Sun, Nov 27, 2016 at 5:32 AM, Dean Coclin via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

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 *. <http://payliquid.com/> payliquid.com 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.

---------------------------

Background and options explored (from Barclays):

“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.  

Merchant and consumer impact:

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. 

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.”

-----------------------------

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:  <https://crt.sh/?sha256=ADF3CF69897EF0F02549D27266D324D61AB5746AB6FAB0D89C122616B68B7441> https://crt.sh/?sha256=ADF3CF69897EF0F02549D27266D324D61AB5746AB6FAB0D89C122616B68B7441

 

Dean Coclin
Symantec

 

Dean,

 

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.

 

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.

 

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?

  a) If yes, could you explain more why you opted not to go down this route?

  b) If no, could you explain more why it wasn't considered?

 

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.

 

2) This situation appears, at least, to be customer-inflicted related to pinning. 

  a) What guidance does Symantec provide regarding pinning - either via HPKP or otherwise?

  b) Was the shutdown of this CA communicated with the customer in advance?

  c) Does Symantec provide public resources, timelines, or committments regarding the operation of its intermediate CAs?

 

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.

 

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 - https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ). 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?

 

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161201/03946d51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20161201/03946d51/attachment-0001.bin>


More information about the Public mailing list