On Fri, 13 Nov 2020 21:06:30 -0500 Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> Right, I can see by my failing to explicitly state you were > misunderstanding my position in both parts of your previous mail, you > may have believed you correctly understood it, and not picked up on > all of my reply. To the extent your preferred policy is actually even about issue #205 (see later) it's not really addressing the actual problem we have, whereas the original proposed language does that. > Yes, you're absolutely correct that I want to make sure a CA says "any > method at our discretion", but it's not about humiliation, nor is it > redundant. It serves a valuable purpose for reducing the risk of > arbitrary, undesirable rejections, while effectively improving > transparency and auditability. This boilerplate does not actually achieve any of those things, and you've offered no evidence that it could do so. If anything it encourages CAs *not* to actually offer what we wanted: a clearly documented but secure way to submit acceptable proof of key compromise. Why not? It will be easier to write only "Any method at our discretion" to fulfil this requirement and nothing more, boilerplate which apparently makes you happy but doesn't help the ecosystem. > But equally, I made the mistake for referring to PACER/RECAP without > clarifying more. My reply was to address that yes, there is the > existence of "potentially illegitimate revocations", but that it's > not tied to "secret" documents (which you misunderstood). And my > mistake in not clarifying was that the cases weren't addressed to the > CA, but related to a CA subscriber. You can read more about this at > https://www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml > Here, this is about revocations that harm security, more than help, > and you can read from that post more about why that's undesirable at > https://medium.com/@mattholt/will-certificate-authorities-become-targets-for-dmca-takedowns-7d111275897a We're in the discussion about issue #205 which is about proving _key compromise_ If you believe Mozilla should write policies requiring CAs to resist certain types of legal action this ought to be a separate issue. I might even have positive things to say about that issue, and perhaps some CA participants do too. I was not able to discover what revocation reason was actually used in the incident referenced, do you have copies of the signed OCSP response or CRLs related to the Sci Hub revocations or similar incidents? Otherwise I have to assume Key Compromise was not given as the reason for these revocations and so this has nothing whatsoever to do with issue #205 and you've hijacked an unrelated discussion. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
