[cabfpub] Proposal of a SHA-1 exception procedure

Eric Mill eric at konklone.com
Fri Jun 17 03:16:58 UTC 2016


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

> If I said, “Dean Coclin’s Really Valuable Credit Card Processing Center”
> is using a SHA-1 certificate, isn’t that like painting a target on me?
>

The target was already painted by running a really valuable credit card
processing center. As Ryan argued in his latest email, this argument is
generic "security through obscurity" enterprise angst, and not very
persuasive when measured against the need the entire web PKI community to
have the information it needs to handle this and future migrations
responsibly.

-- Eric



> So answering questions 1 and 2 in the public domain is adding risk to the
> cert requestor. A proposed answer could be, “ETA Member #32”, where
> browsers who are members of the ETA could know for sure who it was.
>
>
>
> The cryptanalysis, to my understanding from Ryan and Andrew’s explanation,
> was to help mitigate the risk of a SHA-1 collision and designed to minimize
> risk to the PKI ecosystem.
>
>
>
> *From:* Eric Mill [mailto:eric at konklone.com]
> *Sent:* Tuesday, June 14, 2016 4:07 PM
> *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 Tue, Jun 14, 2016 at 3:45 PM, Dean Coclin <Dean_Coclin at symantec.com>
> wrote:
>
> Also, some important points I heard in both Bilbao and on the call are
> worth repeating here:
>
>
>
> 1. In Step One of the procedure, it appears some of the questions are of
> an informational nature. For example, would the answers to 7 or 8 somehow
> disqualify an applicant from their request being granted?  It was my
> understanding that these type of questions were for learning purposes, to
> help formulate how future deprecations would be timelined.
>
>
>
> 2. Going public with some of this information seems like an invitation to
> hacking. Would it be possible to redact certain security information from
> the public version and send that only to the browser representatives?
> Otherwise, it seems we are mitigating one security risk (using
> cryptanalysis) but artificially introducing another.
>
>
>
> What security information being requested would provide an invitation to
> hacking? That needs to be more specific to be actionable, and there may be
> disagreement about how sensitive this information is.
>
>
>
> For example, sharing the domain names involved with a payment service
> might be considered internal information by the service owner, but is
> unlikely to actually be internal information in practice, given how much
> information is available to even the most untargeted scanner, much less a
> targeted inquiry. Since only sensitive infrastructure is even being
> considered for this process, a basic level of understanding by potential
> attackers of a provider's internet-facing infrastructure should already be
> assumed.
>
>
>
> Wherever possible, a process that allows a payment (or other) provider to
> weaken the public PKI, even temporarily, should reflect well-defined risk
> and not just a general sense of risk aversion. The burden should be placed
> on demonstrating why information should be kept secret, rather than why it
> should be made public.
>
>
>
> -- Eric
>
>
>
>
>
> Dean
>
>
>
>
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Dean Coclin
> *Sent:* Monday, June 13, 2016 12:18 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* CABFPub <public at cabforum.org>
> *Subject:* Re: [cabfpub] Proposal of a SHA-1 exception procedure
>
>
>
> See below.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Monday, June 13, 2016 8:54 AM
> *To:* Dean Coclin <Dean_Coclin at symantec.com>
> *Cc:* Andrew R. Whalley <awhalley at google.com>; CABFPub <
> public at cabforum.org>
> *Subject:* Re: [cabfpub] Proposal of a SHA-1 exception procedure
>
>
>
>
>
>
>
> On Sun, Jun 12, 2016 at 3:20 PM, Dean Coclin <Dean_Coclin at symantec.com>
> wrote:
>
> Andrew,
>
>
>
> Thank you for taking the time to formalize what was discussed in Bilbao.
>
>
> Regrettably, I was unable to attend the call last Thursday where I
> understand this was discussed in more depth. However, I believe the
> following are the action items:
>
>
>
> 1. Andrew to re-look at the questions to see if (a) are they all
> necessary, (b) can some be phrased differently and (c) would any additional
> questions be helpful?
>
>
>
> Hi Dean, as discussed on the call, I think this is simply some fundamental
> disagreement with Microsoft about what represents the minimum steps
> necessary for the public interest. We (Google) feel there is necessary
> information that should inform this discussion in order to help mitigate
> current risks and prevent future changes to the BRs from running into this
> same situation. Microsoft is OK allowing either CAs to provide this
> information or for it to be omitted.
>
>
>
> This is no different than how various root stores diverge on policy, even
> though they agree to a common baseline.
>
>
>
> Notably, as this is not being proposed as a CA/B Forum Ballot to adopt -
> as made abundantly clear in Bilbao and restated on our call - the goal is
> not to whittle it down to the bare minimum that everyone can agree on, but
> rather, to hopefully ensure there is minimal disagreement on the basics.
>
>
>
> As at least one member made it clear they won't be able to participate in
> discussions on this topic if those discussions happen in the public
> (refraining from naming who until the minutes are published), it does not
> appear that the action item you propose is a useful or valuable task. As
> such, this represents at least what Google/Chrome feels is relevant to
> consider SHA-1 exceptions.
>
>
>
> >>Nonetheless, I did hear Andrew say on the recording that he would take a
> 2nd look at the questions to review a, b and c.  Hence I assumed he was
> planning on doing so.
>
> 2. There was extensive discussion about the necessity of all the
> questions. Rather than rehash that here (I guess we’ll see that in the
> minutes), I assume Andrew will address that in 1a above.
>
>
>
> As above, I do not believe this is necessary.
>
>
>
> 3. There was an unanswered question from Peter regarding audit findings
> which needs clarification from the browsers. Basically, the issuance of a
> SHA-1 certificate that went through this procedure would result in a
> qualified audit but it was my understanding from Bilbao that the CA should
> record the answers to the questions and cryptanalysis for review by their
> auditor. Browsers would then not consider any punitive action if the record
> was complete (as shown in the audit report). However, this is not
> documented in the procedure and I believe Peter (correctly) pointed out
> that CAs should expect something in writing here, otherwise there is no
> distinction between following and not following the procedure.
>
>
>
> I'm concerned there may be have some misunderstanding about the process;
> the suggestion was that this information would be public, but the auditor
> would review evidence that the proposed procedure was followed. Perhaps
> more importantly, it's unclear what you expect to see 'in writing' here. It
> sounds like you're asking for something from the specific root programs you
> care about, but perhaps you can elaborate on what you want to see, or how
> that meaningfully differs from when CAs have, in the past, approached root
> programs about exceptions to the BRs. For example, I know Google did not
> provide anything in writing for WorldPay as an exception before Symantec
> went and issued those certificates, so I'm not sure what you'd like to see
> provided from us this time around.
>
>
>
>
>
> >>What I believe Peter was trying to point out before the agenda item
> ended was that if this procedure is agreed to by CAs and Browsers, a CA
> would expect that the browsers would not take action against CAs from the
> audit finding. Hence he was asking that this be noted in the procedure, for
> clarification.
>
>
>
> Dean
>
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
>
> --
>
> konklone.com | @konklone <https://twitter.com/konklone>
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/59c2676a/attachment-0003.html>


More information about the Public mailing list