[cabfpub] Proposal of a SHA-1 exception procedure

Eric Mill eric at konklone.com
Tue Jun 14 20:07:21 UTC 2016


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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160614/381fcb69/attachment-0003.html>


More information about the Public mailing list