Hacker News Reader

Comment by steventhedev | Hacker News Reader

Can the admins change this to point to the actual mailing list thread[0]?

I'm still reading through the thread, but it seems that DarkMatter have some small technical issues around issuing certifications. Specifically, the claims seem to be:

1. using 63 bits of entropy for the serial number instead of the required 64.

2. name constraints were incorrectly filled in for their intermediate certificates.

3. DarkMatter's other business units may compromise the CA internally for malicious purposes.

[0]: https://groups.google.com/forum/#!topic/mozilla.dev.security...

EDIT: more background - DarkMatter have an open request to be included in the Mozilla CA Store[1], and are currently trusted through intermediate certificates rooted with QuoVadis, who were recently acquired by DigiCert.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1427262

View on HN

I think DarkMatter is right on 64 bit entropy discussion, requirements are clearly wrong unfortunately.

- it says you should use 64-bit entropy as output from a CSPRNG

- it says Serial number is a signed number

If you use 64bit serial, you clearly lose 1 bit. That means any certificate with 64bit serial is not conforming to the standard.

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.

It is not contradictory but it can be confusing when many parties involved.

You have some software to get key for serial from RNG, when you get 64 bit and put it to serial field, you feel it is ok.

This is probably what happened in this case. But if requirements made sure lets say signature part is 64bit random + some extra (serial, identifier etc) forcing serial field to be one more octet, this could never happen.

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/...

I don't have much knowledge about certificates, except from what I read on this mail list. But are there are other CAs active (in mozilla's root trust), using 64bit serial?

Probably.

Mozilla doesn't have a big team of investigators wandering about looking for possible problems. The CAs could dob themselves in (filing a "problem report" that says they broke this rule and what they're doing about it) or an independent researcher could write to m.d.s.policy about a problem they found. Otherwise it may go undetected forever.

Most interest is focused on problems that either directly indicate a grave problem (e.g. some researcher got a CA to issue for example.com when they shouldn't because that researcher doesn't control example.com) or suggest a management problem that could hide further grave problems from us (e.g. Symantec had paperwork that directly contradicted the operational behaviour of CrossCert, so why did we notice the problem before they did?)

The 64-bit entropy rule isn't such a problem. CAs should use random values here because it protects us against a problem with the secure hash function (SHA256 usually these days). If the hash function is slightly broken the random numbers buy us time to get a new one. But if you have 63-bits instead of 64-bits, it's not like that's the difference that makes an attack viable. It's just a technical violation, it's a Brown M&M in that sense. The rules say to do it, and they didn't, so we are more worried than otherwise that they are not obeying the rules.

> 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.

Some things don't like negative serial numbers, and so the Baseline Requirements (which is where this 64-bit entropy requirement comes from) say to only use positive serial numbers. Thus, "you clearly lose 1 bit".

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!

Reply on news.ycombinator.com