I think that is the wrong question. If we go to first principles, Mozilla Root Policy exists to support Mozilla's mission:
Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe, and independent. With that context, I believe the question becomes how giving WebPKI CAs room to be content watchdogs supports that vision, and does doing so conflict with that mission? I would argue that it does not support the mission and accommodating it conflicts with that vision. More concretely, I would argue that the fact the objective of ensuring the internet is a "global public resource" that is "open and accessible to all" directly speaks to the organization's position on this class of problem. Furthermore, the mission's focus on empowering individuals to "shape their own experiences" suggests that the user or their agent should protect them from maliciousness, not some third party they have never heard of. As a technologist, if I put aside the mission of the organization and ask myself at which layer of the stack should be used to protect users from malicious content, the first question I would ask is at what layer in the stack can we see the content that the user is going to interact with. The answer to that question would exclude doing so at the naming layer, which is what both DNS and the WebPKI represent, as they don't see the same content the user does, and content changes far more often than certificates expire. Furthermore, since a browser's technological objective is to provide a uniform experience for its users, I would posit the objective of the root program is to deliver a uniform experience for those that rely on HTTPS within the browser since it is HTTPS that demands the existence of the root program. This precludes accommodating subjectivity; after all, there are nearly 100 members of the root program, and many of these organizations operate in countries with different concepts of appropriateness. To me, this means that for Mozilla to allow for censoring for reasons outside some narrowly defined scope that is well defined, such as legal obligations and conflicts with other root program requirements it must provide a definition for what is acceptable if it wants them to do this. Otherwise, from the perspective of the web, Mozilla's behavior is non-deterministic. I say this because CAs in the WebPKI serve at the behest of browsers (which are the user’s agents) as they facilitate the browsers to provide authenticated and encrypted sessions for them. In the case of Mozilla, they achieve this goal by using their software and associated community to advance its broader mission, which includes this scope, which is why the root program exists. Ryan Hurst On Wednesday, March 1, 2023 at 8:20:50 PM UTC-8 Kurt Seifried wrote: > On Wed, Mar 1, 2023 at 9:10 PM 'Jeremy Rowley' via > dev-secur...@mozilla.org <dev-secur...@mozilla.org> 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:* dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of >> Ryan Hurst <ryan....@gmail.com> >> *Sent:* Wednesday, March 1, 2023 7:54:31 PM >> *To:* Kathleen Wilson <kwi...@mozilla.com> >> *Cc:* dev-secur...@mozilla.org <dev-secur...@mozilla.org> >> *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 <kwi...@mozilla.com> >> 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 >> "dev-secur...@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-po...@mozilla.org. >> 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 >> "dev-secur...@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-po...@mozilla.org. >> 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 >> "dev-secur...@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-po...@mozilla.org. >> > 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://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB26000622195C610DB2107B7F8EB29%40BYAPR14MB2600.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Kurt Seifried (He/Him) > ku...@seifried.org > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/57fea565-5b93-44a7-bd3d-668dd3e813fen%40mozilla.org.
