<div dir="ltr">Dean,<div><br></div><div>To be fair, there are still a number of outstanding questions posed to TSYS, so it's not readily apparent that they share your suggested sense of urgency. I do hope it was perhaps an oversight that <a href="https://cabforum.org/pipermail/public/2016-July/008027.html">https://cabforum.org/pipermail/public/2016-July/008027.html</a> has yet to be answered.</div><div><br></div><div>Also, please realize that this issue is precisely because the only request so far has every appearance of attempting to exploit the very thing the process was designed to protect against. The choice of random OUs is exceptionally concerning to us and members of the relying community, and the explanation in <a href="https://cabforum.org/pipermail/public/2016-July/008041.html">https://cabforum.org/pipermail/public/2016-July/008041.html</a> doesn't do much to assuage those concerns. Equally concerning is Symantec's own inability to follow a secure process in generating the tbsCertificates - a topic we explicitly discussed in Bilbao during the discussion about how a CA, such as Symantec, would be able to make use of this process, given that your systems would have difficulty with the serial number production.</div><div><br></div><div>I think it's reasonable to be concerned that the process as proposed may not be as foolproof as we'd all hoped, given the events surrounding the request, and the proposed change could be a very concrete way to address those concerns - AND the concerns with the very request you reference.</div><div><br></div><div>But I think perhaps most important to consider was the repeated communication that this should not just be assumed to be a rubberstamp process. Faced between a choice of rejecting the request for these concerning and opaque irregularities, or modifying the process to provide reassurances, I'm sure you can see why the latter would be preferred.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 5:50 PM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
The proposal to deal with SHA-1 issuance was discussed and debated in Bilbao, further discussed on list after Andrew drafted the proposal (which took into account the Bilbao discussion) and then further discussed on the CABF call with industry representatives at the end of June. This resulted in the "final" procedure which applicants used to prepare their info to the forum. One has come forward, based on all these adjustments and discussions, and prepared (in good faith) an application for consideration by the forum, browsers and the public.<br>
<br>
It would be very unfair at this stage to change that procedure especially as we have one party going through the process with an especially urgent request.<br>
<br>
In my opinion, the time to comment on the current procedure has passed. We should be fair to everyone by sticking to what was published. However, if the group wants to amend the procedure for upcoming applicants, that should be discussed and approved for the future.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of <a href="mailto:philliph@comodo.com">philliph@comodo.com</a><br>
Sent: Tuesday, July 19, 2016 8:06 PM<br>
To: Erwann Abalea <<a href="mailto:Erwann.Abalea@docusign.com">Erwann.Abalea@docusign.com</a>><br>
Cc: CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
Subject: Re: [cabfpub] A better way to do SHA-1 legacy<br>
<br>
The point is that it is not possible t change just one bit in a certificate at a time. Any change to the cert whatsoever will cause unpredictable changes to at least 128 bit in the cert.<br>
<br>
I know that we agreed to do something different. The reason I am proposing to revisit is that the original scheme isn’t auditable and people seem to be screwing it up.<br>
<br>
<br>
<br>
> On Jul 19, 2016, at 6:59 PM, Erwann Abalea <<a href="mailto:Erwann.Abalea@docusign.com">Erwann.Abalea@docusign.com</a>> wrote:<br>
><br>
> The attacker can tweak the public key and obtain a resulting tbsCert until a set of attacker-defined conditions is met. He doesn’t need to interact with anybody for that, and we don’t know what kind of « attacker-defined conditions » is acceptable.<br>
> In my view, it’s a regression from the current scheme.<br>
><br>
> Cordialement,<br>
> Erwann Abalea<br>
><br>
>> Le 19 juil. 2016 à 16:53, Gervase Markham <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> a écrit :<br>
>><br>
>> On 19/07/16 15:44, Erwann Abalea wrote:<br>
>>> There’s no need to collide SHA2 with this scheme.<br>
>>> The attacker can know in advance what the serial number will be; it<br>
>>> may not be sequential, but is nevertheless predictable. So the<br>
>>> attacker<br>
>><br>
>> But the attacker can only know the serial number when the entire<br>
>> remainder of the certificate is fixed. So how can they tweak it to<br>
>> enable the attack? If they tweak it, the serial number changes.<br>
>><br>
>> Gerv<br>
>><br>
><br>
> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div><br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>