(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
