Hi Wayne,
This is how its supposed to work under eIDAS:
1. Check the value of the QCStatement [1] of the certificate under
problem (which is the location of PDS);
2. Open the PDS and check relevant contact info as in [2].
Thanks,
M.D.
[1] see 4.3.4 (QCStatement regarding location of PKI Disclosure
Statements (PDS)) in ETSI EN 319 412-5;
[2] see Annex 1 (Model PKI disclosure statement) in ETSI EN 319 411-1.
On 1/22/2018 10:07 PM, Wayne Thayer via dev-security-policy wrote:
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
