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...
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? 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. 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? 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. In fact, as I understand it, Symantec has already been encouraging their customers to do exactly this. 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. 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'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
