On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi <r...@sleevi.com> wrote: > > On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer <wtha...@mozilla.com> wrote: > >> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi <r...@sleevi.com> wrote: >> >>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy < >>> dev-security-policy@lists.mozilla.org> wrote: >>> >>>> **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? >> > > There are two things that stand out to me that are unclear if you meant to > incorporate by reference to the incident report: > - Whether it's a policy violation if the CA fails to disclose the affected > certificates, which MSFT policy explicitly requires >
We would only want this if the certificates were disclosed publicly, and that seems challenging. TLS certs will, of course, be logged because of other UA's requirements, but for email certs CAs may not have the contractual right to disclose publicly. And "GDPR". - What, if any, timeframe for periodic updates. MSFT policy explicitly > states that MSFT shall determine the update cadence. (This may be a > non-issue) > > Conceptually this makes sense, but I would be interested to hear your thoughts on what our requirement should be? A one-size-fits-all requirement of something like weekly updates could be an enforcement nightmare. We already assume the right to set deadlines for responses, so it's not obvious to me what we'd want in this requirement. Additionally, in further consideration of both this proposal and the > highlighted difference, it's unclear whether it's intended to create a > hierarchy of incidents. I think the language, as worded, does - perhaps > inadvertantly - by mentioning misissuance vs a procedural or operational > issue. > > Consider, for example, a CA that determines they're copying the O field > directly from CSRs into the final certificates. Such certificates are > unquestionably misissued, but the language creates the opportunity that the > CA would argue it's a "procedural or operational" issue, and thus they're > not required to cease issuance until the problem has been prevented. > This language was cribbed from the wiki page: "In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done" Perhaps it shouldn't try to account for things like OCSP misconfiguration and only state: "CAs SHOULD cease issuance until the problem has been prevented from reoccurring."? > > 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. >> > > I do share those concerns, hence the attempt to split it in the middle. > > My concern is that there have been several high-profile incidents which > have been discussed in m.d.s.p., in which very relevant questions from > members of the community go ignored, perhaps deliberately, and it becomes > difficult to track in all of the discussion what those points were. > However, I suppose the same issue may similarly exist if tracking the > discussion through Bugzilla. This suggestion may end up being orthogonal to > the policy update question, but it's one largely motivated by wanting to > either make sure CAs are aware of the need to respond to questions - or to > make sure that it's accurately noted when CAs ignore or otherwise fail to > do so. > I'd like to create a separate issue to track this proposal and continue to work out the best solution rather than combining it with the relatively easy question of "should we require incident reporting in policy". _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
