Thank you for the incident report. I have created a bug for tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=1528290
- Wayne On Fri, Feb 15, 2019 at 7:21 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > (Sending from the right e-mail) > > On Fri, Feb 15, 2019 at 8:05 AM info--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi, this is the incident report: > > > > 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 have controls to detect any misissuance before and after the issuance > > of the certificate. The certificate was issued at 11:52, detected in the > > following minute, and revoked at 12:07 > > > > 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. > > > > Feb 14th 11:52 -> the certificate was issued > > Feb 14th 11:53 -> the misissuance was detected > > Feb 14th 12:07 -> the certificate was revoked > > Feb 14th 13:28 -> reported the incident to our PKI software manufacturer > > Feb 14th 15:24 -> received the answer from the manufacturer. They tell us > > that there’s a bug in the preventive filter with the OU, and that they > have > > a hotfix to solve it. > > Feb 14th 17:21 -> Izenpe reports to mozilla.dev.security.policy list > > > > 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. > > > > We’ll do a dual manual check until we have the hotfix correctly applied > > > > 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’s just one certificate affected > > > > 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=1202714390 > > > > 6. Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > It was a bug in the filter of the PKI software > > > > 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 hope to have the product hotfix applied by March 3rd > > > > Thanks for providing the additional details. However, I largely don't think > this meets the bar for the necessary level of detail - with the exception > of the timestamps and the remark your vendor had a bug, we've not really > learned anything about what went wrong or how to effectively prevent it. > > Please work with your PKI software manufacturer, if necessary, to provide a > more substantive incident report - understanding when the bug was > introduced, what the bug is and how it functions, and how it's being > hotfixed, are all areas that are key to understanding how we can better > apply this knowledge across the CA ecosystem. > > If you're not sure what an 'necessary' level of detail looks like, please > consider something like > > https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/W1D4oZ__BwAJ > , > listed as the "Good Practice" examples in the > https://wiki.mozilla.org/CA/Responding_To_An_Incident > > Consider that it was stated that controls exist before and after issuance, > and yet it was still issued - this suggests the controls before issuance > are faulty. > Consider that we don't have details about what preventitive filters exist > or are configured, how they're supposed to work, how they failed to work, > and how the hotfix is meant to correct these issues. > > I do want to acknowledge that it *is* good that y'all proactively detected > post-issuance and filed a report - this is absolutely what CAs should be > doing, and I'm glad to see Izenpe doing this. I similarly don't want to > discourage reporting as information comes in - I think that the details > provided are a good example of an 'interim' report in which the CA > continues to provide updates and transparency to the community while they > gather information. However, I don't think it represents a good 'final' > report - there's nothing of substance here other than "We found a problem > and fixed it". The goal of these is to understand the problem in > substantial technical detail, so that we can understand how the fixes will > address, and so that the community at large can be aware of systemic risks > or patterns and ensure that, regardless of what PKI software they use, so > that the ecosystem can itself improve. > > Please continue to provide more details regarding this incident > _______________________________________________ > 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
