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.
2019-07-05, 04:29 UTC: Internal quality assurance noticed the error 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. 2019-07-05, 04:29 UTC: Internal quality assurance noticed the error / Start Incident 2019-07-05, 04:45 UTC: Issuing stopped 2019-07-05, 06:30 UTC: Start investigating the error 2019-07-05, 09:00 UTC: Short-term measures are identified to prevent further errors. Bringing the measures into effect and training the validation team. Correction of certificate request. 2019-07-05, 10:10 UTC: Issuing restarted 2019-07-05, 10:35 UTC: Production of the certificate 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. CA has stopped the production after detecting the error. Production was resumed after corrective action was taken. 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. No certificates were affected but only precertificates for one certificate. 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. https://crt.sh/?id=1638856360 https://crt.sh/?id=1638856369 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. In order to avoid incorrect certificate issuance, various automated checks were implemented. These have also successfully prevented the creation of a real SSL certificate. These checks were carried out with good intention as close as possible to the actual production time in order to detect any errors in the processing. However, this procedure can result in incorrect precertificates. In the specific case, the OrganizationalUnitName field of the subject was more than 64 characters. 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. We have realised that we also want to prevent the production of defective precertificates in the future. To this end, we will reassess the timing of the implemented checks from this perspective and add additional checks. Until then, additional manual testing measures have been established and the validation team has been trained. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
