I don’t think I’m arguing that CAs should ever ignore the BRs. I’m arguing that deciding the consequences of failing to follow the BRs falls in the hands of the browsers. But I think you definitely highlighted why this discussion is confusing. I think all agree on the following:
1. Failure to revoke by Jan 15th is a non-compliance with the BRs. 2. Non-compliances require an incident report 3. The incident should appear on the audit report. Side note – there won’t be audit criteria around this particular issue by the time all certs are revoked. We’re planning to inform our auditor of course (already have in fact), but without audit criteria any delay in issuance essentially goes undetected unless someone in this community notices. Because the audit criteria won’t be updated until well after our audit report, if we were a bad acting CA, the incident would just never show up. I think the only thing we disagree on is: 4. Can the browser say what happens for a failure to comply with the BRs before the failure happens. Is that a fair assessment? I see why you wouldn’t want to engage in the question you asked (“Hypothetically, what would happen if we did (Bad Thing X)". That would be terrible. Much better to treat this question as “We know X is going to happen. What’s the best way to mitigate the concerns of the community?” Exception was the wrong word in my original post. I should have used “What would you like us to do to mitigate when we miss the Jan 15ht deadline?” instead. Apologies for the confusion there. Jeremy From: Ryan Sleevi <r...@sleevi.com> Sent: Wednesday, December 26, 2018 10:00 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: dev-security-policy@lists.mozilla.org Subject: Re: Underscore characters On Wed, Dec 26, 2018 at 11:13 AM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hey Matt, The trust stores are always free to ignore the CAB Forum mandates and make their own rules. Mozilla has in the past (see the Mozilla audit criteria exception for other audits outside of Webtrust and ETSI). The root stores are also the entities that determine what happens if the rules are violated. Thus, we're asking what the violation of this revocation timeline results in and whether Mozilla is enforcing the CAB Forum requirement. The browsers always decide the risk they want to bear and when that risk becomes unacceptable. The question we're asking is whether this particular mis-revocation provision would amount to unacceptable risk to the browsers. I don't think we're asking browsers to take on any risk. In fact the opposite. The risk of revocation is a browser outage for that website. A delay in revocation gives the operator for specifically issued certificates gives them more time to avoid an outage. Thus, risk is mitigated. A poor explanation, but I think we have to identify what the risk is before browsers can say they are taking on anything additional. The "CAs may be doing bad things in the dark" allegation can't be responded to because it's too vague. I'm also troubled to think that might be a concern as our policy is to over-report issues. Plus, that risk is pretty hard to sell to management as an immediate threat requiring replacement of their certificates. This lack of definition on the problem is also the main difference between this event and a compromised key. Explaining key compromise to executive management for an emergency exception to a blackout period is a lot different than explaining why hundreds of certificates require replacement because they contain underscores. I think everyone would benefit (myself included) if I could get more information about why underscore characters themselves present an actual risk. If we could get a statement on that, you'd see a lot less confusion. Jeremy Jeremy, While I can't speak for Wayne, I tried to highlight how dangerous and problematic this thinking is and framing. By framing it as you have, it makes it much more difficult to see this as a productive discussion about handling revocation following an incident, and instead about a CA arguing that they should be able to ignore the BRs at will. I'm sure you can see how that latter framing is especially problematic, and I think arguments that try to present it as such have a chance at steering the conversation very negatively. You've heard from two browsers at least (Mozilla and Google) that they expect an incident report, which means that they are enforcing the Baseline Requirements and do view this as non-compliance by a CA. There is no exception being granted - it's non-compliance. Further, the discussion you're looking to have is seemingly not about whether this particular incident is problematic in-and-of-itself, even though you've framed it as such here, but instead whether the pattern and set of incidents represents a concern about the ongoing risk posed by continued trust. A poor analogy, but one that hopefully highlights the flaws in the argument you're making, is a bit like asking "What's so bad about stealing a candy bar from the shop", while trying to ignore whether you robbed the till the day previous or have been stealing every day the past week. The framing that seems to have resonated is that we are NOT talking about whether or not stealing candy bars is OK and acceptable. We've seemingly agreed it's bad, and thus (in the CA space) are expecting an incident report and treating it as an incident. It would be extremely risky to suggest that stealing is sometimes OK, both in the immediate and long-term. The question being discussed is what to do if (or, in this case, when) you're caught stealing, and what it would look like. Matt's moral hazard is absolutely correct with respect to legitimizing things - especially treating them as non-incidents. Similarly, I have concerns with the ideas that CAs can or should ask the community "Hypothetically, what would happen if we did (Bad Thing X)" - I think that demonstrates less than stellar trust. That's why I suggested that this is a continuation of the discussion about underscores - "So, a CA did bad thing X, how do we get the ecosystem whole without causing unnecessary challenges" - rather than being on trying to segment out the hierarchy into compromise vs CA negligence.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
