1.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.
On November 30, 2018, we posted an ETSI audit for KPN with the audit deficiencies. In absence of getting a complete audit, this report was posted to confirm completion of an audit by KPN. On January 20, 2019, DigiCert received outdated Audit alerts from CCADB reporting for KPN CAs. Internal discussion occurred to confirm the notification list with audits posted already to CCADB and details of the audit report posted.
2.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.
30-Nov-2018 KPN ETSI Audit posted in CCADB (report was issued on 2018-09-13)
20-Jan-2019 CCADB Outdated audits notifications sent to DigiCert included KPN CAs.
01-Feb-2019 DigiCert internal call to discuss missing CAs based on outdated audit notifications from CCADB.
02-Feb-2019 Email raised with KPN regarding missing CAs from Audit.
06-Feb thru Audit reviewed internally by DigiCert and follow up communications
13-Feb-2019 with KPN over email.
15-Feb-2019 KPN sent reply requesting a call to discuss the audit issues for the following week (they were not available for over a week due to primary contact out on leave).
28-Feb-2019 DigiCert / KPN conference call to explain deficiencies found in audit and reinforce policy requirements.
6-March-2019 KPN came back with a response after communicating with their ETSI auditor (BSI) to request extending the scope to cover the missing CAs in their audit. Due to limited availability by their ETSI auditor and challenges with extending their audit year scope from prior year, they stated it was not feasible for BSI to update their audit.
8-March-2019 DigiCert requested to make contact directly with BSI.
12-March-2019 No response from KPN on BSI contact; another request for follow up with BSI sent.
14-March-2019 DigiCert contacted KPN and gave them 7 days to produce a compliant audit and warned of public incident report to be raised.
15-March-2019 DigiCert / KPN conference call to discuss their remediation plan – amongst the area of rectification discussed was to engage a new auditor (KPMG for Webtrust) to address the concern with availability of ETSI auditor in the Netherlands.
18-March-2019 KPN authorized revocation of 3 ICAs on the list that were no longer active.
19-March-2019 3 CAs for KPN revoked and CRLs posted.
22-March-2019 KPN produced an audit engagement letter with KPMG but was marked Confidential and had corrections needed; DigiCert requested corrections.
23-March-2019 DigiCert sends an email demanding an audit engagement letter to be released to Mozilla community with corrections as part of an incident report.
25-March-2019 KPN furnishes another version of KPMG engagement audit letter that is releasable to Mozilla community. DigiCert sends another set of corrections on the scope letter. We will post the corrected audit engagement letter once received.
3.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.
We have not revoked the remaining CA’s that will be audited by KPMG. The set of CA’s that are on the outdated audit list is expected to be covered in a Webtrust audit to be completed by end of May 2019. Three of the CAs on the list were no longer issuing and had no valid certificates and were revoked on 19-March-2019.
4.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’s for KPN that have outdated audits and number of active certs with EKUs are listed below.
*ABN AMRO CA - G2 – 247 active certs – EKU constraints: emailProtection, clientAuth
*ABN AMRO CA - G2 – 785 active certs – EKU constraints: emailProtection, clientAuth
ABN AMRO TEST CA G2 – 5 active certs – EKU constraints: emailProtection, clientAuth
KPN Class 2 Managed PKI Individual Subscriber CA 2016 – 22 active certs – EKU constraints: emailProtection, clientAuth
*Philips Extranet CA G4 – 33 active certs - EKU constraints: emailProtection, clientAuth
Shell Information Technology International CA - G3 – 12,768 active certs - EKU constraints: emailProtection, clientAuth, encryptedFileSystem
*These CAs represents recertified instances that may appear in multiples in CCADB. Only one version of the CA can be loaded to the account at one time. There is one issuer per account relationship in the platform and the body of the certificates in the account gain trust from any of the N recertified issuers.
5.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.
Please see 4) above.
6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
An ETSI audit was provided by KPN to DigiCert after their audit completed. The scope of their audit report was for a PKI that did not include the CAs issuing under our roots. (Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1435815)
7.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.
Going forward, we are requiring all CAs cross-signed or having an external intermediate to share their auditor engagement letter with DigiCert in advance so we can review the scope prior to them signing and starting the audit engagement. We want the engagement letter to specifically list the CAs that are being audited and require the auditor to list the CAs in the audit report.
Overall, we have seen inconsistencies in audit reporting, including missing a level of detail that Mozilla’s policy requires. This is also the level of detail that would provide assurance to the relying parties (including us as the Root CA) that their audits are adequately covering the relevant scope. We have asked for corrections on audit final reports with missing thumbprint information, CA’s or audit periods covered. We believe engaging the auditor (whether ETSI or WebTrust) as part of the initial engagement process would avert issues that we have been finding after the reports are issued.