On Thu, 12 Nov 2020 15:51:55 -0500 Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> I would say the first goal is transparency, and I think that both > proposals try to accomplish that baseline level of providing some > transparency. Where I think it's different is that the concern > Dimitris raised about "minimums", and the proposed language here, is > that it discourages transparency. "We accept X or Y", and a secret > document suggesting "We also accept Z", makes it difficult to > evaluate a CA on principle. [...] > Yes, this does mean they would need to update their CP/CPS as they > introduce new methods, but this seems a net-positive for everyone. I think the concern about defining these other than as minimums is scenarios in which it's clear to us that key compromise has taken place but your preferred policy forbids a CA from acting on that knowledge on the grounds that doing so isn't "transparent" enough for your liking because their policy documents did not spell out the method which happened to be used. The goal of this policy change is to avoid the situation where a researcher has one or more compromised keys and, rather than being able to quickly and securely set in motion the process of revoking relevant certificates and forbidding more being issued they end up in a game of telephone (perhaps literally) with a CA because its policies are unclear or unworkable. You seem to anticipate a quite different environment in which "secret documents" are used to justify revocations which you presumably see as potentially illegitimate. I haven't seen any evidence of anything like that happening, or of anybody seeking to make it happen - which surely makes a Mozilla policy change to try to prevent it premature. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
