Wojciech, Thank you for the incident report. I believe it does a good job of explaining how you will prevent this specific problem from happening again, but it does not address the broader problem of misissuance and Certum's failure to detect it. How can the Mozilla community be assured that Certum will detect and prevent all types of certificate misissuance in the future?
- Wayne On Wed, Oct 10, 2018 at 8:03 AM Wojciech Trapczyński via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Please find our incident report below. > > 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. > > From Bugzilla bug 1495518 created by Wayne Thayer on October 1 2018 at > 18:42 GMT. > > 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. > > Oct 1, 2018 18:42 GMT - The Bugzilla bug 1495518 was created. > Oct 2, 2018 - We analyzed this case and found the reason for > misissues. We started to prepare the fix. We found all affected > certificates. We informed our customers about this bug and necessity to > revoked certificates. > Oct 3, 2018 12:00 GMT - We deployed fix on production. > > 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. > > Oct 3, 2018 at 12:00 GMT. > > 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. > > Total number of affected valid certificates: 43. All certificates, > except two, already have been revoked. These two certificates will be > revoked by the end of this week. > > 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. > > In attachement. > > 6. Explanation about how and why the mistakes were made or bugs > introduced, and how they avoided detection until now. > > We did not properly choose the profile name for certification request > with EC public key in our software. Instead of choose EC profile where > Key Encipherment value in Key Usage extension is disallowed we choose > RSA profile where Key Encipherment value in Key Usage extension is > allowed. The bug was not found by our tests suite because we did not > have scenario for such case. > > 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 fixed our software. Now, if a certification request contains > EC public key only EC certificate profile is allowed to use. > - We have added the appropriate test case. Now, for every software > release we check that appropriate profile is chosen for given type of > public key. > - We have added an additional protection at the certificate profile > level in the CA issuing system. Now, the CA system for issuing > certificates will block the issuance of the certificate if it receives > unmatched combination of public key and profile. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
