[cabfpub] Proposal of a SHA-1 exception procedure

Ryan Sleevi sleevi at google.com
Thu Jun 16 21:58:04 UTC 2016

On Thu, Jun 16, 2016 at 2:44 PM, Dean Coclin <Dean_Coclin at symantec.com>

> My suggestion was that the browsers be notified of those details but that
> they be redacted from the public document.

Right, in case it wasn't clear:

There is no desire from Google for any of this to happen in private. If at
any part the answer is "Trust Google to have done due dilligence", that's
simply a non-starter. That is not keeping the ecosystem risks in
consideration, and is favoring a system that invites itself to compromise,
coercion, or negligence.

I know that at least one Browser feels that openness is inconsistent with
their principles. I can respect that, but I think we'd disagree. The
issuance or non-issuance affects far more than just browsers or just
financial services, and no special preferential treatment should be given
to either those affected or those here in the Forum. If we are going to
introduce security risks that threaten the entire ecosystem - from mobile
devices, to IoT, to cars, to thermostats, to browsers, to server-side
processing systems, and everything big or small that uses TLS with publicly
trusted certificates, rightly or wrongly, then we need transparency.

> As Jody stated in Bilbao, there is no point in exposing this information
> if it introduces security risks. He also said that we should be
> collectively trying to find a solution which involves compromise. To that
> end, I think Andrew has done a great job with his initial proposal,
> garnered from the discussion in Bilbao. But some fine tuning should be
> expected and hopefully we can find an amenable solution to all parties.
> Today I participated on a call with FS-ISAC members in which they
> expressed a security concern about the current procedure. Hence my comments.

Care to elaborate what those concerns are, in the benefit of transparency
and avoiding fear and uncertainty?

> I’m wondering if a separate working group type call could be held to mash
> out a final, recommended document and present to the forum members. I’m not
> suggesting a formal working group, rather a subset of the normal meeting
> call in group that can work together to propose a final document.

Ultimately, I think it's up to each and every rootstore to separately
evaluate what they see as appropriate risk to allow issuance, much in the
same way they determine the appropriate risk to handle if a CA fails to
follow those procedures.

Google's proposed a solution that embraces transparency, which we feel as a
critical necessity for decisions that effectively put the entire TLS
ecosystem at risk. It is unfortunate that others disagree. I think we're
more than happy to entertain concrete concerns with the proposal, and
absolutely amenable to change, but feel it's similarly necessary to have
transparency over those discussions and concerns. As an organization
frequently under the spotlight for matters of security, good and bad, I'm
sure you can understand how important it is that there isn't an appearance
of slinking off to smokey back rooms to hash it out in secret cabals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/1739dc02/attachment-0003.html>

More information about the Public mailing list