On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy < [email protected]> wrote:
> All but one of your suggestions would require the revocation of existing > SubCA certificates, essentially invalidating all existing uses of > certificates issued by those SubCAs (Each certificate holder would need > to obtain and install at least a new SubCA cert, possibly a complete new > end cert). > This is not at all an accurate representation of what it would require, but I'm not sure it's worth pointing out the code to you, since I think the broader conversation is whether or not that's a bad thing. While you're presupposing it's objectively bad, you haven't demonstrated that it's an unreasonable requirement. Then there is your suggestion of requiring technically constrained > SubCAs (that were constrained under a previous set of relevant name > types) could survive by subjecting themselves to the massive overhead of > satisfying the requirements for an unconstrained SubCA (audits, dual > user authentication, specially secured server facilities, geographic > redundancy, etc.), where as a constrained SubCA they could operate under > normal enterprise internal security rules. > Yup. > Could you suggest an alternative solution that does not impose such > significant costs? > Why? You're moving a goalpost as it suits, and that's not a productive line of discussion. To the point that there are multiple ways to address this problem is established. That there are paths forward that avoid radically breaking backwards compatibility is also established. What you haven't stated, but which is clear from your replies, is you view these costs to exceed the cost of breaking backwards compatibility. That's certainly a viewpoint you can take, and I respect your view, but you haven't advanced any arguments to support that, and merely stated it as factual. I hope we can agree there are multiple ways to address the introduction of new nametypes. These different approaches have different tradeoffs for them - revocation, auditing, new functionality, breaking old functionality - and I've presented this multitude in the hopes of demonstrating to you that jumping to a solution which notably runs counter to Mozilla's Principles isn't necessary - there are alternatives. You may still wish to view a solution that breaks backwards compatibility favorably, and it's unlikely I can convince you otherwise. But I can highlight for those on the list that alternatives do exist, and your solution has notable costs - costs that, in many cases, are deemed unacceptably high. > You seem to be ignoring my actual arguments and arguing only against > specific words and phrases. Hopefully, you can see from above that I haven't done so at all, but in fact been explaining to you why your proposal is unacceptably costly. It may be simply you disagree. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
