Jeremy, It seems like any answer for what it "might" look like if a CA violated the BRs in a particular way is going to be predicated on what the incident report says. In the case of a hypothetical like this, it seems like the hypothetical incident report would discuss what is planned or proposed, and should a CA go forward with such an intentional violation, the 'actual' incident report would equally consider how accurate that was.
Recall that the approach to incident reporting is not punitive - it's to make sure that we're addressing systemic gaps and issues, that we've understood the issues, and have the available data to assess the impact, risk, and any patterns of issues. The incident reporting template is one way to provide that data in a structured way and to gather feedback. I think a minimum next step is to move from the abstract discussion to the concrete: imagine you went forward on Jan 15 and had to file an incident report. Write the report like that. Include the timeframes, affected certificates, impact, root causes, remediation plans, etc. Having a complete presentation of what the discussion is about seems critical to having that discussion, because it would be unreasonable to expect information to trickle in and new customers or use cases added as the discussion progresses. Thus there's a balance to be struck: Treating each hypothetical as a "separate" incident report runs the risk of being considered in isolation, ignoring both the systemic gaps and the cumulative risk. At the same time, treating it as a "singular" incident report tries to paint all problems in the same stroke, and can overlook distinct systemic issues. Both cases run the risk of "scope creep", which is constantly adding or expanding the scope, which is as well received in legitimate incident reports as it is hypothetical (which is to say: not well). Perhaps the best analogy is to that of subordinate CAs: each time a subordinate has an issue, that's an incident report, and a pattern of issues at distinct subordinates is equally a concerning issue for the parent CA. You don't want to loop all distinct subordinates into one issue, but you also don't want to lose sight of the systemic issues with the parent. Beyond that framing and execution, it seems useful to suggest that any timeline about underscores should at least acknowledge Ballot 202 in June 2017 and any/all steps the CA took leading up to and following SC12. None of this is radically new or should be surprising: DigiCert and other CAs have already had similar conversations in discussing other matters of BR compliance and revocation. All of these have become part of the CA's record of incidents. When the CA proposes extending revocation timelines, a discussion of the facts, risks, scope, and patterns play a core part in any discussion in determining the short term acceptability of the proposal, and unquestionably all factor in to any long-term discussions that may later happen. The one last closing thought is that I think we're in the waning days for when such hypothetical issues or concrete delay proposals can or should be discussed. Given the many discussions that have been had regarding revocation - regarding technical non-compliance, compromised keys, weak validation, etc - the argument that "replacing a cert is hard" is not really going to be acceptable anymore without demonstration about what steps are being taken by CAs and Subscribers to mitigate that risk (such as automation) and communicate expectations (such as in Subscriber Agreements or Terms of Sale). I don't think we want to go through 2019, and certainly not come out of it, having the same conversations we've been having in 2018. The best way to prevent that is for CAs to take clear steps to work to resolve these issues with their customers, so that it never becomes an issue for them, or their CA, in the first place. CAs that aren't able to demonstrate steps towards that in future discussions are unlikely to be looked upon too favorably if there are future incident reports. On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy < [email protected]> wrote: > The total number of certs impacted is about 2200. Just more info. > > -----Original Message----- > From: dev-security-policy <[email protected]> > On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Tuesday, December 18, 2018 3:28 PM > To: mozilla-dev-security-policy > <[email protected]> > Subject: Underscore characters > > We're looking at the feasibility of replacing the certificates with > underscore characters by Jan 15th. Revoking all of the certificates will > cause pretty bad outages. We're prepared to revoke them but would like to > discuss (before the date) what should happen if we don't revoke. There are > about 15 customers (which I can't disclose the names yet but am working on > the list of certs). The number of certificates range between 1700-100 > certificates per customer. > > > > The primary reason for this is every one of these organization are in a > holiday blackout. The blackout periods end between Jan 12-Feb 15. Can we > start this discussion now on what this means? I'll provide certificate > lists > as I have a timeline on when they plan on replacing. > > > > Jeremy > > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
