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

[Erwann Abalea]

There’s a disadvantage with this approach, in that now, there’s no random information inserted by the CA to raise the attack cost.
Back to chosen-prefix collision, from random-prefix collision.

Cordialement,
Erwann Abalea

> Le 18 juil. 2016 à 19:36, philliph at comodo.com a écrit :
> 
> Looking at the recent SHA-1 muck up, I am not confident that the current approach works. It fails for the same reason that random Elliptic Curve parameters fails, there is no mechanism that allows a process for generating random numbers to be audited.
> 
> So lets go to the solution we chose for EC - rigid construction. This can be made to be auditable.
> 
> 
> I propose that the way be generate SHA-1 certs is as follows.
> 
> 1) Generate the tbsCertificate with the Serial number field containing the bytes [0x01 … 0x01], minimum of 16 bytes. This is just a fixed value placeholder. Also add an extension OID for ‘phb-sha1-hack'
> 
> 2) Generate the SHA-2-512 hash of the tbsCertificate structure
> 
> 3) Truncate the result of (2) to the length of the desired Serial number and populate. The result is the final tbsCertificate value.
> 
> 
> The advantage of this approach is that it is rigid and auditable. CertSentry can look for SHA-1 certs and check to see that the serial number format is compatible. If it is not compatible, the requisite consequences can be delivered to the guilty party automatically.
> 
> Yes, there are other ways to strengthen the process with commitments and such. But this approach guarantees that the cert has a work factor of 2^128 even if a second preimage attack on SHA-1 becomes feasible.
> 
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public