[cabfpub] Proposal of a SHA-1 exception procedure

Dean Coclin Dean_Coclin at symantec.com
Thu Jun 16 19:05:42 UTC 2016


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? 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 <mailto: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>  [mailto: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 <mailto:sleevi at google.com> >
Cc: CABFPub <public at cabforum.org <mailto:public at cabforum.org> >
Subject: Re: [cabfpub] Proposal of a SHA-1 exception procedure

 

See below.

 

From: Ryan Sleevi [ <mailto:sleevi at google.com> mailto:sleevi at google.com] 
Sent: Monday, June 13, 2016 8:54 AM
To: Dean Coclin < <mailto:Dean_Coclin at symantec.com> Dean_Coclin at symantec.com>
Cc: Andrew R. Whalley < <mailto:awhalley at google.com> awhalley at google.com>; CABFPub < <mailto:public at cabforum.org> 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 <mailto: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 <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public





 

-- 

konklone.com <https://konklone.com>  | @konklone <https://twitter.com/konklone> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/f9464b6e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160616/f9464b6e/attachment-0001.p7s>


More information about the Public mailing list