[cabfpub] Proposal of a SHA-1 exception procedure

Eric Mill eric at konklone.com
Mon Jun 20 19:19:30 MST 2016


The entity name has some direct utility in putting 3 through 8 in context,
and making those answers more useful in understanding why companies ended
up in the situations they did. For example, an answer to question 7 ("When
and how did the Subscriber first become aware of the SHA-1 sunset?") of
"August 2015" would be a lot different coming from AT&T than from a
regional payment processor. Follow-on proposals to address each of them
would likely be different.

But more concerning is the downside to declaring the entity name a secret
-- once you do that, then it starts making sense to keep the answers to #2
(description of the infrastructure) and #9 (the certificate itself) a
secret, since the certificate could probably be traced back to the entity
through the hostnames or other metadata. Similarly, the respondent is
likely to give more minimal answers to #3 through #8 in the interest of
redacting details that might point to their identity.

Making identifying oneself a requirement of obtaining a certificate removes
disincentives to filing a full and complete report of why the multi-year,
multi-stage SHA-1 deadline didn't work out for their piece of critical
infrastructure.

It's not surprising that payment processors are reluctant to provide their
names, and legal departments will be a barrier. But if it's truly critical
that an organization receive SHA-1 certificates to continue operations,
that barrier shouldn't be insurmountable.

On Mon, Jun 20, 2016 at 12:02 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> Eric- I get that. Lessons learned is a great tool for future deprecations.
> But what I think the processor industry doesn’t understand is how the
> particular name of the applicant helps toward that end. What difference
> does it make if the applicant name is Chase, TSYS, Worldpay, or Blueswipe?
> It seems the valuable answers to help future deprecations are those to
> questions 3-8 (i.e. what steps have been taken, impact, expected transition
> time, awareness, etc). How does the specific entity name address your goal?
>
> Thanks,
> Dean
>
>
>
> *From:* Eric Mill [mailto:eric at konklone.com]
> *Sent:* Saturday, June 18, 2016 11:25 AM
> *To:* Dean Coclin <Dean_Coclin at symantec.com>
> *Cc:* Ryan Sleevi <sleevi at google.com>; CABFPub <public at cabforum.org>
> *Subject:* Re: [cabfpub] Proposal of a SHA-1 exception procedure
>
>
>
> On Fri, Jun 17, 2016 at 6:35 PM, Dean Coclin <Dean_Coclin at symantec.com>
> wrote:
>
>
>
> >>I think this is the crux of the issue which will require dissecting this
> sentence. First, “That includes the necessary disclosures and information
> so that we can gather information necessary to avoid such situations in the
> future”: This is great and  I don’t think anyone has an issue with
> gathering this information so the CA/B Forum and root store operators can
> avoid future issues. The second part, “while having the necessary
> transparency for us effectively accepting, on behalf of the Internet trust
> ecosystem, the security risks” focuses on the security risks which I
> thought were ameliorated by the cryptanalysis. Is this not true?
>
>
>
> The cryptanalysis ameliorates risks associated with the basic technical
> weaknesses that prompted the SHA-1 deprecation. It doesn't speak to any
> risks associated with how long it has taken the ecosystem to migrate away
> from SHA-1.
>
>
>
> Those risks are just as real, especially since continued issuance of SHA-1
> signatures by any one actor creates risk for all actors. And they'll be
> just as real when it's time to deprecate SHA-2, or to deal with practical
> quantum computing. To the extent the SHA-1 deprecation is a dry run for
> future migrations, the cryptanalysis is less important than the business
> analysis -- an analysis the entire community needs access to.
>
>
>
> -- Eric
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160620/ade1b7e5/attachment.html 


More information about the Public mailing list