On Sun, Jan 21, 2018 at 2:14 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > > I think the whole CA incident reporting question has lots of room for > > improvement. And I think this should be considered in a way that people > > who are not familiar with the details of the CA ecosystem can > > successfully report incidents. I.e. saying "you can find all the > > contact info in our CPS" is not particularly helpful, as nobody outside > > a small circle of people knows what that is. > Even if a relying party looks for the problem reporting mechanism in the CPS, they are unlikely to find it. The only requirement is "The CA SHALL publicly disclose the instructions through a readily accessible online means" in BR 9.4.3. From my observations, many CAs do not place this in their CPS, and almost none equate the requirement to "easy to find". > I think if people try the "natural" way of contacting a certificate > > issuing entity this should lead to a successful outcome. (And that is > > more or less "This has been issued by X, so I try to contact X".) > > The "natural" way is likely to be some generic support email address that receives thousands of emails a day and is subject to the problems Ryan describes below. Maintaining a 24-hour response time for any email address a relying party might find is not compatible with the requirement for a timely response. > > To be honest, I think I find myself agreeing with other CAs when I question > whether that should be or necessarily is a goal. > > If you’ve been on an inbound bug queue for virtually any product > (particularly popular ones), you will be amazed at the (lack of) quality > reports. Just search the Mozilla or Chromium bug trackers for “my computer > has been hacked” to see a variety of bugs from people most likely suffering > from one or more mental disorders, unfortunately, to see how bad it can be. > > Add to that the complexity of PKI, and the contractual obligations of > responsivess, and t becomes quite different. Talk to existing CAs that > provided email links to problem reporting mechanisms (prior to Mozilla’s > requiring they do so) and hear about the spam. I know of problem reports > from Google to other CAs that have similarly been caught by the spam > filters designed to ensure high signal. > > Combined with the spectrum of technical acumen we see, even here, or > through contributions from Interested Parties to the CA/Browser Forum, and > I suspect that highlighting even more the reporting mechanism is to vastly > increase the noise, rather than the signal, and thus do more harm than > good. > > Normalizing problem reporting - meaning that reporters have to do more work > to align their reports into actionable data - conversely increases the > barrier to submission but reduces the barrier to action. Is it an equitable > tradeoff? It may be. > > Something to ponder, however, as easier does not necessarily mean better. > > This is a good point, but easier doesn't necessarily mean worse either. I propose that we add a requirement that makes the reporting mechanism more consistent and easier to find (e.g. clearly labeled so that a search for "google CA problem report" gets me there). Allow the reporting mechanism to be flexible so that a CA can, for example, use a form with a captcha to collect the report. I don't know if we need to specify "better" by normalizing the mechanism or information that is gathered, but I'm also not opposed. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
