This is related to Mozilla Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1503638
INCIDENT REPORT: 1. How your CA first became aware of the problem Rob Stradling contacted a person related to WISeKey CA and it was redirected to us. Please note that the official channel for these communications is cps(AT)wisekey(DOT)com 2. A timeline of the actions your CA took in response. After we confirmed the issue, the intermediate CA was added to CCADB some minutes after receiving the communication. It's also important to clarify that this intermediate was in scope of the last WebTrust Audits and included adequately in the reports. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. N/A 4. A summary of the problematic certificates. This Intermediate CA was not set into production and the only certificates issued were the ones required for testing during the inclusion request of the new parent Root. 5. The complete certificate data for the problematic certificates. The Intermediate certificate is https://crt.sh/?id=880386822 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. WISeKey has two procedures related to CCADB disclosure: - The disclosure is done as a "post-ceremony" activity, once the first tests are performed - When a new CA is activated in our certificate management platform, we repeat a number of verifications, like certificate profiles, OIDs, etc. Typically a lack of disclosure would be detected at this point too. This intermediate was created under a new Root and its main purpose was to issue the required test certificates to request inclusion. As the Root was not yet included in CCADB when the Intermediate was created and therefore could not be disclosed normally, we didn't follow our standard procedure. Additionally, the Intermediate has not been yet put into production and not linked yet to our certificate management platform, so we didn't do the additional verifications before first issuances. Finally the new Root was included by Mozilla in mid August 2018, and at that point we should have detected the issue, but our process didn't consider this situation and we failed to notice the problem. Nevertheless, it must be also understood that for a new Intermediate under a Root not yet in CCADB it doesn't seem possible to fully follow section 5.3.2 (The CA with a certificate included in Mozilla’s root program MUST disclose this information within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates) because at that point (and until some months later) the parent Root wouldn't be considered in CCADB and in my understanding it's technically not possible to add subordinate CAs. We totally assume our mistake, as we should have proactively verified compliance with the Mozilla Policy once the new Root was activated in CCADB and detect ourselves the lack of disclosure of this intermediate, even before the new Root was included in the Mozilla Program, but as explained our procedure didn't consider this situation. To remediate this issue, we changed our procedure related to the relationship with Root CA Programs, so we ensure that once a new Root is accepted and included in CCADB, we verify the need to disclose Intermediate CAs created in the interim. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
