[cabfpub] Mozilla SHA-1 further restrictions

[Erwann Abalea]

Bonjour,

> Le 21 nov. 2016 à 20:16, Gervase Markham via Public <public at cabforum.org> a écrit :
> 
> On 18/11/16 22:36, Wayne Thayer wrote:
>> What constitutes a 'documented compatibility reason'? Is the intent
>> to create a very limited scope backed by hard data, or is "Windows XP
>> (pre-SP3)" a 'documented compatibility reason'? I would like to
>> continue to provide SHA-1 signed OCSP responses and CRLs for all
>> certificates in GoDaddy's SHA-1 hierarchies (root - intermediate -
>> and EE certs are all SHA-1), but if the intent is to prevent that
>> with this bullet, then I'd like to make it clear here - perhaps by
>> requiring approval rather than just documenting.
> 
> Are such roots still trusted by Mozilla?
> 
>>> * The CA takes care the all of the signed data is either static, 
>>> defined by the CA, or of a known and expected form.
>> 
>> Should we specifically ban nonces in OCSP responses?
> 
> Well, a nonce is a "known and expected form", even if the data is
> arbitrary, it's of a known length. My understanding of engineering
> collisions is that it normally requires a fair amount of junk to be
> added and the attacker can't control the length of the particular bit of
> calculated junk which works.

The nonce is an OCTET STRING, with no constraint. As are the issuerKeyHash, issuerNameHash, and serialNumber.
One could play with some heuristics and ban arbitrarily large values, for example > 20 octets for a nonce, > 20 octets for the serialNumber (only possible if the CA is absolutely RFC5280-compliant wrt the serialNumber length), and > 64 octets for the hashes.
After the « rogue CA » demonstration, where the colliding messages were 3 blocks large at least, single block MD5 collisions have been made possible. A classic SHA1-signed OCSP tbsResponseData is 3 blocks wide, of data completely under the attacker’s control.
Add the MD5->SHA1 improvements in resistance, subtract the advance in cryptanalysis and computing power, and you’ll get a subjective risk level.

I may be wrong, but I think that when using a non collision-resistant hash function, OCSP responses provide a larger attack surface than certificate requests services. And it is the case even if nonces are banned.

Of course the best answer should be to completely ban SHA1. But since we’re struggling with legacy stuff, my proposal would be to ban SHA-1 OCSP signing from a CA key, and instead use a designated OCSP responder certificate for such responses.

Cordialement,
Erwann Abalea