Hey Matt, Sorry this e-mail went unanswered. I was updating my mail filters today and noticed it had been missed.
On Thu, May 7, 2020 at 8:03 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This has happened twice now, with two different CAs, so I'm going to raise > it as a general issue. > > I've had one CA reject e-mails because the HELO name wasn't to their liking > (which I was able to fix). The other, which has just started happening > now, > is utterly inscrutible -- "550 Administrative prohibition - envelope > blocked". Given that the envelope sender and recipient hasn't changed from > the numerous other problem reports I've sent over the past month or so, I'm > really at a loss as to how to proceed. > > Questions that arise in my mind: > > 1. To what extent is it reasonable for a CA to reject properly-formed > e-mails to the CPS-published e-mail address for certificate problem > reporting? > I don't know if I have a good answer for this. I think from your own reporting, we've now seen a variety of responses from CAs - e.g. "antivirus that prevents e-mailing CSRs" is still a ... rather surprising behaviour that I don't know we've got a good hard-and-fast rule for. As you know, to date, Mozilla has so far declined to make e-mail reporting mandatory for CAs to support, precisely because of the complexities of specifying a policy that is loophole free. At the same time, we're seeing a telling trend of CAs restricting submissions for certain problem reports to only particular mechanisms, and I think that's equally troubling: CAs are placing barriers for reporters that, I believe, straddle the border if not outright cross it of unreasonable burden. Which I guess is to say "we'll take it on a case by case basis", and look for opportunities for improved policies based on the hurdles that problem reporters face. > 2. What is a reasonable response from a problem reporter to a rejected > problem report e-mail? > I would say bringing it here and/or in a CA incident. Ultimately, both Root Program policies and the Baseline Requirements themselves are improved based on experience and challenges faced. Knowing the challenges faced by a problem reporter help us improve the policies. > 3. In what ways are the required timelines for revocation impacted by the > rejection of a properly-formed certificate problem report? > This is part of the challenge here. If we applied the logic a number of CAs did during the CA/Browser Forum voting discussions (which lead to Bylaws reform), we know that several CAs view the act of contacting a mail server, even if it does not accept the message, as sufficient notification. Of course, by Bylaws were clarified to take a less extreme position, of confirmed receipt/acceptance. I would say the answer is that this is case-by-case. CAs that place burdensome barriers to receive reports of key compromise and/or misissuance are, unquestionably, not acting in the public interest. However, there are legitimate challenges. I think the best answer is treating these as incident reports, and allowing the CA to provide their explanation and rationale, and either treating it as a BR-violation incident or closing as WontFix/Invalid, depending on the depth and quality of the CA's report and the steps they take in response. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
