I like the reporting mechanism. And Bugzilla is even better because it’s public. If someone complains, the CA can respond there. I know I wouldn’t have a problem saying on Bugzilla that we didn’t issue X cert because they are in X country or were found involved in Y criminal activity.
As for the scope of the problem, no idea. I know the scenarios I gave are real, but I’m unaware of any CA that refuses to issue certs to communities Mozilla might want to protect. From: Kurt Seifried <k...@seifried.org> Sent: Wednesday, March 1, 2023 9:49 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Ryan Hurst <ryan.hu...@gmail.com>; Kathleen Wilson <kwil...@mozilla.com>; dev-security-policy@mozilla.org Subject: Re: DRAFT: Root Inclusion Considerations Also is there any mechanism for an entity to report a CA refusing to service them? Can I suggest it might be better to: 1) Create some sort of reporting mechanism (bugzilla?) 2) Create some sort of process, e.g. where the CA is questioned and has to explain why they refused it Because then we'd actually have some facts upon which to figure out what happens next. E.g. Do we even know how often this happens at all? Like is this even a problem? On Wed, Mar 1, 2023 at 9:36 PM Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > 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 dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> > Sent: Wednesday, March 1, 2023 9:21 PM To: Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Cc: Ryan Hurst <ryan.hu...@gmail.com <mailto:ryan.hu...@gmail.com> >; Kathleen Wilson <kwil...@mozilla.com <mailto:kwil...@mozilla.com> >; dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> Subject: Re: DRAFT: Root Inclusion Considerations GRAY AREAS. dangit. On Wed, Mar 1, 2023 at 9:20 PM Kurt Seifried <k...@seifried.org <mailto:k...@seifried.org> > wrote: On Wed, Mar 1, 2023 at 9:10 PM 'Jeremy Rowley' via dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@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-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> > on behalf of Ryan Hurst <ryan.hu...@gmail.com <mailto:ryan.hu...@gmail.com> > Sent: Wednesday, March 1, 2023 7:54:31 PM To: Kathleen Wilson <kwil...@mozilla.com <mailto:kwil...@mozilla.com> > Cc: dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> <dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> > Subject: Re: DRAFT: Root Inclusion Considerations Kathleen/Ben, I have been thinking about the new <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Root_Inclusion_Considerations%23Concerning_Behavior___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OmNhNGQ6MDJmNDRlYjc5ZWFhNWVlNzQxMjFlYTM4M2U4MGJjOTQ3MDNkMjdmNGZiOWFmODM1NmQ5YTNiZGM5YWFiZTJjODpoOlQ> Concerning Behavior 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 <https://url.avanan.click/v2/___https:/letsencrypt.org/2015/10/29/phishing-and-malware.html___.YXAzOmRpZ2ljZXJ0OmE6bzo3YjI3MDBkNWJiZTQ3OGUyNTRmYjY5M2I0ZmZmMzk1MDo2OjkxNWY6YzM1Y2M4Y2U4MTgzNmQ2N2UwZDVkYmRlOTJiODJmYzQ3NzdiNTI5MDI0YzAzZWEyZDVhODFiOGNlZjNkNTNkNDpoOlQ> CAs make poor content watchdogs. 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 <kwil...@mozilla.com <mailto:kwil...@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-security-policy@mozilla.org <mailto: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 <mailto: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/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-security-policy@mozilla.org <mailto: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 <mailto: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/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-security-policy@mozilla.org <mailto: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 <mailto: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/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) k...@seifried.org <mailto:k...@seifried.org> -- Kurt Seifried (He/Him) k...@seifried.org <mailto:k...@seifried.org> -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org <mailto: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 <mailto: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/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> . -- Kurt Seifried (He/Him) k...@seifried.org <mailto:k...@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/BYAPR14MB2600458BFC513541B777A5AB8EB29%40BYAPR14MB2600.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
