On Fri, Nov 13, 2020 at 6:11 PM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
> > > On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote: > > > > 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. > > > I understand the proposal to describe a different thing. Your proposal to > accept an email, is a different requirement, which is "how to communicate". > I think the policy change proposal is to describe the details about what is > expected from third-parties to submit in order to report a key compromise. > Whether via email, web form or other means, I think this policy update > covers *what* is expected to be submitted (e.g. via CSR, signed plain text, > the actual private key). > Right, and that is what I meant as well. My point was the "we'll work it out with you" being about explicitly stating an *open-ended what*, while discouraging CAs, by making it detectable during CP/CPS reviews, of intentionally choosing to *reject* any what they don't like. If a CA doesn't state an open-ended what, it could mean that their plan is to do exactly that, which would be bad, or it could just mean they forgot, which is easily fixed, but also a warning sign. > > 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. > > > I think one of us has misunderstood the policy update proposal. I believe > that what you describe is already covered by the existing policy which > states that the CA must disclose *how* they accept requests (via email, > API, web form, etc), disclosed in CPS section 1.5.2. > No, I think like above, I may have chosen an unclear example, but I think we understand it the same. "Convoluted API ... at the lunar equinox" was trying to cover both the how it's delivered and the method of proving it, but I can totally see now that it might be perceived as just the how it's delivered, which wasn't the intent. I'm talking about the "what method of demonstrating proof is accepted". That covers both the how it's delivered and how it's demonstrated, and as I went into further with Nick, my goal is to make sure "X, Y, Z" are listed in the CPS, and not some side-doc that may or may not be audited and may or may not be disclosed. The problem with the "minimum" approach is that it doesn't adequately make clear that the "listed in a side doc" is one of the several problems to be solved, with the goal being to bring it into the CP/CPS. Having just the minimum required would still encourage CAs that go above and beyond the minimum to put it off in a side doc, when the goal is to get it into the CP/CPS, for reasons I expanded on to Nick. I think you took it as discouraging a CA to go "above and beyond the bare minimum", which I agree with you, that would be bad to discourage. But I want CAs to be clear when they do go above and beyond the minimum, and to be clear that they also recognize it's important to do so, since the minimum is just that: the minimum. The minimum isn't meant to be "This is how you should operate daily", but the "You should be better than this regularly, but you absolutely cannot regress this threshold", and having CAs explicitly state that they expect to constantly be improving (by accepting other methods), helps show they understand that, as I think you're arguing for here. > 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. > > > If people consider that the original language is unambiguous and will > prevent an auditor to interpret this as "you have stated specific technical > method(s) for a third-party to demonstrate a key compromise, therefore > these are the only methods you must accept otherwise you are violating your > CP/CPS", then I'm fine. > Yes, I agree with you, we want to prevent that scenario. I believe it's possible to do, with the original language, but this requires the CA to proactively take steps to address that in their CP/CPS. That is, I think it'd be reasonable for an auditor to conclude that, if a CA stated "We do X, Y, Z" in our CP/CPS, then doing "A, B, or C" without it being listed in their CP/CPS first would be an issue. I believe that is the concern you're raising, if I understood you correctly. The way to address that, and what I think is a good goal, is to get it to be "We do X, Y, Z, and any other method", ideally, when CAs make the update in response to the new policy. As situations come up on a case by case basis, the CA can deal with the issue without any update required first. If any CA updates their CP/CPS without also adding "and any other method" in response to the new policy, we can then clarify whether they're intentionally stating they'll reject anything, or whether it was an oversight, and like you, they want extra flexibility because they want to go "above and beyond" as needed. However, I also want to make sure that any formally accepted method of proof is documented in the CP/CPS. So if the CA formalizes A and B as routine operations, they will update their CP/CPS to state "We do X, Y, Z, A, B, and any other method". This makes it clear which are the guaranteed methods they promise to accept, as well as that exceptions are recognized as necessary, and they will be accepted and dealt with. I'm not trying to require every CA do A and B, but my worry with Ben's modified language is that a CA will decide to accept A and B as a general rule, but not ever add that to their CP/CPS, since the policy would explicitly allow/encourage this scenario. While this is more likely accidental than a sign of nefarious intent, it happens enough for me to be wary about something being seen as encouraging it. By having *one* place for a CA to document *everything* they do or plan to do, specifically their CP/CPS, it makes it easier to review the CA and what they claim to do. Additionally, it makes it easier to recognize when a CA is going above and beyond, by highlighting when one CA only does X, Y, Z, while another does X, Y, Z, A, and B. CAs should totally be looking at eachother's CP/CPSes and trying to learn about good ideas, whether things like validation or, in this case, compromise handling. We already see this with incident reports being valuable information sharing for the industry, like Entrust's recent report about customer's attaching private keys to CSRs, and CP/CPSes should equally be a source of good practices for the industry. Thus, this helps up evaluable which CAs are being industry leaders and doing good things, and which are just trying to skate by with the minimum. From those leaders, we can learn about good new methods, like A and B, and we can look to require them for all CAs. So it's wins all around, but we only get their by making sure it's in the CP/CPS. And yes, I do acknowledge there's a risk that if CA Foo does X, Y, Z, A and B, while CA Bar does X, Y, Z only, then Foo might be tempted to *stop* doing A and B to cut costs. But I think we still have enough CAs that are truly motivated by being pro-security, rather than trying to cut costs, that even if some CAs are tempted to be lazy and as cheap as possible, there will be positive model CAs next to them, and the comparison would highlight who is a "good" CA and who is a "bad" CA. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
