Mozilla fears DarkMatter ‘misuse’ of browser for hacking

How does that mean the requirements are wrong? Larger than 8 byte serials are allowed in the certificates, as is mentioned in that thread. I don't see how the requirements of the CA forum and the certificate representation can be taken as inherently contradictory instead of simply requiring a larger than 8 byte serial.

The number 64 is arbitrary, and was chosen because of potential birthday attacks on digest algorithms. Mozilla enforce the BR sometimes in extreme ways, and we derive security and trust from that enforcement. In many cases, the BR are confusing, unclear, or ambiguous. The confusion here arose from the BR requiring 64 bits of entropy from a CSPRNG and to always be positive, and ASN.1 integer fields using signed integers, so 1 bit is lost to the sign bit.

In this specific case, they have the option to use 160 bit fields for the serial number. They chose to use the minimum required of 64, apparently out of performance concerns for embedded devices with limited memory/compute.

The CA platform (EJBCA) they use defaulted to this behavior, and from what I was able to understand[0] are in the process of pushing out an update to all their customers to resolve the issue. It is very likely that someone will start going through the CT logs and we will see many reports of insufficient entropy in cert serial numbers.

[0]: https://groups.google.com/d/msg/mozilla.dev.security.policy/...

> If you use 64bit serial, you clearly lose 1 bit.

That's not clear to me at all. A 64-bit signed integer can still contain 64 bits of entropy, it just has to be negative 50% of the time.

The requirement in question is "Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG".

This has been generally accepted (via discussions on MDSP and in the CABForum itself) to mean that the serial must contain at least 64-bits of entropy. Not that the generation process consumes 64-bits. If it was the latter then `head -c 8 /dev/urandom | head -c 1` (and clamping the top bit to 0) would be a permissible method of generating a serial since it consumes 64-bits of CSPRNG output to generate the serial number.

CAs are given enormous power in the ecosystem and we judge them based on their incident response and process improvement. The barrier to entry should be very high for new entrants as we strive to improve the state of the industry. This incident alone is not a disqualifier for DM's inclusion but should be considered in the context of the other issues (both technical and otherwise) raised during review of the application process.

Regarding your claim that all certificates with 64-bit serial numbers are guaranteed invalid: A certificate with a 64-bit serial MAY be valid under the standard because a CA might choose to implement the spec such that they generate a serial and prepend a null byte if and only if the high bit is 1. To determine whether or not a CA is doing that experimentally you could use services like crt.sh or censys to find all CAs with valid 64-bit serial number certificates and see if they also issue 72-bit serial numbers. If you don't see any >64-bit they're likely violating the BRs and you should submit a report to them (Mozilla maintains a contact list for CAs on their wiki) and also send an email to MDSP. Independent researchers are the lifeblood of the current wave of enforcement across the industry!

They do wildcard certificates now, I have several of them. I _think_ they do SAN as well.

The biggest issue with it to me is the "vouch for their security" part, perpetuating the myth that HTTPS means the site is "safe" or that a certificate is a security audit of some kind.

I'm not a fan of promise - it makes it sound like a choice, and not something enforced by the design (assuming it's set up properly, which the CA _can't_ promise).

That kind of explanation is how a company could "promise the traffic will not be intercepted" while using ROT13 to secure it.

Also the insurances/warranties are a joke, the way they're written, there is pretty much no way anyone will be able to ever land a claim against them.

Yeah, no, it's pretty badly wrong.

Sometimes you will see a journalist say something that's just _technically_ wrong, in an "Um... actually" kind of way. Like saying there are 4 billion "Internet addresses". Yeah it's actually 2^32 and those are IPv4 addresses, and anyway some are in reserved classes we can never use and... We shouldn't care about these cases, it's fun to make a big deal as a _nerd_ but it's not a real problem.

But here they are misleading people as to the general purpose of a CA.

The CA doesn't in fact promise "traffic will not be intercepted" and how could they. The CA promises that their subscriber proved to them that they know a private key to which the corresponding public key is in the certificate, and that they control the things (usually FQDNs) named in the certificate.

Insurance, as another poster points out, is basically worthless. In fact it's worthless in multiple independent ways, it's deliberately engineered to _be_ worthless. For consumer insurance that would be illegal in many countries (taking people's money to "insure" against a risk that won't happen is prohibited in those countries), but they don't sell it to consumers, they sell it to the Certificate Authority and non-individuals are more free to make bad decisions since nobody important will get hurt.

> AFAIK the logic is that the since root CA is fronting the risk (in case of any misissuance), there doesn't need to be any extra scrutiny on the part of browser vendors.

This logic doesn't make sense (though I think it is the logic)

- We audit CAs precisely because the cost of being caught isn't high enough to provide a reasonable deterance.

- No one is suggesting removing digicerts root certs over this. The cost to the public is too high.

> the root CA will simply provide a API that rubber-stamps whatever certificate is requested.

- We audit CAs precisely to prevent them from doing things like this... Any CA caught doing this after it was forbidden isn't worth anyones trust and could be immediately removed.

- Even that would be an improvement because they would presumably keep logs...

A standard website cannot access your local services. 127.0.0.1 and localhost are local addresses to the server, not the end user system. Private addresses cannot be accessed over the public internet.

This is about a server accessing backend local services on the server or local private network via a SSL terminating reverse proxy etc.