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 be very clear: "secret" document is not what you described, as a way for a CA to hide nefariousness. In the context of this issue, I'm talking about "secret" as in not part of the public commitments that can be examined via the CP/CPS, and that are visibility, transparently part of the audit. These are the "internal" documents that may or may not be audited (depending on the audit scheme and the auditor's interpretation; ETSI is less transparent here, but I'm sure they'll insist it's somehow the same). Think your training manuals, your internal policies for incident management, your policies on escalation or interpretations of the BRs (such as jurisdiction requirements), etc. They are things that are conceptually and logically part of a CA, and part of how a CA operates, but they aren't part of the externally documented set. Or, they might not be explicitly linked to some audit criterion that requires examining then; for example, change control management would be, but policies around lunch and break times are unlikely to be. My point is to bring them "into the CP/CPS". As I mentioned in my previous e-mail, although I can understand you might be confused because I did not clearly state I disagreed with you, the point is to make it explicit whether or not a CA is stating that they will *reject* anything they don't like. If a CA says "I accept X, Y, Z", and you send them "A", and they say "Sorry, we said we don't accept A, you decided to trust us anyway, boo hoo for you", they're not entirely wrong. That's exactly what audits and CP/CPSes are designed to make explicit. If the CA says "We accept X, Y, Z, and any other method", then if someone sends them "A", there's a presumption here of acceptance. If the CA decides to reject it then, they bear the burden and presumption of explaining their discretion, especially if it turns out to be a valid issue. Here, the presumption is on the CA to demonstrate why their judgement and discretion is trustworthy, knowing that if they rejected A without good cause, they will be viewed negatively. Equally, we can decide whether the new policy should ACTUALLY be "We accept X, Y, Z, A, and any other method" - making it clear the new minimum set. However, while you think it redundant, it actually provides a number of important details for CP/CPS reviews. For example, were a CA to omit "any method", it easily raises a red flag to ask a follow-up. We see these sorts of omissions all the time in CP/CPS reviews, particularly around domain validation methods (3.2.2.4). So we'll ask during the review, and the CA will say, "well, we go into more detail in this other document. Our auditors looked at it, and agreed it met the requirements, but we didn't put it in our CP/CPS". Now, the problem with accepting that answer is that you don't know whether or not they actually did go into that detail in the other document - we don't have it, and would have to ask for it. You can see this playing out in Incident Reports today, where we'll ask a CA to attach the old and new document (such as a training document, an architectural layout, a testing matrix), where we try to understand what's changing. However, we also don't know whether or not the auditor looked at that document as well; the CA's version of the audit report would show this, but the one we see does not. The benefit here is that by getting it into the CP/CPS, it clearly becomes part of the audit. It also becomes part of the CA's public commitments, and then we can see if they're changing operational behavior midstream. Either they updated their CP/CPS, and we see that they did in fact go through a change, or they changed behavior and didn't update their CP/CPS, which will get flagged in the audit. Both ways, we, the community, end up learning that something changed, and can review that change to make sure that change is aligned with what we want. 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. On Fri, Nov 13, 2020 at 8:12 PM Nick Lamb <n...@tlrmx.org> wrote: > On Fri, 13 Nov 2020 12:11:57 -0500 > Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > 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". > > I see this as essentially redundant. Any major CA which does not choose > "We will accept ... any method at our discretion" under your formulation > stands to be humiliated repeatedly until they revise their policies to > say so as I explained previously. > > I guess the existence of resulting let's call it "Sleevi boilerplate" is > harmless, but it seems foolish for Mozilla to demand people write > boilerplate that doesn't achieve anything. > > > I encourage you to make use of PACER/RECAP then. > > I examined 7 pages of RECAP results for "Key Compromise". Most of them > meant this phrase in the sense of "important settlement of differences" > but some were cryptography related. While your original premise that I was arguing for "secret" documents as a means to force potentially illegitimate revocations, which my previous mail went into detail about how that was flawed, I can see by replying here, you thought I was agreeing. 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 Hope that helps clarify for you. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
