Done:
https://bugzilla.mozilla.org/show_bug.cgi?id=1515564 It ended up being about 1200 certs total that we are hearing can’t be replaced because of blackout periods. From: Ryan Sleevi <r...@sleevi.com> Sent: Wednesday, December 19, 2018 11:05 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Underscore characters 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 <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > 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 <r...@sleevi.com <mailto:r...@sleevi.com> > Sent: Wednesday, December 19, 2018 7:17 AM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > 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 <jeremy.row...@digicert.com <mailto: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 <mailto:r...@sleevi.com> > Sent: Tuesday, December 18, 2018 7:35 PM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
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
