I think it might be useful to take a step back and remind ourselves of Mozilla's mission, principles and goals with regard to resolving the situation with Symantec. These will be useful as we flesh out the details of the consensus proposal, particularly concerning dates.
First, a quick reminder on goals, anti-goals and non-goals. Goal: something you specifically want to achieve. Anti-goal: something you specifically want to not achieve. Non-goal: something you are explicitly not trying to achieve. Non-goals differ from anti-goals in that you will try hard not to achieve an anti-goal, but you don't mind either way whether a non-goal happens or not. In deciding what is a goal, anti-goal or non-goal, we need to establish our principles, which in this case I will define as higher-level things we believe and are trying to achieve with our root program which are not specific to this particular situation. Mozilla's principles relating to this situation all flow from our overarching mission to do good to and for the Web, and the manifesto principle that the security of web citizens is essential. More specifically, I would characterise our principles here as follows: Root Program Principles ----------------------- 1) Maintain the public's trust in the WebPKI as a whole. 2) In any change, minimise disruption to websites and web end-users. 3) Make decisions for the benefit of Mozilla and its mission first. 4) Operate in a transparent, consultative and open way. In this case, we are attempting to maintain trust in the WebPKI by executing the sub-task of eliminating hierarchies, systems and/or issuers who have lost trust. So our goals in this particular situation, where we no longer have trust in Symantec's "old" (current) PKI, are therefore: Symantec Remediation Goals -------------------------- A) Remove the roots relating to the old Symantec PKI from our root store as quickly as possible. B) Before we can do so, take interim steps to minimise risk by reducing the scope of trust in their old PKI, such as: * not trusting new Symantec-controlled issuance; * not trusting certs without proof of publication; and/or * not trusting certs issued before a certain date; all as quickly as possible. C) Make sure that those certificate users with a hard dependency on Symantec's old PKI and also a requirement for public trust have, or mostly have, sufficient transition time to eliminate that dependency. Something which is a non-goal is that Symantec be able to continue issuing all the same types of certs at the same volumes to all of their customers without interruption. This will almost certainly be a goal for Symantec, but it's not a goal for Mozilla. It must be pointed out that it's not an anti-goal either - we are not _aiming_ to affect Symantec's business. But we are not going to take decisions which treat maintaining those capabilities unchanged as a goal. This point will become important when Symantec publishes the results of the process they are currently going through to find CAs to work with them on taking over issuance from their old PKI. Their plans and the dates associated with them will, no doubt, be predicated on that goal, which is not our goal (but to repeat, is not an anti-goal), and will need to be evaluated in that light. Symantec also need to be clear that "we signed a contract to meet this goal" is not an argument which will cause that goal to become Mozilla's goal. Any set of dates we require which are not "as long as you need" will inevitably have a level of arbitrariness about them. Why not a week more? Why not a week less? I think it would be unhelpful, therefore, to get into a date-based "negotiation". We need to make our best estimate of how long it would take Symantec and their partners to put in place systems which allow our goals to be met, and choose deadlines accordingly. The only other thing which might modify our requirements is the fact that this is a consensus proposal we are implementing. Consensus is a good thing for the WebPKI and for Symantec, who I'm sure would not welcome the prospect of implementing several different remediation plans at the same time. Therefore, we should also take into account the published principles and goals of other root store operators who are part of the consensus, and how the proposal might need to be written to also meet their goals. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
