I concur that censorship should be carried out transparently, with comprehensive policies documented in their CPS and any applications of that policy be published in a discoverable manner. For instance, when censorship is the reason for an order being rejected, detailed errors should be published, and possibly a CENSORED.TXT file could be published in a well-known location, similar to how SECURITY.TXT is used to identify security contacts.
I also believe that when a CA serves only a narrow or specific community, its CPS should explicitly state this. This raises questions about whether such entities should be included in the Mozilla root program, which is designed to serve the broader Mozilla community. However, that is a separate discussion. Regardless of the outcome of this discussion, I think it is appropriate to document Mozilla's stance. This could involve adding text on Concerning Behavior, Recommending Best Practices, or updating the root program requirements themselves. Given the various gray areas that exist in this topic, It was my belief the non-binding nature of"Concerning Behavior" was appropriate which is why I mentioned it here. This is because my understanding is that this is a section of "considerations" not "prohibitions". Ryan Hurst On Thu, Mar 2, 2023 at 2:39 PM Watson Ladd <[email protected]> wrote: > On Wed, Mar 1, 2023 at 9:57 PM Ryan Hurst <[email protected]> wrote: > > > > Jeremy, > > > > I wanted to respond to your other two comments. > > > > [JR] That wasn’t proposed language. That was pointing out a flaw in > saying “No censorship is allowed”. > > > > To be clear, my proposed language did not say “no censorship is > allowed”. Suggesting so would be what I think most would consider a straw > man argument. What I did say, in essence, is that said censorship only when > served the legal obligations of the CA or requirements of other root > programs. > > > > This in essence says if a government says we want you to censor people > here is the definition we want you to follow. If a root program wants you > to censor here is the standard we want you to follow and Mozilla respects > their right to do so. > > > > Basically, there needs to be a clear standard so it is applied uniformly. > > I'd like to suggest a more generalized approach to the issue. First > off we should require that the CPS cover in detail who the CA issues > for, and what will lead to non-issuance. That information is important > for evaluating the risk vs. reward of adding a CA. Secondly we should > say that content based restrictions are inappropriate vs. e.g. "we > only serve educational institutions", "we only serve *.ir domains", > etc. > > Otherwise I think we'll end up debating the merits of a particular > decision endlessly vs. separating into the CPS and whether it was > followed. > > The other point I want to raise is that if CAs broadly have limited > sets of issuance, we might be in a situation where some websites could > not transition in case of distrust. That would be problematic for the > health of the ecosystem, and is a reason we need to evaluate who CAs > will and will not serve. > > Sincerely, > Watson > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwYi%2BoyNOAYT%2Bo1v3D5%2BsomT%3DZ8QhJPCpXRTsfuPV2CuQA%40mail.gmail.com.
