Next week I will close discussion on this matter, and I will close this Issue #129 altogether (as "won't fix"). While well-intentioned, the application of a "non-discrimination" rule would be too difficult to implement, without resorting to ad hoc decisions on a case-by-case basis (which might lead to allegations that such decisions were arbitrary themselves), and for other reasons presented in the comments received thus far. I will wait a week in case anyone comes forward with a really good answer to this problem. Thanks, Ben
On Thu, Oct 28, 2021 at 10:09 AM Aaron Gable <[email protected]> wrote: > Speaking personally: > > I support the idea that CAs should not discriminate against arbitrary > portions of their potential subscriber base. > > However, historically CAs have used the ability to limit certain subsets > of issuance in order to continue serving the majority of their subscriber > base while ensuring that they don't engage in misissuance. For example, a > CA might cease issuing EV certs with a specific country code because they > know there are data issues with their set of valid locality names within > that country. Or a CA might (and as far as I'm aware, some CAs do) prevent > all issuance for `.ir` domains, because some entities which use that TLD > are subject to US sanctions. Do those behaviors count as discriminating > against whole countries? If a CA blocks a potential subscriber due to > repeatedly violating rate limits, or repeatedly issuing certs which are > later revoked due to suspected phishing (as per BRs 4.1.1), how would a > claim of discrimination against that subscriber be adjudicated? > > How does one draw a line around what kinds of issuance limitations count > as discrimination and what kinds don't? How does one draw a line around how > long certain kinds of limitations can persist before they become > discriminatory? > > Again, I like the idea and sentiment here. It's just a little scary to > introduce the first "CAs *must/should* issue" requirement (in contrast to > the very common "CAs *must not* issue" requirements) with such nebulous > language. > > On Wed, Oct 27, 2021 at 12:41 PM 'Tim Hollebeek' via > [email protected] <[email protected]> wrote: > >> Ben, >> >> >> >> In addition to your concerns (which I share) about whether it’s actually >> possible to encode this sort of thing in policy successfully, I’ll note >> that your proposed text has a slight loophole: even though someone agrees >> to abide by their obligations in the T&Cs, they may not actually be >> complying with the T&Cs, and, to further complicate things, whether they >> are in compliance or not may be a matter that is in dispute between the >> parties. >> >> >> >> As written, the policy proposal would forbid revocation in cases where an >> entity is violating the T&Cs but refuses to admit it, as the entity can >> claim they are exempt from revocation because they “agreed to the T&Cs”. >> That would be a very unfortunate circumstance. >> >> >> >> -Tim >> >> >> >> *From:* [email protected] <[email protected]> >> *On Behalf Of *Ben Wilson >> *Sent:* Tuesday, October 19, 2021 4:54 PM >> *To:* [email protected] <[email protected]> >> *Subject:* Re: Policy 2.8: MRSP Issue #129: Require non-discriminatory >> CA conduct >> >> >> >> As an initial edit, I am proposing that we add the following language as >> a new subsection 6 to MRSP section 2.1 - "[CAs SHALL] provide services on a >> non-discriminatory basis to all applicants who meet the requirements and >> agree to abide by their obligations as specified in the CA's terms and >> conditions". See >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/fab61408608feed365a9446ac47560a34c06cf85 >> >> >> >> >> On Thu, Oct 7, 2021 at 6:06 PM Ben Wilson <[email protected]> wrote: >> >> All, >> >> >> >> This email is the first in a series of discussions concerning the next >> version of the Mozilla Root Store Policy (MSRP), version 2.8, to be >> published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8) >> >> >> >> Issue #129 <https://github.com/mozilla/pkipolicy/issues/129> in GitHub >> proposes that we add a policy of non-discrimination to the MRSP. >> >> >> >> This particular issue arose from discussions of whether CAs should be >> allowed to arbitrarily refuse to issue or to revoke certificates. (The >> situation involved an EV certificate for Stripe, Inc., of Kentucky, >> https://groups.google.com/g/mozilla.dev.security.policy/c/NjMmyA6MxN0/m/asxTGD3dCAAJ). >> Many of you argued that CAs should objectively and non-arbitrarily apply >> the issuance and revocation standards of the CA/Browser Forum. The full >> discussion can be read in the email thread referenced above, so I'll forego >> any attempt to recap. >> >> >> >> Potential policy language can be paraphrased from the suggestion made in >> Issue #129, which was to base language on ETSI 319 401--"Practices under >> which the CA operates SHALL be non-discriminatory. The CA SHALL make its >> services accessible to all applicants who meet the requirements and agree >> to abide by their obligations as specified in the CA's terms and >> conditions." Alternative wording might be something like, "Decisions not >> to issue or to revoke a certificate should be based on the unbiased >> application of the CA/Browser Forum's requirements using the objective >> criteria stated therein," OR "CAs shall apply the CA/Browser Forum’s >> issuance and revocation requirements in a non-arbitrary manner." >> >> Is a variation of the language above sufficient? What do you suggest as >> language? Should it be inserted somewhere in section 2 >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#2-certificate-authorities> >> of the MRSP? >> >> >> >> Thoughts? >> >> >> >> Thanks, >> >> >> >> Ben >> >> -- >> 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/CA%2B1gtabsOaZP88JXg5qP%2BGjZoAvc0n4_Y2Y%2B63KF94h2OoTDDQ%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabsOaZP88JXg5qP%2BGjZoAvc0n4_Y2Y%2B63KF94h2OoTDDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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/DM8PR14MB5237711529EF4B46FF7F6E1883859%40DM8PR14MB5237.namprd14.prod.outlook.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM8PR14MB5237711529EF4B46FF7F6E1883859%40DM8PR14MB5237.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CA%2B1gtaYzOFVrBXVj9o5j4RZDJCB4hac8OVATNZ50gFfyjDZ1Yg%40mail.gmail.com.
