[cabfpub] Final Minutes of CA/B Forum meeting of June 23rd

Dean Coclin Dean_Coclin at symantec.com
Thu Jul 7 11:44:48 MST 2016


 

Attendees: Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton
(Entrust), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris
Zacharopoulos (Harica), Doug Beattie (Globalsign), Erwaan Abalea (Docusign),
Geoff Keating (Apple), Jeremy Rowley (Digicert), Jody Cloutier (Microsoft),
Josh Aas (Let's Encrypt), Josh Purvis (Cisco), Kirk Hall (Entrust), Li-Chun
Chen (Chunghwa Telecom), Moudrick Dadashov (SSC), Neil Dunbar (Trustcor),
Patrick Tonnier (OATI), Peter Bowen (Amazon), Peter Miscovic (Disig), Philip
Hallam Baker (Comodo), Robin Alden (Comodo), Ryan Sleevi (Google), Tim
Hollebeek (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple),
Wayne Thayer (GoDaddy). Special guests: Amy Zirkle (Electronic Transactions
Association), Charles Bretz (FS-ISAC), Eric Mill (Independent).

 

 

1.                   Roll Call completed.

 

2.                   Antitrust Statement was read by Dean

 

3.                   Agenda Reviewed - no changes

 

4.                   Minutes of F2F of May 26, 2016 - Minutes were approved
and will be posted to the public list. Minutes of June 9, 2016 - approved
and will be posted.

 

5.                   Ballot Status: Ballot 170 failed. Ben commented that he
felt those that didn't understand the subject matter should abstain rather
than voting no. Dean said there was a bigger issue at hand with regard to
the mission of the Policy Working Group, which was chartered by ballot 128
(https://cabforum.org/2014/07/09/ballot-128-cp-review-working-group/). Kirk
commented that folks were questioning whether we need to fill in all
provisions and suggested that the group send out pre-ballots to give people
more time to comment. Jeremy thought this was superfluous as those that are
interested should be part of the working group. Kirk thought that for
complex issues, it doesn't hurt to have others look at it. Peter said the
forum approves everything and not everyone wants to be involved in the
minutiae discussions. Jeremy wondered if we should have the discussions at
the forum level instead of the working group. Patrick asked if the comment
period was the time when questions should be answered. Ben said he answered
every question during the comment period. Patrick said that the process
worked as designed. Ben and Jeremy said we should start the discussion on
the main list. Dean read the original charter (see link above). Ryan said
the issue was not the charter or scope. He said Gerv had raised a concern
about the priority of the changes. Google said the ballot itself was not a
good ballot; some language was not auditable and was too broad which created
a set of subjective interpretations which in the end, were meaningless.
Jeremy again said we should surface the issue to the main mailing list. Ryan
disagreed, saying that would be too much for the main mailing list, would
likely be ignored, and the details should be discussed in the working group.
He didn't think doing this would change the participation. Kirk said the
Validation working group used the "pre-ballot" model successfully. Ben said
we will take this back to the working group for further review. Dimitris
asked if we would no longer have SHOULDS in the document as they are not
auditable. Ben said he would like to hear from others on this. Kirk thought
that many requirements were already in WebTrust for CAs and should be
transferred from there. Dean called time on this subject and said it would
be taken up in the working group.

 

6.                   SHA-1 Issue: Dean recapped the invited guests for this
segment were Amy, Charles and Eric. Each introduced themselves and their
organization: Charles and Amy representing two different payment processor
trade associations. Ryan said they had circulated their proposal, discussed
comments but have made no changes to the proposal. Hence the proposal as
written, stands. Geoff from Apple said they had not formulated an opinion on
the procedure. Dean stated they have heard from Microsoft, Google and
Mozilla but input from Apple is critical to CAs that are contemplating
issuing under this procedure.

 

Amy Zirkle from ETA stated they are a non-profit trade association based in
Washington, DC, representing the payments technology industry. Their 500+
members include CABF members, Amazon, Apple, Google and Microsoft. They have
become more involved as members have expressed concern about the SHA-1
issue. 

 

Charles Bretz from Financial Services Information Sharing Analysis Center
(FS-ISAC), stated they are a nonprofit whose goal is to protect the
financial services industry from cyber threats and enhance business
continuity. They have 6800 members worldwide. Charles concentrates on
payment risk activities and represents a council of payment processors who
represent 90%+ of North American merchant processing volume and over 50% in
Europe as well as significant volume in Asia-Pacific and South America. 

 

Eric Mill was representing himself but stated his interest in policy work as
a US Government employee.  

 

Charles commented on the current proposal on behalf of the processors. The
main objection was to the disclosure requirement which they felt was not
necessary and would lead to something similar to the Worldpay situation.
Charles proposed an alternative whereby if a processor wanted to request a
SHA-1 certificate under the current proposal, that they be allowed to submit
the application to FS-ISAC and FS-ISAC would redact the name of the
processor and insert "Payment Processor #X" into that field. This would then
be submitted to the CA and then the forum. 

 

Amy said their members also reviewed the document. They take the security
issues very seriously and are working diligently to insure all merchants
have upgraded terminals. They want to insure all are aware of the
significant and critical impact to the ecosystem of not allowing continued
use of SHA-1 for a longer time than what the forum has prescribed. But there
are too many terminals in the field and there isn't enough time to do it in
the window as it currently stands. Amy agreed with Charles' proposal and
didn't believe branding an organization in a public shaming (i.e. Scarlet
letter) would further the cause of fixing this issue.


Ryan clarified that this is an ecosystem issue. He understood that they
payment industry is significantly behind on security issues which is
unfortunate. This issue really gets to the heart of trust online. Medical
data, personally sensitive data, emails, financial transaction are all
protected by the same technology. SHA-1 is no longer safe to continue
issuing. Google has had the academic community review their proposal and
they said it was too big a risk but Google decided to go forward anyway as
they understand there is a balance to the ecosystem. However, the payment
services industry is asking to put the whole Internet at risk. Hence it is
necessary to understand why this is and what we can do to protect it and
this needs to happen in the public. The issues extend beyond FS-ISAC, CABF
and ETA. They need to understand what went wrong, how we can do better. The
risk is borne by everyone. The suggestion that this was meant to be punitive
is not correct. FS-ISAC's suggestion wouldn't work to help understand how
the problems were created. The need for public disclosure and have a
communication channel is paramount. The transparency has a functional
purpose. 


Eric stated he participated in the Worldpay thread and can understand why
some might see this as a "public shaming" but the intention here is to make
fewer experiences like this, not more. In that case, it was unexpected and
out of context, which is different now. It also was focused on one browser
where this procedure is intended to be more universal. He thought it was
unlikely that processors would see a repetition of the Worldpay ("Scarlet
letter") experience. Eric also stated that making one thing secret tends to
spread to other things and that it spreads "like a cancer" within an
organization. Second order redactions would come next. Overall Eric feels
this proposal mitigates any public shaming while benefiting all involved. 

 

Philip gave a historical perspective stating that the web PKI was originally
a browser initiative and that the roots were embedded in the OS, not the
browsers. But that changed later. However now the web PKI is being used for
things beyond browser application and no one ever told the other users that
this was a bad thing to do. We need to think about what is the best for
Internet and payment infrastructure as a whole. Academics will tell you that
things are really bad and that caution is usually the best approach however,
the cost and security benefit must be weighed when asking the question. The
context must be part of the question (impact to consumers/merchants). Is it
possible to create a certificate that doesn't conflict with browser uses?
(i.e. rejected by browsers). Browser vendors can shut off SHA-1 anytime they
choose. The question then becomes is the non-shutoff of these certs in
browsers more important than the continued use cases of the payment
terminals that can't be updated?

 

Peter said that he had heard not only from payment processors but others
that have come forward and that perhaps we should just lump together the
lessons learned from the different industries. Dean clarified that this
specific request was for payment processors but there had been rumblings
about cable boxes and medical devices.

 

Geoff said in Apple's case they are an operating system (not just a browser)
and they have one root store and one TLS implementation. When they turn
SHA-1 off (just like they did for RC4), it goes off in the browser, email,
API calls from apps, everything. Exceptions mean they can't turn it off and
hence the ecosystem issues become a problem. Payment devices could be
impacted if Apple were to make this change. It's important to understand the
consequences. This is part of the reason they don't have a policy on
exceptions yet. They very much want to know what went wrong. It's been 10
years since NIST put out a SHA-1 deprecation policy. 

 

Charles addressed Ryan's comment on what went wrong. He suggested he be
given a list of CABF questions on how we got here and FS-ISAC would create a
questionnaire for their members. They would then aggregate those answers and
publish them for all to see. This would help show how the industry got here
but not one particular company. This would cover a large share of the
payment processors. 

 

Ryan said this doesn't address their need or use case. It is vitally
important to understand who the subscriber is for further comment and to
prevent abuse. Part of this addresses a potential to mount attacks. At a
minimum, the entire certificate must be disclosed - this is non-negotiable.
>From this info, the "who" can be ascertained. The idea for redaction is not
something they are willing to consider. The need for public discussion is a
critical part for Google to grant an exception.


Eric said that once you redact some info, this will lead to other
redactions. The example he gave is someone's legal counsel looking at the
application and trying to insure that in no way they can be identified-this
will lead to further redactions which will not even permit the cert name to
be disclosed; something that is just unacceptable and dilutes the quality of
the answers. 

 

Charles asked if the processor submitted the proposal and if questions came
back, would the answers then go back to the forum in a transparent way? Ryan
said yes, the proposal asks a set of initial questions and includes a 10 day
consultation period. This gives time for cryptanalysis and weighs risk to
the ecosystem as a whole. Google has been opposed to SHA-1 issuance and this
represents a balance to assist processors. It also gives CAs a "pass" to
issue these IF they follow the procedure.

 

Amy clarified that some members have done the SHA-1 to SHA-2 migration
successfully and do not have an issue. She asked if there is a way to
convene discussions where there is some level of security/confidentiality to
take into account security concerns and risks with a subset of the group.
There are instances where ETA has meetings with subset of members to discuss
security issues in private. Would such a discussion be possible given
sensitive business issues? Eric said the CABF list isn't the same as the
Mozilla list (i.e. only members and Interested Parties can post). Ryan
clarified that the Forum can't grant this exception and this is up to the
browser part of the CAB forum. What Amy is really asking then is if each
individual browser members would entertain such meetings. For Google, this
is not an option. Ryan also said that security concerns  were separate from
the transparency concerns and hoped to understand what those security
concerns were. 

 

Dean thanked everyone for participating and apologized for not getting to
other scheduled topics. He said he would put Philip's topic of Quantum
Computing as the first item on the next call. Philip said he needed to
discuss this before the Berlin IETF meeting in July. Peter suggested Philip
post this on the public list to generate a discussion. 

 

The next call is on July 7th.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160707/0db37943/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 : https://cabforum.org/pipermail/public/attachments/20160707/0db37943/attachment-0001.bin 


More information about the Public mailing list