Yeah – I’ll be providing an accurate incident report (working on gathering all the information). The incident report assumes we don’t revoke of course. Revocation is still on the table. However, I wanted to start the conversation with everything I know so far:
1) ~2200 certs 2) Roughly 15 companies 3) Only one has publicly chimed in so far on the Mozilla thread (still hoping more will…) 4) Revocation of all certs will occur by May 1, 2019, depending on how the discussion here goes. 5) The common thread is that the Jan 15th deadline falls in the blackout window of most orgs. They generally come off it between Jan 15-Feb 15. They can’t replace the cert or change the domain so the 30 day cert option doesn’t help. 6) We provided notice as soon as the ballot passed. We blocked issuance prior to that date, but we’d hoped that the certs could remain valid until expiration. We had trouble with our BI providing the information so some notices went out later than I’d hoped. I’ll find the exact date on when all notices were complete. Ballot 202 failed. I’m not sure how it’s relevant other than to indicate there was definite disagreement about whether underscores were permitted or not. As previously mentioned, I didn’t consider underscore characters prohibited until the ballot was proposed eliminating them in Oct. I know the general Mozilla population disagrees but, right or wrong, that’s the root cause of it all. I can explain my reasoning again here, but I doubt it materially alters the conversation and outcome. From: Ryan Sleevi <[email protected]> Sent: Tuesday, December 18, 2018 7:35 PM To: Jeremy Rowley <[email protected]> Cc: mozilla-dev-security-policy <[email protected]> Subject: Re: Underscore characters 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] <mailto:[email protected]> > wrote: The total number of certs impacted is about 2200. Just more info. -----Original Message----- From: dev-security-policy <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
