While I appreciate you sharing what you have, as I tried to capture in my previous message, I don't believe there can be any discussion or consideration in earnest without the full and final information. I don't think it's reasonable to drip in information piece meal, given the impact and affect that can have - whether incomplete information for the issue or whether additional customers being added.
You're making a huge request of the community, arguably one that borderlines unreasonable given the set of issues had in the past. I do want to help you achieve your goal of understanding what that would look like, but that's only possible with full and complete information. You mentioned it's roughly 15 companies. If you had ten committed, but were waiting on the remaining five to give the OK, I think it would be irresponsible to hold up having that conversation until you get the OK. Quite simply, if you don't get the OK from those five companies, then we shouldn't even be discussing them. Ultimately, the ball is in your court as to how you want to address this with your customers, but I think that delaying the conversation in order to make sure "stragglers" are included is probably not the wisest for your customers that have their stuff together. As such, I don't think the conversation can begin without that (hypothetical) incident report, and I look forward to you deciding what that scope will be in order to share and commit to it. On Tue, Dec 18, 2018 at 9:51 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote: > 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 <r...@sleevi.com> > *Sent:* Tuesday, December 18, 2018 7:35 PM > *To:* Jeremy Rowley <jeremy.row...@digicert.com> > *Cc:* mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > *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 < > dev-security-policy@lists.mozilla.org> wrote: > > The total number of certs impacted is about 2200. Just more info. > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Tuesday, December 18, 2018 3:28 PM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > <https://clicktime.symantec.com/a/1/UwaqiTBLrHZxNFaFiw6tF5llM6J0dwQUFAOmtu6Yhmg=?d=GFS0cws0XLcWxiZpBrQGssA_ePKmj4UUy4D2_uRaH8vcPjyqROPrY3hUGg2pgvZX_ZSweYg_qEW7ZnDID39n3Y03BrX9ZUmyKw12P0Lj3uQ1-NFXv2hJ3n_IhoJZ45zw5xY2Xlqsb5yTdnfpqFO0GRgdzt8VIkyfA4oCGdPCIie8zO5lwRWA9_9L1nY_oZnqebapEewPO7G3TFTC4Vzng0UMv_e8PwMZ74yTMF7rGLvtqD3lsC4TLVB3F-26Y6p4yOZ6AszODfYLWEldaDnPqOG-u9qQ_sjKPN8Wkk7PJK_Feu4CFeTXTv8QoOYXf3d8ZDukCHi7G9GW5g98ljUVS25gLdi_Qv4sRenxqpOmGBi6LfMOAfGfsRcnQGYIdObfC97HsN8F&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
