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. [JR] This is the crux of the issue. Appropriate vs. inappropriate censorship or what is a good definition of censorship? Is not wanting to issue to Dark Matter censorship after Mozilla booted them? What about sites that are espousing hate crimes? Although there’s nothing that says a CA needs to verify the contents of a site, there’s also nothing saying the CA can’t vet the content of a website. One of my big worries with the original DMCA was being a contributory infringer for copyright violation. If I refuse issuance to Warez sites, is that censorship? A definition would be good. Let's take the topic of hate speech. As the agent of the user Mozilla provides a number of capabilities. This includes all the supporting technology and the associated ecosystem that enables it to authenticate domain names and provide TLS. It also supports technologies to protect its users from content and malicious names, one example being its support for Safe Browsing (I think it might be called Phishing Protection now). If Mozilla wants those it delegates verification of domain control to also protect users from malicious or hateful content it should specify what standard to apply. Absent that CAs should be put on notice that applying opaque and subjective “good censorship” is something to be considered when they evaluate if a CA should be a member of the root program. Ryan Hurst On Wednesday, March 1, 2023 at 8:36:25 PM UTC-8 Jeremy Rowley wrote: > 1) CA's have to abide by legal restrictions in their jurisdiction (e.g. US > sanctions) and often in other jurisdictions (e.g. US sanctions, if you use > US banks.. yeah) > > [JR] Yeah – but what if its not exactly 100% sanctioned? For example, > assume the US decides to sanction a country and France doesn’t. If the CA > in France decides not to issue because the entity is on the sanctions list, > then what? Did they censure it? Or what if the CA is tired of a country > being put on and taken off the US list every month and just stops allowing > issuance to that domain. Its okay to issue there some months, but not > others. > > > > 2) Please define censorship, if you mean "not willing to issue a > certificate" then there are many gay areas, e.g. let's pick on Russia. What > if the CA says "look, we get a ton of spam/abuse/bad behavior from Russia, > so we're simply declining to take those risks, it's not worth it"? Are we > now going to force people to deal with everyone and not allow them to be > somewhat selective in their clientele? > > [JR] This is the crux of the issue. Appropriate vs. inappropriate > censorship or what is a good definition of censorship? Is not wanting to > issue to Dark Matter censorship after Mozilla booted them? What about sites > that are espousing hate crimes? Although there’s nothing that says a CA > needs to verify the contents of a site, there’s also nothing saying the CA > can’t vet the content of a website. One of my big worries with the original > DMCA was being a contributory infringer for copyright violation. If I > refuse issuance to Warez sites, is that censorship? A definition would be > good. > > > > 3) "the policy should include some standard where a ca can exclude > entities where there is there is a risk of potentially facilitating of > legally questionable activity." > > > > Please define "legally questionable", please define which jurisdictions > come into play (the CA? the client? the US where Mozilla resides? anything > else?) and so on. This is hugely problematic language. > > [JR] That wasn’t proposed language. That was pointing out a flaw in saying > “No censorship is allowed”. > > > > Sort of devil's advocate: Why is it a problem if a CA refuses to provide > certificates to someone/some entity, assuming it's legal (e.g. a US CA > refusing certificates to protected classes of people would likely not be > legal, but refusing to service an entire state would likely be legal)? > > [JR] I think there’s years of court cases that try to answer this > question, and answer it better than I could. But I think Mozilla has an > interest in making sure CAs are providing services to the community as a > whole (for example, not issuing only to themselves) while allowing CAs to > manage their own risk profile. > > > > > > *From:* 'Kurt Seifried' via [email protected] < > [email protected]> > *Sent:* Wednesday, March 1, 2023 9:21 PM > *To:* Jeremy Rowley <[email protected]> > > *Cc:* Ryan Hurst <[email protected]>; Kathleen Wilson <[email protected]>; > [email protected] > *Subject:* Re: DRAFT: Root Inclusion Considerations > > > > GRAY AREAS. dangit. > > > > On Wed, Mar 1, 2023 at 9:20 PM Kurt Seifried <[email protected]> wrote: > > > > > > On Wed, Mar 1, 2023 at 9:10 PM 'Jeremy Rowley' via > [email protected] <[email protected]> wrote: > > I think this approach is dangerous too though. Is it censorship if a CA > won’t issue to Russian entities? What about to other government entities? > If Mozilla goes down this route, the policy should include some standard > where a ca can exclude entities where there is there is a risk of > potentially facilitating of legally questionable activity. > > > > So some concerns: > > > > 1) CA's have to abide by legal restrictions in their jurisdiction (e.g. US > sanctions) and often in other jurisdictions (e.g. US sanctions, if you use > US banks.. yeah) > > > > 2) Please define censorship, if you mean "not willing to issue a > certificate" then there are many gay areas, e.g. let's pick on Russia. What > if the CA says "look, we get a ton of spam/abuse/bad behavior from Russia, > so we're simply declining to take those risks, it's not worth it"? Are we > now going to force people to deal with everyone and not allow them to be > somewhat selective in their clientele? > > > > 3) "the policy should include some standard where a ca can exclude > entities where there is there is a risk of potentially facilitating of > legally questionable activity." > > > > Please define "legally questionable", please define which jurisdictions > come into play (the CA? the client? the US where Mozilla resides? anything > else?) and so on. This is hugely problematic language. > > > > I'm inclined to aks the question: > > > > Sort of devil's advocate: Why is it a problem if a CA refuses to provide > certificates to someone/some entity, assuming it's legal (e.g. a US CA > refusing certificates to protected classes of people would likely not be > legal, but refusing to service an entire state would likely be legal)? > > > > ------------------------------ > > *From:* [email protected] <[email protected]> on behalf of > Ryan Hurst <[email protected]> > *Sent:* Wednesday, March 1, 2023 7:54:31 PM > *To:* Kathleen Wilson <[email protected]> > *Cc:* [email protected] <[email protected]> > *Subject:* Re: DRAFT: Root Inclusion Considerations > > > > Kathleen/Ben, > > > > I have been thinking about the new Concerning Behavior > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Root_Inclusion_Considerations%23Concerning_Behavior___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OmNhNGQ6MDJmNDRlYjc5ZWFhNWVlNzQxMjFlYTM4M2U4MGJjOTQ3MDNkMjdmNGZiOWFmODM1NmQ5YTNiZGM5YWFiZTJjODpoOlQ> > > language being proposed for the Mozilla Root Store Policy and I wanted to > share my thoughts relative to this policy and censorship. > > > > When discussing CA inclusions, a topic that commonly comes up is the risk > of the applicant violating the privacy of Mozilla's users by enabling > MiTMs. However, there are other concerning behaviors that are not often > discussed, such as the use of certificate issuance and denial as tools for > censorship, community exclusion, and enabling misinformation. > > > > These behaviors can have far-reaching impacts on Mozilla's customers and > are not aligned with the objectives of Mozilla as I understand them. > > > > In 2015, Let's Encrypt wrote a blog post on why CAs make poor content > watchdogs > <https://url.avanan.click/v2/___https:/letsencrypt.org/2015/10/29/phishing-and-malware.html___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjkxNWY6YzM1Y2M4Y2U4MTgzNmQ2N2UwZDVkYmRlOTJiODJmYzQ3NzdiNTI5MDI0YzAzZWEyZDVhODFiOGNlZjNkNTNkNDpoOlQ>. > > I believe the points raised in this post are still relevant today, and it > may make sense to add some language to the Concerning Behavior section of > the Root Store Policy to make Mozilla's position on these topics clear. > > > > For example, we could consider adding the following bullets to the warning > signs section: > > > > - CA operators who attempt to act as a content watchdog beyond what is > required by other root programs or governing legal jurisdictions should be > seen as a warning sign of behavior that could lead to censorship and be > incompatible with Mozilas objectives for the root program and its > principles overall. > - CA operators who attempt to act as content watchdogs by denying the > issuance of Internationalized Domain Names (IDNs) for reasons beyond legal > jurisdictional requirements, what is required by other root programs, or > the technical limitations of their certificate issuance systems should be > seen as a warning sign of behavior that could lead to censorship which > would be incompatible with Mozilas objectives for the root program and its > principles overall as it limits access to the internet for non-English > speaking users and may be used as a tool for political or cultural control. > > > > While this is probably not the exact right wording something similar to > this has the potential to make it clear what Mozilla's position on these > topics is and as a result, strongly discourage CAs from leveraging their > position to support these activities. > > > > Best regards, > > Ryan Hurst > > > > > > On Wed, Mar 1, 2023 at 4:46 PM Kathleen Wilson <[email protected]> wrote: > > I continue to receive feedback/concerns about the auditor bullet point in > the "Concerning Behavior > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Root_Inclusion_Considerations%23Concerning_Behavior___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjI4NWY6MGUyYzhlOTQ1ZDUwOTBjYjg4ZmQ5NjViNTgwZDNhNDJkMDY2NDRjN2FiYmE4ZGRlMDFkODA4M2U3NjljYjM1NjpoOlQ>" > > section, so I am attempting to resolve those concerns with the following > version of that bullet point: > > > > - The CA is using an auditing organization (ETSI > > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Audit_Statements%23Verifying_ETSI_Auditor_Qualifications___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjAxYjM6MzRhYTc1Njc3OWJlNjYxYTUxNmExNjE1MDAzZmI5OTEwZWFiYjllNjFiYmE5MjFmY2I4MTM0YWIyNTg4NjA5NzpoOlQ>, > > WebTrust > > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Audit_Statements%23Verifying_WebTrust_Auditor_Qualifications___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjZhY2E6MmEzNGUxMjRmNjVlYjEwMzgyODI1ZWM5ZTcwMTBhZjhiMTI4NjI0MzA1OTRlZDUzZTFjOGVjNmVjNDkyM2M2YTpoOlQ>) > > that has not audited other publicly trusted CAs whose root certificates > are > included in browser root store programs, and the Auditor Qualifications > > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Audit_Statements%23Providing_Auditor_Qualifications___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OmY4ZWU6YjdjYzkwNTg3N2U0Y2Q0NTM5N2NlYzJmMzkxNzIyNTJhYjNjNTU0YWQ3OTA5YzRiZjkxZDQ4YmUwODllMWVkMzpoOlQ> > > indicate that the audit team is inexperienced in auditing CA operations, > public key infrastructure, trust services or similar information systems. > > > - New auditors are allowed under the condition that the CA ensures > that the Audit Team is lead by third-party specialists or affiliate > audit > firms who are experienced in auditing publicly trusted CAs, and this > information must be provided as part of the Auditor Qualifications. > > > > I will appreciate feedback and suggestions on this new text. Does it > address your concerns? > > > > Also, I am no longer receiving feedback on the rest of the wiki page, > https://wiki.mozilla.org/CA/Root_Inclusion_Considerations > <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Root_Inclusion_Considerations___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjVlMDc6MjkyZmNiMjdiNzQzN2JjNzdhYWQ1M2Y3NDI4ODI5ODVjY2JkMDBkN2EyYjdlNDYxNzQ3MTdjNmUwNzczZGU1MjpoOlQ>, > > so I am assuming that the rest of the page is solid (i.e. ready to remove > the "DRAFT" at the top of the page). > > > > Thanks, > > Kathleen > > > > > > -- > 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/164d74b3-2371-4d79-815c-2bcd466ace00n%40mozilla.org > > <https://url.avanan.click/v2/___https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/164d74b3-2371-4d79-815c-2bcd466ace00n%40mozilla.org?utm_medium=email&utm_source=footer___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OmVmMjM6ZGFkOTk0MjU3OThkZDcxYmE1ZjM0YmNmYzM2NjVkNmMzZGJlOWMxOGFmOGE3ODhlYTZjNzdhMTY2ZjA4NjZlZjpoOlQ> > . > > -- > 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/CALVZKwY_j1foAGnqW0atHEx%3DMLLZdPXgx-K5aWXyMFvAMnW-2w%40mail.gmail.com > > <https://url.avanan.click/v2/___https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwY_j1foAGnqW0atHEx%3DMLLZdPXgx-K5aWXyMFvAMnW-2w%40mail.gmail.com?utm_medium=email&utm_source=footer___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjRhM2Q6YTE2OGJjYmZjZWM5OTU2NjI5NjQ4NTc3YWE0MDRmYTJiZmMyMTIxZWQxNjc0M2E1Y2FmMjU3ZmE1ODFlMGM0MzpoOlQ> > . > > -- > 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/BYAPR14MB26000622195C610DB2107B7F8EB29%40BYAPR14MB2600.namprd14.prod.outlook.com > > <https://url.avanan.click/v2/___https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB26000622195C610DB2107B7F8EB29%40BYAPR14MB2600.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer___.YXAzOmRpZ2ljZXJ0OmE6bzoxZGI4Mjg1OWEzMGJmNzM4NjA2N2JjMTcwMmUxMzBjYjo2OmExNzI6MzIzNGNiNGI4OGY1ZjA5MzM3Y2IzMDM5MGY1NzU5YmY2YjAzZThjYzdmMjA0MTcxNmM5YWQ0MWMxOWQ4NjExNjpoOlQ> > . > > > > > -- > > Kurt Seifried (He/Him) > [email protected] > > > > > -- > > Kurt Seifried (He/Him) > [email protected] > > -- > 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/CABqVa382qwgB%3DC0jMjDWNVWu_2NQRBEVDcsMw88%2B3%3D5zf2Jp7Q%40mail.gmail.com > > <https://url.avanan.click/v2/___https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa382qwgB%3DC0jMjDWNVWu_2NQRBEVDcsMw88%2B3%3D5zf2Jp7Q%40mail.gmail.com?utm_medium=email&utm_source=footer___.YXAzOmRpZ2ljZXJ0OmE6bzoxZGI4Mjg1OWEzMGJmNzM4NjA2N2JjMTcwMmUxMzBjYjo2OjViMTI6YjAyNjk0NDQ1MzQ1MzZiMjZmMjZhNjU5ODJmOGJhYjBjYTEwZmRmMjM5NDc1MGRkMjVmZGRlNWIxZTBmMWJhYjpoOlQ> > . > -- 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/97f19967-8831-4aa8-9bfc-8f9c80df712en%40mozilla.org.
