[cabfpub] Notice of Certificate Issuance

[Ryan Sleevi]

On Sun, Nov 27, 2016 at 5:32 AM, Dean Coclin via Public <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 *.
> 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=ADF3CF69897EF0F02549D27266D324
> D61AB5746AB6FAB0D89C122616B68B7441
>
>
>
> 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://lists.cabforum.org/pipermail/public/attachments/20161129/7bed0f95/attachment-0002.html>