On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> We currently expect CAs to deliver incident reports whenever they fail to > comply with our policy, but this is not a requirement of our policy. There > is no obvious place to add this in the existing policy, so I propose > creating a new top-level section that reads as follows: > > **Incidents** > > When a CA fails to comply with any requirement of this policy - whether > it > > be a misissuance, a procedural or operational issue, or any other variety > > of non-compliance - the event is classified as an incident. At a minimum, > > CAs MUST promptly report all incidents to Mozilla in the form of an > Incident > > Report <https://wiki.mozilla.org/CA/Responding_To_An_Incident>, and MUST > > regularly update the Incident Report until the corresponding bug is > > resolved by a Mozilla representative. In the case of misissuance, CAs > > SHOULD cease issuance until the problem has been prevented from > reoccurring. > > > For comparison, Microsoft's policy is https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident One thing to consider with such a policy is whether to formalize the use of Bugzilla to track these. In looking through incident reports that have been filed, we see a fair distribution between the initial reporting being on the email list vs Bugzilla. We've certainly seen Bugzilla be more useful in tracking unacknowledged questions and responses (via the use of Needs-Info). Would it make sense to require that the incident report be provided via Bugzilla, with a notification to the mail list? This is https://github.com/mozilla/pkipolicy/issues/168 > > It has also been proposed that we add a disclosure of the CA software being > used to the list of topics we expect an incident report to cover. [1] This > addition was proposed before the serial number entropy issue arose, so it > is more than a reaction to that specific issue. I propose adding the > following item to the list of incident report topics: > > > > > Information about the CA software used to generate the certificates. For > > COTS <https://en.wikipedia.org/wiki/Commercial_off-the-shelf> solutions, > > provide the name, vendor, and version of the software in use. For > > home-grown solutions, provide information about the architecture > including > > the name and version of relevant 3rd party components. > > > > This is https://github.com/mozilla/pkipolicy/issues/162 As one of the people most frequently exploring incident reports, I do not believe this will provide substantial value with respect to the incident reporting process. There certainly is an element of curiosity and applicability in the case of some bugs, but I do not believe it provides a particular value as a blanket requirement. My experience with such information is that it more commonly highlights when a CA may be failing to adhere to the NCSSRs or their auditor reaching a conclusion different from them, rather than being particular to the incident reports. Would it make more sense to consider this as part of audit reporting and disclosure? Namely, that the CA's annual disclosure MUST include such a disclosure? I do worry that, regardless of the method chosen, it will be difficult to determine whether or not it provides value. For example, given the open-source nature of EJBCA, a CA might disclose they use "Custom software", when in fact, all they changed was a single line of an EJBCA file to thus "customize it". We thus learn nothing 'useful'. Even in the cases where this was referred to (KIR S.A. and the serial number incident), the disclosure of the software would not have provided any new insight; EJBCA could have been configured to a more expansive serial number, and there were enough other issues re: KIR S.A. that the choice of CA software was hardly the high-order bit. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
