On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx <[email protected]> wrote: > On 2016-12-16 15:45, Gervase Markham wrote: >> >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't >> trust cert chains that rely on it, so there's no need to ban it. Is there? > > > Can I point out again that Firefox (or NSS) is not the only user of the root > store?
Can I point out again https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F Not trying to be snarky - just that if we're going to act upon your comment, actionable data and concerns are needed. Put more concretely: - Hypotheticals ("What about software foo?") should not be considered unless they're demonstrated - If they are demonstrated, the author/maintainers of those packages should be engaging with the Mozilla community to represent those concerns So let's say, for example, that Curl was using the Mozilla set, but using it with a GnuTLS validator, and was concerned about a direction that Mozilla would take - wanting additional time or to push back on that. It seems eminently reasonable to expect that both the maintainers of Curl and GnuTLS's validator would step up and participate, representing those concerns, and be open/amenable to changes or to explaining why changes may not work. Absent that, as an upstream project, it seems entirely reasonable that a decision is made, on list, and unless someone comes up with specific and concrete objections (with a plan for remediating or exploring the problem more), then it goes forward. For example, "This would break Curl, and we'd need a new version of GnuTLS to support [X]. Could you wait on making this change for 3 months so that we can get a new release out?" is a concrete and actionable plan :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
