On Fri, Dec 7, 2018 at 4:35 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> I only ask because telling people to go back to the CA and work something > out isn’t a great answer when the retort is that the CA will be distrusted > if they don’t. Either the customer doesn’t replace all their certs and they > are made non-functional by revocation or the certs are distrusted because > the CA isn’t operational anymore. Telling people to go have the CA cover > the risk when those are the two options seems like we’re avoiding the > public discussion. > Why not? It's fundamentally the CA taking the risk on when deciding whether or not to meet the requirements of the programs that they participate in - whether technical, policy, or contractual. If a customer wanted to ask a CA to break a contractual requirement, isn't it ultimately the CA they should be asking? I think we're in agreement that, regardless, the CA MUST receive a qualified audit. There's seemingly no defense that if they fail to revoke, it should be a qualification, and there's even an argument that the issuance itself should have been a qualification (and result in their auditor re-evaluating these material facts, such as under AT-C 205.A54-A57 regarding revisions to opinions in light of subsequent events and application guidance). It's unclear what you expect to result from a public discussion, so perhaps it would be helpful if you could clarify. It sounds like you're looking for a blanket rubric for which to ignore the requirements of the Baseline Requirements, so that the rubric can then be applied customer requests, and determine whether or not these individual customers justify violating the BRs. A good CA would acknowledge the rubric is, in fact, zero - zero violations is the "justified" case, and everything else is the risk case. Alternatively, it may be a desire that a rubric should exist, a priori to any violations, so as to help determine whether a violation is justified, even when the stated goal is zero violations. If you look at public discussions, think about what the goals are of the Incident Response template, which is about understanding how the CA's processes failed. If you were to imagine intentionally violating the BRs, knowingly, it seems like an incident response template would be far more damning for that CA's operational competencies. That's not to suggest to CAs its better to ask forgiveness than permission - a CA that ignored changes in the BRs, clearly communicated (as Wayne mentioned in the original post), also seems likely to have an incident report template that is quite damning. Using the experiences from the SHA-1 exception process, the only formalized exception process, you can see that even in those limited cases, there was significant skepticism towards the reasons. I would think that any proposal for exceptions minimally achieve that degree of transparency, but would be equally damning if those justifications were the same as those used for SHA-1 - as the SHA-1 exception process "should" have revealed that those are not, in fact, seen as legitimate. If it helps to imagine this as a "How would this incident be received if it became part of a Wiki page that listed a series of ongoing violations", I think any CA contemplating not meeting the required transition date should be asking "How many issues have I (or my sub-CAs) had under https://wiki.mozilla.org/CA/Incident_Dashboard and https://wiki.mozilla.org/CA/Closed_Incidents ). And there are definitely some CAs that do not look to great in that light. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
