[cabfpub] Proposal of a SHA-1 exception procedure

[Ryan Sleevi]

On Thu, Jun 16, 2016 at 6:03 PM, Dean Coclin <Dean_Coclin at symantec.com>
 wrote:

>  >>There’s transparency and then there’s security. We need to find the
> right balance.
>

You have yet to explain how or why that they're imbalanced. The only thing
you've argued so far is that there's security in obscurity. That's not
security.

> And that’s what I thought we did with the suggested cryptanalysis. Anyone
> can do it, everyone can see the results. Seems transparent to me.  BTW-I
> didn’t say trust one browser. The intent was to provide info to all
> browsers. Unless all browsers are in collusion, this seemed like a fair
> request.
>
The collective browsers represented in the CA/Browser Forum are either US
companies (Apple, Microsoft, Mozilla, Google) or Chinese companies (Qihoo
360 and Opera, pending regulatory approval of their sale to Qihoo 360).
Collective collusion is not outside the realm of public concern, especially
under a nation-state threat model.

But equally, it seems you don't think it's meaningful if 90% of the
certificates are issued to one company?

The entire ecosystem bears the risk.
The entire ecosystem took considerable effort to migrate.
You don't think that it deserves transparency as to why some failed? So
that we can understand how to do better in the future? So that we can make
sure the ecosystem isn't gamed and abused? To inform public policy and
participation?

Again, I'm simply not comfortable with having to tell Chrome users that we
can't explain why we did or not agree due to secret information. This is no
different than our unwillingness to sign NDAs with companies that misissue
certificates - these are matters of global interest, and transparency is
absolutely needed to avoid suggestions of collusion, compromise, or
negligence.

Equally, it doesn't help improve the ecosystem if the only people who know
why it failed are browser-members and auditors. That seriously limits the
amount of reasoned, public, rational discourse we can have on how to
collectively prevent such situations in the future.

> >>Exactly what I stated earlier. Giving out names puts a target on ones
> back and potentially releases security info.
>
> This isn't elaborating. You've again restated "potentially releases
security info" - without elaborating what you view that security info is.
That's uncertainty. You've hinged it on 'potentially' - without elaborating
what that security info is, that's just fear and doubt.

Again, if there are concrete concerns you'd like to elaborate on, I'm all
ears. If there are attacks you believe such organizations would be
vulnerable to, that's equally useful.

You're painting a very broad stroke of an argument.

>>So far, everyone has been pretty open in our discussion and comments to
> the draft; following our forum rules.  I hope we can continue this way.
> However, it would be good to come to conclusion soon given impending
> expirations of critical infrastructure certificates and impact to the
> financial ecosystem. Having said that, I know for a fact that some CAs are
> working hard with the affected vendors to try every possible alternative
> before resorting to the procedure discussed here.  Thanks.
>
So let's get to brass-tacks and figure out concretely what CAs' &
subscribers' concrete, actionable suggestions and objections are to the
proposal as originally proposed (that is,
https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD
 ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/00f2ea94/attachment-0003.html>