Re: DigiCert/Symantec updates

[Kathleen Wilson]

This hasn't shown up in Google Groups for me yet, so please see the
message below from Jeremy.

Note that there is a bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=1412993) and a Google
support ticket open for this problem of messages that are posted via
Google Groups not showing up in Google Groups. The messages are showing
up in news.mozilla.org.
Other ways to participate in this discussion forum:
https://www.mozilla.org/en-US/about/forums/#dev-security-policy


On 11/15/17 9:03 PM, Jeremy Rowley wrote:
> Hey everyone,
>
>
>
> I wanted to give the community and update on how the DigiCert-Symantec
> transition is going and make everyone aware of a few issues I recently
> created on Bugzilla.
>
>
>
> First, the good news. DigiCert has started validating and issuing
> certificates through the Symantec platform for a limited number of
> customers. The initial tests are positive, and I think we're on track to
> meet the Dec 1 requirements. Thanksgiving next week is going to be a sad
> holiday, but we're very excited to see everything go live. Right now, we
> are doing DV, OV, and EV validation, although only issuing DV certs (as a
> test of the integration). You can see the hierarchy and migration plans
> here: https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. I'm happy to
> answer any questions about it as well.
>
>
>
> The bad news is there are some compliance issues.
>
>
>
> 1. EV JOI issues. I filed this a while ago but never posted about it.
> This bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1413761) caused
> duplicate certificates to issue with incorrect JOI information. Basically,
> when someone duplicated with a different key (RSA vs. ECC), incorrect JOI
> information would be placed in the certificate. The certs were revoked and
> everything was dumped into CT.
> 2. CAA Woes. Like most CAs, Symantec had improper CAA record checking
> where DNSSEC was not properly checked if the record timed out.
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1409735). A patch was applied
> to prevent this. As of Dec 1, all CAA record checking will be done by
> DigiCert's systems instead of the systems we acquired from Symantec.
> 3. Undisclosed CAs. The details are a little iffy on this one so far,
> but I think there are a couple hundred undisclosed issuing CAs within
> Symantec's infrastructure. These CAs are not issuing TLS certs from what I
> can see, but they aren't disclosed in CCDAB
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1417771). I'll be posting
> updates there as we figure out what we're looking at. I think there was
> confusion about whether these required disclosure as they don't issue certs
> and are within the Symantec HSMs. I think disclosure and audit reports are
> required so we'll be updating the latest audit report to show them.
>
>
>
> And my least favorite because its DigiCert pre-close:
>
> 4. Insufficient Entropy. This one makes me sad because of how dumb it
> is (https://bugzilla.mozilla.org/show_bug.cgi?id=1417777). DigiCert's older
> validation system validated domain control using random values in emails
> sent to the WHOIS contact. These random values did not contain 112 bits of
> entropy. They contained 112 bits, but some of the characters were fixed.
> The actual entropy was about 77. Only the one system was impacted. The
> root cause was a developer not realizing 112 bits != 112 bits of entropy.
> All other systems were verified as operationally correct. This impacts a
> large number of certs (like tens of thousands) so we're not 100% sure on how
> to best remediate, especially since significant entropy still existed in the
> random value.
>
>
>
> Let me know what questions/comments you have. Looking forward to the
> discussion!
>
> Jeremy
>
>
>

[Nick Lamb]

4.1 Further to Gerv's question in the bug, I see that Digicert have not actually enumerated the set of issued certificates which are affected. Are you confident that if it became necessary you can do this? I recommend doing this and reporting the count even if not asked to actually list all the affected certificates.

4.2 Because this problem was discovered without recourse to Digicert internal materials there is an enhanced chance that an adversary discovered it independently (and did not report it) compared to if the issue had been less discoverable. I'm sure Digicert will be on the lookout for problems in these certs, but independent researchers have a better chance of finding suspicious things through sheer numbers. Accordingly if any aren't already I suggest the affected certificates be sent to CT logs. If it's more convenient to send a superset (e.g. also logging certs that didn't come through this issuance path) that's fine for this purpose.

4.3 Other CAs should consider if they might have issues like this lurking. Do you have places that mix random and non-random data to form a token? Make sure the result still meets any requirements for randomness / entropy. From an engineering standpoint it may be easier - especially in new systems - to separate random data clearly so that any deficiency is more obvious. For example server4-Nov15-a5213e makes it more obvious the token has just 48 random bits than a5213es41115