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

[philliph at comodo.com]

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 <mailto:philliph at comodo.com> <philliph at comodo.com <mailto: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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160720/d736a106/attachment-0003.html>