On Thu, Nov 12, 2020 at 10:51 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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. > I'm afraid this misunderstands things. I want it to be explicit whether or not a CA is making a restrictive set or not. That is, it should be clear if a CA is saying "We will only accept these specific methods" or if the CA is saying "We will accept these methods, plus any method at our discretion". It's very easy for a CA to be transparent about the latter, and is no different than the so-called "any other method" that was 3.2.2.4.10 in the BRs. The problem with the updated language from Ben is that it makes it indistinguishable whether or not the CP/CPS disclosed method is a complete set (i.e. that the CA will reject a reported compromise because it fails to meet their preferred method) or not. The fact that there can be "secret" documents which could say "We'll accept anything at our discretion" or that it could be empty is a problem. You seem to be taking it as if the CA has to provide exhaustive technical details for each method. That's not the case. They need to disclose the minimum (which might be "we accept anything at our discretion if e-mailed to us"), but with the original language, they would functionally need to disclose whether or not they will *reject* something not on that list, and the proposed revision removes that. > > 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. I encourage you to make use of PACER/RECAP then. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
