On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote: > Hi Steve, > > Thanks for posting this. I appreciate the level of detail provided, > which is useful in giving us a basis for discussion. It's a little > regrettable, though, that it was published a couple of weeks after we > were led to expect it...
In our June 1 post, we stated that we would update the community after the end of the month. Considering the community’s request for detail in our response, we wanted our update to reflect our latest discussions with RFP respondents, which took place during the first two weeks of July. These discussions have directly informed our proposed dates as described in our post. We also felt it was important to collect feedback from both Google and Mozilla (which we have done) on our draft timing proposal before submitting it to the community for consideration given that Google and Mozilla authored / endorsed the SubCA proposal. > One note before we start: Symantec's business dealings regarding its CA > business are not of concern to Mozilla other than relating to the > "change of ownership or control" provisions in Mozilla policy (policy > 2.5 section 8). However, if dates are proposed or agreed for > implementation of the consensus plan, we would not expect those dates to > be renegotiated because of a change of ownership or control. > > Am I right in saying that, in order to hit these dates you are > proposing, you would strongly desire to get consensus on them by August 1st? Symantec would like to reach consensus on the totality of the SubCA proposal, including final dates, as soon as possible. This is in the best interest of all. Our proposed dates assume we are able to finalize negotiation of contracts with the selected Managed CA partner(s), which incorporate final agreed-upon dates by the community, by no later than July 31, 2017. > On 18/07/17 19:22, Steve Medin wrote: > > New Certificate Issuance: We believe the dates for transition of validation > > and issuance to the Managed CA that are both aggressive and achievable are > > as follows: > > > > - Implement the Managed CA by December 1, 2017 (changed from August 8, > > 2017); > > > > - Managed CA performs domain validation for all new certificates by > > December 1, 2017 (changed from November 1, 2017); and > > > > - Managed CA performs full validation for all certificates by February 1, > > 2018. Prior to this date, reuse of Symantec authenticated organization > > information would be allowable for certificates of <13 months in validity. > > To summarise for those reading along: this represents a change of a > little less than 4 months for the first date, 1 month for the second > date, and the third date is as originally proposed. This is correct. We have worked with our RFP respondents to put together an aggressive but achievable plan that delivers on the spirit of the original proposal. > Steve: to be clear, this means that browsers could implement a block on > certificates from Symantec's existing PKI as follows: after December > 1st, 2017, they could dis-trust all certificates with a notBefore > greater than December 1st 2017? Correct. However, as we indicated in our update, with a change of this magnitude we believe that there will likely be material compatibility and interoperability issues that will only come to light once server operators begin the transition to the Managed CA issued certificates. Recognizing this, we recommend that we establish a clear process to evaluate exception requests that includes consultations with the browsers to handle such corner cases. > Given the explanations Symantec has given as to why these dates are > reasonable, and the effort required to stand up the new PKI, I am minded > to accept them, particularly as they have managed to hit the third > originally-proposed date on the nose. However, I am still open to > community input. > > > Replacement of Unexpired Certificates Issued Before June 1, 2016: There are > > two major milestones that must be achieved after implementation of the > > Managed CA in order to replace unexpired certificates issued before June 1, > > 2016 that do not naturally expire before the distrust date(s) in the SubCA > > proposal. Those include the full revalidation of certificate information > > and then the customer replacement of those certificates. > > That is not necessarily so. The customers could replace their > certificates using new, CT-logged certificates from Symantec's old > infrastructure. This doesn't require any revalidation or any change in > the certificate chain, so should have excellent compatibility > properties, and it's something that could begin today. While this is true under the terms of the SubCA proposal, we do not believe this is consistent with the spirit of Google’s and Mozilla’s prior commentary on their intent regarding the SubCA proposal, which is to limit the issuance of Symantec certificates under Symantec’s existing infrastructure and governance. While we continue to believe the SubCA proposal is unnecessary and unwarranted, our primary objective has always been to minimize any potential business disruption for our customers and for browser users while also responding to Google’s and Mozilla’s comments about Symantec certificates and our issuance practices, which is why we have previously indicated our willingness to adopt the SubCA proposal with appropriate modifications, such as achievable dates. Accordingly, our intention and expectation is that the majority of certificates issued before June 1, 2016 that will need to be replaced before their expiration under the current SubCA proposal will occur after the Managed CA is implemented. This will ensure there are no limitations on the replacement certificates that are issued to affected customers, which limits the substantial risks of implementation problems if our customers are not given the appropriate time to plan and execute their certificate replacements. In our post we explained our rationale of why this period needs to be a minimum of 9 months. It is important for the community to note the significant operational burden and compatibility / interoperability risks that our customers will face if they have to replace their certificates once, let alone twice. > In fact, as I > understand it, Symantec has already been encouraging their customers to > do exactly this. Symantec has received significant inbound requests from customers about whether or not they should be replacing their certificates issued before June 1, 2016 based on the dates of Google’s original SubCA proposal. To allay concerns, which were compounded by predatory statements by some of our competitors, Symantec sent a message to customers explaining how to replace their certificates now as a preventative and risk mitigation measure. In that outreach, we were clear, as Google and Mozilla have been, that the SubCA proposal was still a proposal and not an agreed upon plan that required customer action. > This would, of course, mean, that those certificates would need > replacing again at some point before the final total dis-trust of the > current Symantec PKI. Correct. This increases business disruption and interoperability and compatibility risk, which is why we do not believe a December 1, 2017 distrust date is feasible or constructive (more on that below). Assuming the final SubCA plan implements a May 1, 2018 distrust date for certificates issued before June 1, 2016, we will recommend to customers that they begin planning their replacement of unexpired certificates once the SubCA proposal becomes an agreed-upon plan. We will further recommend to customers that they schedule the actual replacement of such unexpired certificates, where possible, for a date that is after full implementation of the Managed CA (February 1, 2018) so they can execute early replacement of their Symantec certificates issued before June 1, 2016 with new certificates that will be valid for the lifetime they require (within the scope of the BRs). We believe organizations will need up to 9 months to safely plan for and carry out this unscheduled transition. Our recommendation for replacing certificates issued before June 1, 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a single shift to our new PKI for SSL/TLS certificates and eliminates any necessity for organizations to replace their certificates multiple times. > This activity would need to start during the December holiday season > when many organizations impose infrastructure blackout periods. As > such, we believe that the only achievable timing for this transition is > after the holiday season. We understand that browsers may want to > technically enforce this transition and that multiple milestones may be > undesirable from a coding perspective. In order to accommodate a > simplified and cost efficient transition schedule (especially for > organizations that currently have certificates with notBefore dates of > both June 1, 2015 and June 1, 2016) and to allow impacted organizations > the time, as they will likely need to replace, test and operationalize > these replacement certificates in their infrastructure, we recommend > consolidating Chrome's distrust dates to a single date of May 1, 2018. > This would mean that Chrome's distrust of Symantec certificates issued > before June 1, 2015 would change from August 31, 2017 to May 1, 2018, > and that Chrome's distrust of Symantec certificates issued before June > 1, 2016 would change from January 18, 2018 to May 1, 2018. > > A key date for Mozilla is when we can tell our software to dis-trust any > certificate issued by the Symantec current PKI which was issued before > June 1st 2016, because certificates issued after that are guaranteed > (pretty much) to be in CT, and therefore are a bounded and known set. > Therefore pushing that date out to May 1st 2018 seems like a negative > from our perspective. > > A two-stage strategy such as the one outlined above seems to us to be > worth investigating, as it would allow us to give Symantec more time to > transition its customers from the current to the new PKI (something > which might come with compatibility risk, as you have correctly noted) > without having to bear the risk of continuing to trust arbitrary and > unbounded sections of the current PKI. > > So I would like to propose an alternative timeline based on those > principles. The exact dates could be discussed, but it might work > something like this: > > December 1st, 2017: Dis-trust of all current PKI certificates issued > before June 1st, 2016. This means all Symantec customers with certs > older than this would need to implement a certificate change in the next > four months, but they could do so to near-identical certificates issued > from the same roots, intermediates and infra, a prospect which should > have excellent compatibility characteristics. Why December 1st? Well, it > matches with the other December 1st date (for standing up the new PKI), > and extending further beyond that seems to provide little value given > the holiday change freeze issue that is regularly raised. > > November 1st, 2018: Total dis-trust of the current Symantec PKI. This > gives Symantec the full nine month window that you have requested (from > Feb 1, the target date for Managed CAs to be able to do validation, to > Nov 1) to transition their customers from the old PKI to the new PKI, > with new validations done by the Managed CA. In an improvement from the > existing plan, this nine months no longer contains a holiday blackout > period, and does not overlap the period when you are focussed on > standing up the new PKI. Mozilla feels more comfortable about allowing > an extended time for this transition because the set of old PKI > certificates that would need be trusted during this period would be > known and bounded because they would all be in CT. > > I would like Symantec to seriously consider and comment on the > feasibility of a plan structured along these lines. We believe a suggestion to implement a December 1, 2017 distrust date for certificates issued before June 1, 2016 and a total distrust date of November 30, 2018 for Symantec PKI for SSL/TLS is contrary to a fundamental principle underlying the SubCA proposal and substantially increases Internet ecosystem disruption and compatibility / interoperability risk. The practical effect of this suggestion is to require up to two early replacements for affected customers of certificates issued before June 1, 2016 and a newly introduced early replacement cycle for customers of certificates issued between June 1, 2016 and December 1, 2017, the proposed date of transition to the Managed CA. This suggestion increases compatibility and interoperability risk, and causes substantially increased disruption to websites and web end-users. A December 1, 2017 distrust date for certificates issued before June 1, 2016 effectively prevents Symantec from issuing replacement certificates on the Managed CA infrastructure, which is contrary to what we have been led to believe was the original purpose of the SubCA proposal made by Google and Mozilla. Symantec has done extensive work to propose what we believe is the most aggressive timeline for both migration to the Managed CA(s) and the distrust of certificates issued before June 1, 2016 that is also achievable and safe. The earliest distrust date that is both aggressive and achievable is May 1, 2018 for Symantec SSL/TLS certificates issued before June 1, 2016. In fact, we urge the community to consider postponing this to as late as February 1, 2019. Our proposed 9-month period (from August 1, 2017 to May 1, 2018) is significantly more aggressive than other extraordinary events that have involved early certificate replacement, such as the years of transition to 2048 bit and SHA-256 certificates (the only relevant comparisons for an effort of this magnitude). Further, the most practical period for customers to time their changes to minimize further disruption will be after we have implemented full validation with the Managed CA, which we propose to be no later than February 1, 2018. This leaves effectively 3 months for our affected customers to test and implement replacement certificates assuming they schedule their replacements during this window. The introduction of a new “total distrust” condition to the SubCA proposal – a November 1, 2018 total distrust date for Symantec’s PKI for SSL/TLS – creates a new distrust event for Symantec customers of unexpired certificates issued between June 1, 2016 and December 1, 2017, the proposed date of transition to the Managed CA, which significantly expands the scope of total Internet ecosystem disruption under the SubCA proposal. Further, this “total distrust” condition, when combined with the December 1, 2017 distrust date suggestion for certificates issued before June 1, 2016, necessarily creates a second early replacement cycle for the new certificates that are issued as a replacement of unexpired certificates issued before June 1, 2016. That’s a punitive result for customers that replace such unexpired, pre-June 1, 2016 issued certificates with new Symantec certificates. Multiple, premature replacements will also increase confusion and compound the possibility of mistakes during customer implementation. More importantly, however, this newly introduced “total distrust” date condition to the SubCA proposal is completely contrary to a fundamental principle of the original SubCA proposal authored by Google and endorsed by Mozilla, which Symantec has relied upon in good faith in evaluating whether and how to implement the SubCA proposal – namely, that “existing certificates issued on or after June 1st 2016 would still be trusted, provided they comply with the Chrome CT policy.” On May 23, 2017, Google confirmed on Blink that Symantec certificates issued after June 1, 2016 would not be “be constrained in any way (such as reduced validity, no EV treatment, etc.).” On July 7, 2017, Mozilla confirmed on Blink: “Mozilla continues to support the proposal as originally written (with the exception of questions about timeline, which remain to be agreed).” Simply put, this total distrust date suggestion introduces a new condition to the SubCA proposal that is uniquely punitive to Symantec’s CA business and to Symantec customers, is unjustified, and materially alters a fundamental tenet of the original SubCA proposal, which Mozilla has publicly endorsed as recently as July 7, 2017 and which Symantec and its prospective Managed CA partner(s) have relied upon in all of our discussions and SubCA planning efforts to date. In light of all of these implications, we respectfully request that Mozilla, Google and the community consider the dates Symantec has proposed, which are the results of our earnest and extensive efforts to implement the spirit of the SubCA proposal. > > We've also received feedback from some of our prospective Managed CA > > partners that they would like Symantec validation staff to continue to > > perform verification of identity under the baseline requirements. The > > Managed CA would complete all domain validation and they would make the > > final decision on certificate issuance. In this scenario, Symantec would > > continue to undertake a baseline requirement audit and WebTrust audit for > > as long as it operates that particular RA function. Permitting Symantec to > > perform just the organizational validation (not the domain validation) > > would give customers an uninterrupted experience while still meeting the > > stated objectives. We look forward to community feedback on this proposed > > change to the SubCA proposal. > > I think I prefer the proposal where Symantec staff work under the aegis > of the Managed CA, it is responsible for them, and they report to it. > > Note that I am on holiday for a further week, but will try and check in > here from time to time. > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
