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. Microsec became aware of the problem from the new discussion at the mozilla.dev.security.policy https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/jRKOr4nvOfY
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-10-02 2 precertificates were issued for internal testing purposes with short validity 2020-03-10 Microsec was informed about the faulty precertificates 2020-03-10 Microsec checked the faulty precertificates. They were already expired, so revocation was not possible. 2020-03-10 Microsec decided to immediately stop issuance of IVCP certificates until all corrective measures are in place, to prevent similar mistakes in the future 2020-03-10 Microsec decided to develop the CA software by adding further controls regarding the required fields of IVCP certificates to guarantee compliance with the certificate profile in the future 2020-03-13 Microsec deactivated all the IVCP profiles in the CA software to prevent issuance of IVCP certificates until the controls in the CA software are in place 2020-03-13 Microsec opened this incident report 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. Two subordinate CA were affected. They haven’t been stopped, but the issuance of IVCP certificates has been suspended by informing the RA operators about the decision and by deactivating all the IVCP certificate profiles. 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. There are 2 certificates involved. They were issued on the same day which was 2019-10-02 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. The problematic certificates are: https://crt.sh/?id=1947655126&opt=zlint,ocsp https://crt.sh/?id=1947655112&opt=zlint,ocsp 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Microsec made an investigation and could find the following: - the certification policy and practice statement contain the proper requirements regarding the content of the IVCP certificates - the problem was caused by human mistakes, the RA operators could not recognize the missing data - the CA software presently does not have automatic controls to check for the existence of the required fields in case of IVCP certificates - the certificates have been checked by cablint, but cablint did not indicate this fault - the certificates have never been published and used, so the fault has not been discovered until now 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. Microsec decided the following measures to avoid having the same problem in the future. - the problematic precertificates were issued for short period and have already expired, so revocation is not necessary - suspended the issuance of the IVCP certificates with immediate effect - decided to develop the CA software to add further controls and checks in case of IVCP certificates - no deadline has been set due to the COVID-19 situation - decided to hold a training about the required IVCP profiles for the RA operators before enabling the issuance of IVCP certificates again - the issuance of IVCP certificates may be continued only after the successful testing of the upgraded CA software - Microsec will check all the issued IVCP certificates looking for similar issues - deadline 2020-03-20 - Microsec will review the CA software looking for possible similar problems - deadline 2020-03-31 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
