[cabfpub] A better way to do SHA-1 legacy

Wed Jul 20 13:17:05 UTC 2016

Rest assured that answers to all questions are being prepared by TSYS, not only to yours but the few others outstanding as well. This organization is new to the forum and this process and is therefore reviewing, checking and getting approval for all answers. If there are unsatisfactory answers to any questions, the community should ask additional questions for clarification. If after all concerns and questions are addressed, there are exceptional security concerns, those should be voiced and vetted.

I also note that some questions relate to what happened and  “lessons learned” while others are about the certs themselves and their construction. Priority is being given to the latter in case anything has to be redone but all will be answered.

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, July 19, 2016 9:07 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: philliph at comodo.com; Erwann Abalea <Erwann.Abalea at docusign.com>; CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] A better way to do SHA-1 legacy

Dean,

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 https://cabforum.org/pipermail/public/2016-July/008027.html has yet to be answered.

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 https://cabforum.org/pipermail/public/2016-July/008041.html 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.

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.

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.

On Tue, Jul 19, 2016 at 5:50 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

All,

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.

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.

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.

Dean

-----Original Message-----
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 philliph at comodo.com <mailto:philliph at comodo.com> 
Sent: Tuesday, July 19, 2016 8:06 PM
To: Erwann Abalea <Erwann.Abalea at docusign.com <mailto:Erwann.Abalea at docusign.com> >
Cc: CABFPub <public at cabforum.org <mailto:public at cabforum.org> >
Subject: Re: [cabfpub] A better way to do SHA-1 legacy

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.

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.

> On Jul 19, 2016, at 6:59 PM, Erwann Abalea <Erwann.Abalea at docusign.com <mailto:Erwann.Abalea at docusign.com> > wrote:
>
> 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.
> In my view, it’s a regression from the current scheme.
>
> Cordialement,
> Erwann Abalea
>
>> Le 19 juil. 2016 à 16:53, Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> > a écrit :
>>
>> On 19/07/16 15:44, Erwann Abalea wrote:
>>> There’s no need to collide SHA2 with this scheme.
>>> The attacker can know in advance what the serial number will be; it
>>> may not be sequential, but is nevertheless predictable. So the
>>> attacker
>>
>> But the attacker can only know the serial number when the entire
>> remainder of the certificate is fixed. So how can they tweak it to
>> enable the attack? If they tweak it, the serial number changes.
>>
>> Gerv
>>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org> 
> https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

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