I have created bug #1622539 to track this issue. - Wayne
On Fri, Mar 13, 2020 at 3:09 PM Sándor dr. Szőke via dev-security-policy < [email protected]> wrote: > 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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
