[cabfpub] Mozilla SHA-1 further restrictions

Gervase Markham gerv at mozilla.org
Mon Nov 21 12:16:05 MST 2016


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.

But perhaps that's bad logic. Anyone have knowledge to comment?

Gerv


More information about the Public mailing list