- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
At the end of 2019 Logius was also reviewing other CCADB records (besides the one mentioned in bug 1605126) that have been flagged by ALV. The outcome was that only one other CA was flagged by ALV, specifically, the "UZI-register Medewerker Niet op Naam CA G21". Unlike the CAs mentioned in bug 1605126, it seems that in this case that the CA in question has been "skipped" in the yearly audit in 2017/2018 as well as 2018/2019. The cause for this seems to be a misinterpretation of Mozilla requirements by both Logius and CIBG.
- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
(all dates are in the format dd/mm/yyyy)
25-11-2019 Logius was notified by CCADB that the fingerprint of the issuing CA with CN “UZI-register Medewerker niet op naam CA G21” was missing from the audit statement that CIBG supplied Logius as a result of their yearly audit concering the year 2017/2018. Logius then asked CIBG for a clarification
28-11-2019 CIBG gave a formal response in which they indicated that in June 2017 issuance of certificates by this CA was halted because of a new ETSI certificate profile requirement which their systems at the time couldn’t comply with (specifically, the inclusion of the Subject.Organizationidentifier field as required by ETSI EN 319 412-3 section 4.2.1). The intent was to do a system upgrade and resume issuance (but then under the new G3 TSP CA) at a later moment. At the time, the question of audits was discussed between CIBG and Logius, and Logius at that time gave the answer that a partial audit was still required (all areas of the certificate lifecyle minus certificate generation). These services were audited for the other CIBG (issuing) CA’s, but because CIBG was no longer issuing under this CA, they interpreted it as OK to place this CA out of scope of the audit in its entirety. CIBG argued that because certificate lifecycle processes are used for all (issuing) CAs of the TSP you can't partially audit an CA as Logius indicated. This wasn't communicated to or checked with Logius and due to human error wasn't spotted by Logius when the audit statement was handed over for the year 2017/2018. Notwithstanding the error in logic made at that time by Logius and CIBG, the majority of the areas involving the CA in question should have been audited and as such, the TSP CA should have been listed on the audit statements (with an asterisk/disclaimer). By the time this issue was discovered by Logius it was too late to amend the 2018/2019 audit to include the CA in scope (although admittedly that wouldn't have helped the earlier issue with the 2017/2018 audit).
15-1-2020 creation of this bug. Our original intent was to post at the same time as bug 1605126 but due to internal discussions (with CIBG) we didn't make that deadline. The delay was made worse by the holiday period with absence of key personell on both Logius and CIBG's side.
- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
See bullet 2. Issuance of certificates by the CA “UZI-register Medewerker niet op Naam CA G21” was stopped in June 2017
- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
The CA in question (https://crt.sh/?id=12715989), although not technically constrained, only issued S/MIME certificates (which, for obvious reasons, are not CT logged), The audit period concerned is from Q3 2017 to the present. Currently, only ~250 certificates are still valid.
- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
See answer 4. Logging is not an option because of GDPR concerns, but we could provide a list of hashes if needed (working on that now).
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
See also our answer listed at question 2 and the reasons listed in bug 1578809. At the time Logius was too much focused on the eIDAS/ETSI domain and not taking into account browser requirements with regards to audit. As also indicated in bug 1586125 Logius made some logic errors in the analysis of the “technical” capabilities of a CA to issue certain kinds of certificates (the CA in question was decomissioned but not revoked). Also, the focus at that time(2017/2018) was too much on the then new G3 TSP CAs instead of the legacy CAs which were in most cases still issuing valid certificates.
- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
All remaining certificates will be revoked before February 17, 2020. The CA in question The CA in question will be revoked after that, but at the latest at February 24, 2020 . Unfortunately, this can't be done earlier mainly due to the fact that the certificates issued by the CA in question are issued on a SUD (smartcard) which takes some time to replace. Since the new certificates are issued by a new G3 CA for which the issuance process has changed slightly (mostly the forementioned Organizationidentifier subject field) this also causes some delay due to the way some healthcare organizations are set-up.
As indicated in bug 1578809, our Overview of Applicability template will contain in its next iteration an overview of the CAs in scope of an audit, including their details (fingerprint, validity dates etc). This way, Logius, the TSP and the auditor can all see if the audit has all the CAs in scope. Part of that overview will be as well for which type of audit the issuing CA in question will be audited (ETSI 411-1 or 411-2, but also for which policy, e.g. NCP, NCP+, EVCP etc).