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

[Peter Bowen]

I would suggest a couple tweaks to the proposed rigid construction:

1) Use SHA-512/t rather than just truncating SHA-512.  This prevents an attacker from getting multiple guesses out of each computation.

2) Require the serial number placeholder to be the same length as the truncation length.

3) Require the top bit of the resulting value be set to zero to ensure a positive serial number.  This should be done after the hash is calculated.

I also agree with Dean — this should be considered for future requests.  It is not reasonable to ask to have a change coded and deployed within the evaluation window for this request.

Thanks,
Peter

> On Jul 20, 2016, at 2:54 AM, philliph at comodo.com wrote:
> 
> The point of the extension OID is to allow an auditor to distinguish between different types of CA blunder. Specifically a CA that fails to produce sufficient randomness and a CA that tries rigid construction and does it wrong.
> 
> I would not expect it to be verified in the client end point, the only place where I would expect it to be used is in CertSentry and similar.
> 
> 
> And just responding to Dean’s point. Yes, we did have a vote etc. But then there was a mis-issue that called into question the approach originally proposed. We are now in an incident response mode. 
> 
> Even if it is too late to change matters this time round, this incident caused me to significantly change my thinking on the value of random vs rigid construction. I think it is useful to consider the strengths of the different approaches.
> 
> 
> The point of ‘randomizing’ the serial number is not that there is a value in unguessability, it is to prevent attacks on the compression function that depend on related keys. 
> 
> If you really wanted belt and braces you could add a nonce generated by the CA to the phb-sha1-hack extension. That would then ensure that the serial number contained the necessary 64 bits of randomness as per the spec while preserving the ability to audit the scheme.
> 
> 
> 
>> On Jul 20, 2016, at 3:13 AM, Ryan Sleevi <sleevi at google.com> wrote:
>> 
>> 
>> 
>> On Mon, Jul 18, 2016 at 10:36 AM, philliph at comodo.com <philliph at comodo.com> wrote:
>> 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'
>> 
>> Objectively speaking, what value does 'phb-sha1-hack' add? 
>> 
>> It would only seem to add value if someone wanted to continue trusting new SHA-1 certificates and programatically evaluate those that contain such an extension.
>> 
>> That doesn't seem to be a thing we should encourage, given that the very argument for the need for these is that they're not to be publicly trusted and on systems that cannot be updated.
>> 
>> Have I missed some other use case?
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public