Re: DigiCert/Symantec updates
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert/Symantec updates
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=141). 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DigiCert/Symantec updates
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=141). 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
