On Sun, Jan 21, 2018 at 4:00 PM Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
> On Sun, 21 Jan 2018 12:09:23 -0800 (PST)
> Ryan Hurst via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > We maintain contact details both within our CPS (like other CAs) and
> > at https://pki.goog so that people can reach us expeditiously. In the
> > future if anyone needs to reach us please use those details.
> I just tried to see what I'd do if I wanted to report issues with
> Google's CA (assuming I don't know where its webpage lives and assuming
> I don't know any Googlers to report this directly).
> When I look into the cert details the certificates for Google webpages
> are issued by
> "Google Internet Authority G2"
> If I goole for that I end up at
> https://pki.google.com/
> This page has a similar style as the pki.goog, but notably it doesn't
> list any contact info. It has an FAQ, but that doesn't have any
> question of the form "How do I report a problem with your CA?"
> The only thing that might be helpful is a pointer to report security
> incidents. I'd probably have done that, though I would be unsure, as
> it's debatable whether an offline OCSP counts as a security issue.
> Meta-comment:
> 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.
> 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".)

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.

dev-security-policy mailing list

Reply via email to