Hi
This is an incident report for two intermediate certificates issued by Buypass in December 2016 noncompliant with BR 7.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. We were following a discussion on mozilla.dev.security.policy (MDSP). On March 18th a list of CAs noncompliant with the entropy requirement in BR 7.1 was published and two Root CAs from Buypass was included. We became aware of this on March 21st and sent immediately a Pre-Incident Report to MDSP [1]. ===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. We did some analyses and identified that we had issued two intermediate CA certificates on December 2nd 2016 without the required entropy in the certificate serial number. At this point in time, the application software on our offline Root CA system did not support the inclusion of random values in the certificate serial number. ===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. The application software on our offline Root CA system was later updated with support for random values in certificate serial numbers. No more intermediate certificates was issued in the meantime and we have since then not issued any certificates noncompliant with BR 7.1 on the offline Root CA system. ===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. Two intermediate certificates were issued December 2nd 2016. The intermediate certificates are used for CAs issuing TLS certificates, i.e. Buypass Class 2 CA 2 and Buypass Class 3 CA 2. ===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. The two certificates are: - Buypass Class 2 CA 2 - https://crt.sh/?id=76748940 - Buypass Class 2 CA 3 - https://crt.sh/?id=76740810 ===Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. This entropy requirement was effective from September 30th 2016. At this point in time we were not very concerned about the risk of using certificate serial numbers with low entropy in certificates issued in our Root CA system [2]. The Root CA system is operated offline/airgapped in a strictly controlled environment by three security officers. Therefore, we focused on implementing support for the entropy requirement in Subscriber certificates. At the time we issued the intermediate certificates, in December 2016, our Root CA system did not yet support random values in the certificate serial number. ===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. The following actions has been taken: - On March 25th we issued two new intermediate certificates for the affected CAs with certificate serial numbers compliant with BR 7.1 on the offline Root CA system - These certificates replaces the two affected intermediate certificates and are distributed to our customers together with all new TLS certificates issued after March 25th We have identified the next actions to be taken: - We will communicate with existing customers and advise them to replace the affected intermediate certificates with the new intermediates - We will revoke the affected intermediate certificates when the risk of introducing any main issues to our customers are considered to be acceptable The offline Root CA system used has been updated and it will not be possible to issue certificates noncompliant with BR 7.1 in the future. Regards Mads [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/n1_sDXBmF_A/yQEz_kQ6BwAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/3avqmSF4MVU/9MV5b2zGAQAJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
