On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi <[email protected]> wrote: > > On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < > [email protected]> 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 > > Thanks for the reference. I would note that Microsoft's requirements appear to be much narrower in scope, applying to "Security Incidents" as defined in section 6. Having said that, are there specific requirements that we should consider adding to Mozilla policy?
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? > > I would be interested in everyone's opinion on this. While I agree that Bugzilla is a necessary mechanism for tracking incidents, I believe that it reduces community visibility and makes it more difficult for most members to follow incident discussions. It has been suggested that we create a process that automatically publishes a summary of new or updated incident bugs to this list on a periodic basis, but that obviously isn't yet in place. Even with that, I might argue that the requirement should be to publish incident reports to m.d.s.p., with a bug then being created by the CA or a Mozilla representative. 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? > > Either as part of an incident report or an annual disclosure, I don't feel that this information would be terribly valuable in most situations, and where it is we can ask for it. Would anyone like to speak in favor of this change? 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
