On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
> There is transparency that the CA has evaluated some reporting > mechanisms and these will be documented in the CPS. However, on an issue > like compromised key reporting, there is no single recipe that covers > all possible and secure ways for a third-part to report a key > compromise. Sure, and the original proposed language doesn't restrict this. The CA can still disclose "Email us, and we'll work it out with you", and that's still better than the status quo today, and doesn't require the CP/CPS update you speculate about. > For CAs that want to do the right thing with this flexibility, the > original language Ben proposed seems to be problematic, which is why I > highlighted it in the discussion. As above > The updated language keeps all the > "good" things from the original language, and allows the CA to accept a > reporting method that they may have not considered. Obviously, the > logical thing is that once this new method is accepted, the CPS should > be updated to include that additional method but that might take place > later, after the report was accepted and certificates revoked. > > I can't think of a bad scenario with this added language. > I addressed this in my reply to Nick, but for your benefit, the "bad" thing here is a CA that lists, in their CP/CPS, "We will only accept using our convoluted API that requires you to submit on the lunar equinox", and then states "Well, that's just the minimum, we have this doc over here saying we'll also consider X, Y, Z". The modified language fully allows that. The original language would see methods X, Y, Z also added to the CP/CPS. > This makes no sense to me. We're not discussing secrets here. Say a > third party reports a key compromise by sending a signed plaintext > message, and the CA has only indicated as accepting a CSR with a > specific string in the CN field. The updated proposal would allow the CA > to evaluate this "undocumented" (in the CPS) reporting method, check for > its credibility/accuracy and proceed with accepting it or not. > The original proposal also allows this, by saying exactly what you stated here, but within the CP/CPS. The modified proposal, however, keeps secret whether or not the CA has a policy to unconditionally reject such messages. You seem to be thinking the original proposal prevents any discretion; it doesn't. I'm trying to argue that such discretion should be explicitly documented, rather than kept secret by the CA, or allowing the CA to give conflicting answers to different relying parties on whether or not they'll accept such messages. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
