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

Dean Coclin Dean_Coclin at symantec.com
Wed Jul 20 00:50:36 UTC 2016


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] On Behalf Of philliph at comodo.com
Sent: Tuesday, July 19, 2016 8:06 PM
To: Erwann Abalea <Erwann.Abalea at docusign.com>
Cc: CABFPub <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> 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> 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
> https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- 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/7ec29359/attachment-0001.p7s>


More information about the Public mailing list