Look forward to seeing and discussing once the full scope of the request is shared.
On Wed, Dec 19, 2018 at 12:21 PM Jeremy Rowley <[email protected]> wrote: > We will post the full list of exceptions today. > > > > One of the big factors should be the risk to the industry/community if the > certificates aren’t revoked. Perhaps we can identify what the risk to the > community is in revocation delays first? There’s no need to know the exact > certs to talk about what the risk associated with underscore characters is. > Could you please explain the risk to the community in a revocation delay as > the “unreasonable” argument isn’t really supported without that > understanding. > > > > *From:* Ryan Sleevi <[email protected]> > *Sent:* Wednesday, December 19, 2018 7:17 AM > *To:* Jeremy Rowley <[email protected]> > *Cc:* [email protected]; mozilla-dev-security-policy < > [email protected]> > *Subject:* Re: Underscore characters > > > > 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 <[email protected]> > 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 <[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]> 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 > <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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
