[profmonocle]

Just to be clear - "mississued" in this case doesn't mean they were issued to someone who doesn't control the domain. The issue is they were issued using a 63-bit serial number instead of the minimum 64 bits. (The software these CAs were all using was generating 64 random bits, but setting the first bit to zero to produce a positive integer.)

The reason CAs are required to use 64-bit serial numbers is to make the content of a certificate hard to guess, which provides better protection against hash collisions. IIRC this policy was introduced when certs were still signed using MD5 hashes. (That or shortly after it was retired.) Since all publicly-trusted certs use SHA256 today, the actual security impact of this incident is practically nil.

[ehsankia]

Is there a reason why certificates are being issued using the bare minimum required number of bits, instead of something higher like 128 or 256? Why even risk being at the very edge?

[tialaramex]

There are legends that some software doesn't like serial numbers that don't fit in 64-bits. As with most legends you'll tend to hear a third hand story that someone heard once from somebody who remembers someone else telling them. Since this came up on m.d.s.policy we have a very specific client to always keep in mind, Mozilla's Firefox, and that doesn't care, but perhaps something else does, or did, at some unspecified point in the past. Probably.

The main practical reason seems to have been that a popular application used by Certificate Authorities, EJBCA, offered an out-of-box configuration that used 63 bits (it called this 8 bytes because positive integers need 8 whole bytes in the ASN.1 encoding used). That looks superficially fine, indeed if you issue two certs this way and they both have 8 byte serial numbers that just suggests the software randomly happened to pick a zero first bit. It's only with a pattern of dozens, hundreds, millions of certificates that it's obvious that it's only ever really 63 random bits.

But yes, I agree the sensible thing here (and several CAs had done it) was to use plenty of bits, and then not worry about it any further. EJBCA's makers say you could always have configured it to do that, but the CAs say their impression was that this was not recommended by EJBCA...

If you could go back in a time machine, probably the right fix is to have this ballot say 63 bits instead of 64. Nobody argues that it wouldn't be enough. But now 64 bits is the rule, so it's not good enough to have 63 bits, it's a Brown M&M problem. If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly? Or internally, if you can't make sure you obey this silly rule, how are you making sure you obey these important rules?

[adrianratnapala]

Thank yous all for teaching me about Brown M&Ms.

https://www.snopes.com/fact-check/brown-out/

[Ajedi32]

It seems that a popular open source software that CAs run on (EJBCA) defaulted to 64 bits and few people bothered to change it, since 64-bits was seemingly (but apparently not actually) compliant.

[remus]

Presumably there's already a big safety margin built in when using 64 bits and some computational overhead involved with increasing that to 128 or 256 bits.

[_wmd]

This seems highly unlikely to be authoritative -- AIUI serial number unpredictability is critical to SSL certificate security, as without it, it becomes possible to induce a CA into producing a signature that matches a certificate for another domain. Unless something else changed about the format when the hash algorithm was changed, AFAIK this property is independent to the hash algorithm in use

If memory serves it isn't a theoretical attack either, I read about it used against (Startcom maybe?) not so many years ago

[geofft]

The signature is over all the data in the certificate. So a hash collision in the signature algorithm makes this attack possible. (And if you can predict/control serial numbers, it makes the attack much easier because then you can generate a colliding pair of one valid cert and one invalid one and get the first one signed, instead of having to find a preimage of a valid certificate.) But without a hash collision, it should be theoretically safe to have no entropy at all. Most commonly-digitally-signed objects (Git commits, software packages, etc.) have no added entropy in the object itself / the input to the hash function.

[heinrich5991]

I believe this is only an issue if you can produce collisions for the underlying hash function. SHA256 is still considered safe against that.