[cabfpub] SHA-1 exception request

[Dean Coclin]

“…hoping to use the precedent of the previous failure to follow policy as an indicator that the policy has been changed.”

 

I assume this is in reference to the TSYS certs which were granted an expiration in Feb 2017. This was not a failure to follow policy nor “Symantec’s previous mistake” and in fact you may recall all the reasons TSYS spelled out for extending to that date due to merchant holiday peak periods (which have been enumerated again on behalf of First Data). This was discussed and approved by the browsers on the public list after a reasonable discussion. I don’t consider this a “failure”; rather a rationale response to a reasonable request to insure continued payment processing for a set of merchants. 

 

 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, October 18, 2016 4:29 PM
To: Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> >
Cc: Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> >; CABFPub <public at cabforum.org <mailto:public at cabforum.org> >; Halliday, Morgan <Morgan.Halliday at firstdata.com <mailto:Morgan.Halliday at firstdata.com> >; Sidoriak, Evan S <Evan.Sidoriak at firstdata.com <mailto:Evan.Sidoriak at firstdata.com> >
Subject: Re: [cabfpub] SHA-1 exception request

 

 

 

On Tue, Oct 18, 2016 at 4:10 PM, Dean Coclin via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

Given that the current TBS certs have passed cryptanalysis, could you allow
the issuance of the TBS certs as presented, and mandate that the CA revoke
those
certs on 12/31 (or the next business day). This is an auditable event and
browsers can push that revocation out to their clients via their own methods.

I believe this meets the intent of the affected browsers by protecting their
users after that date. It also avoids disruption to First Data clients on
October 27th.

 

Symantec has suggested this several times, for other incidents, as have other members of the CA/Browser Forum.

 

Our position is that revocation, while it can be useful in reducing risk to (some of) our immediate user populations, does not represent a sufficient or suitable solution for protecting the broader ecosystem or reducing the moral hazards of various proposals.

 

My understanding is that these certificates begin expiring October 27, and the current urgency was and is created by Symantec hoping to use the precedent of the previous failure to follow policy as an indicator that the policy has been changed. While unfortunate, I agree with Gerv's remarks on the moral hazard of this line of reasoning and this line of utility, and while I appreciate Symantec's exceptional efforts to work on an alternative solution for their customer, I think it's best to follow the policy as outlined some time ago. We discussed and gathered feedback on this precisely to avoid the situation we're in now - we wanted to have an objective, rather subjective, process, which you're now asking that we undermine because Symantec made an assumption, based on Symantec's previous mistake which was not caught (amidst all the other issues Symantec had with the previous request).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161022/4a98481e/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/20161022/4a98481e/attachment-0001.p7s>