Hi Gervase,

Thank you for the update on Mozilla's process.

I have one question regarding your wording. You write"I am therefore *proposing
*the following," and then you list your changes.

Does this mean that the "alternative" option is officially, 100%, off the
table? Or is this still an option Kathleen is considering?


On Tue, May 9, 2017 at 11:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
> Yesterday was May 8th, which was the day I had said we would stop
> discussing my proposal of what to do about Symantec and hand it over to
> Kathleen for a decision. This didn't happen for two reasons: I had some
> personal things to deal with, and also I think the proposal needs some
> modification.
> Mozilla runs an open and transparent root program, and listens to the
> voice of its community. And over the past few days it's been clear that
> our community is not impressed with Symantec's engagement, or lack
> thereof, with this process. I personally am also not impressed with the
> way that getting information from Symantec feels like pulling teeth;
> questions are answered at the last possible minute, and despite there
> being major outstanding problems with compliance to Mozilla's root
> program requirements (issue Y), no effort is made from their side to
> proactively engage and start to resolve these issues. It is clear from
> the issues list that there are a number of serious concerns, and these
> are not being engaged with. Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?
> I am also not happy with simply waiting for the outcome of private
> discussions between Google and Symantec in which Mozilla's interests are
> not adequately represented. I am keen to move forward, to demonstrate
> that delay is not rewarded, and (despite the fact that our process can
> be slow) to make sure that timely action is taken based on the results
> of our investigations. This is only fair, given that this is what we
> have attempted to do for other CAs which we have investigated. We should
> treat everyone the same, as far as we can.
> I am therefore proposing the following:
> * Editing the proposal to withdraw the "alternative" option, leaving
> only the "new PKI" option. I no longer have confidence that the
> alternative option represents an appropriate response. As some have
> pointed out, the "documentation" requirement is actually something
> Symantec should have done years ago as part of our intermediate
> disclosure process, and which other CAs have made great efforts to
> comply with already. The "new PKI" option represents the best way to
> reduce the risk from Symantec's under-managed and sprawling existing PKI.
> * Engagement here in m.d.s.p. with the community to refine and flesh out
> the "new PKI" proposal, based on the Google outline but examining it and
> enhancing it to make sure it is practical, both from an implementation
> perspective and to reduce disruption to sites as far as possible.
> * Discussions within Mozilla as necessary to make sure the appropriate
> parts of the organization are briefed on this process.
> * Submission of the proposal document to Kathleen at the earliest
> possible moment to propose that we have that plan approved as our
> requirements of Symantec. (The timeline here is dependent on other
> moving parts, but as noted above, delay is to be avoided.)
> We may in parallel ask further questions of Symantec, and expect timely
> answers (as this is a baseline requirement for participation in our root
> program), but this process will not wait around for those answers.
> I will begin work on these tasks tomorrow.
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Vincent Lynch
dev-security-policy mailing list

Reply via email to