Policy 2.8: MRSP Issue #129: Require non-discriminatory CA conduct

[Ben Wilson]

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 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 of the MRSP?

Thoughts?

Thanks,

Ben

[Ben Wilson]

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

[Joanna Fox]

Hello Ben and all,

We have put some thought into the practicality of this new requirement and how it will function considering the existing definition of High Risk Certificate Request. This led us to multiple questions for the functionality of this requirement. 

If CA’s are allowed to identify their own High Risk requests using internally derived risk-mitigation criteria what distinguishes this behavior from non-discriminatory behavior?

For example, If we have our own CA name in the High Risk category to prevent potential copy write issues, does that constitute us being discriminatory?

Is it deemed acceptable for the CA to reject this type of request because they consider it High-Risk or a violation of their Terms?

Furthermore, what happens when a certificate is questioned to be discriminatory? Is there an expectation for a CA to publicly provide private information that the customer used to attempt to obtain the certificate in order to justify its decision?

We hope to engage in some conversation around this issue so we all have a clear path forward prior to this requirement being instituted.

Thank you,

Joanna Fox

TrustCor Systems

[Ben Wilson]

Thanks, Joanna.  These are good questions to consider.

[Kyle Hamilton]

I recognize that this is a discussion of the merits of this policy change. I agree with this change, because changing legal names is a very expensive and involved process (much more so for corporations, but also for individuals).

I do need to ask about a connected issue, though, related to why this is even an issue in the first place. Where could I propose that the jurisdiction of the name's registration (for corporations in US, the ST= and C= fields of the Subject DN) be displayed in the EV notice bar? Corporate names tend to be unique among each place of registration (and they legitimately -are-, in US states). This isn't the place to make a full case for such a change, but I am asking to know where such a proposal and full case could be made.

Thanks for your help.

-Kyle H

--
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/CA%2B1gtab-g%2Bnp5xk_YaoKo%3D5QXkLk4zA6oscd6iBARhdnfo6ycw%40mail.gmail.com.

[Josh Aas]

I think it would be helpful to have more clarity on what behavior this
proposal is intended to prevent. With examples, if possible. It might
make it easier to understand if anything ought to be done, and if so,
what language would be most appropriate.

> --
> 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/CA%2B1gtabsOaZP88JXg5qP%2BGjZoAvc0n4_Y2Y%2B63KF94h2OoTDDQ%40mail.gmail.com.



--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA

[Ben Wilson]

The intent of the proposal was to ensure that CAs act fairly by applying objective, stated criteria to decisions (1) to not issue a certificate or (2) to revoke a certificate, but now I think that trying to prevent arbitrary refusals/revocations with policy language might raise more problems than we would be able to solve with any language we could adopt. However, I am still open to suggestions. Do any of these concepts resonate as satisfactory alternatives to "non-discriminatory" to anybody:  unbiased, non-arbitrary, objective, impartial, reasoned, justified, rational, or variations thereof? Can something be written that would meet the intent stated above without the need to interpret it repeatedly on a case-by-case basis for CAs in the future?

Thanks,

Ben

[Buschart, Rufus]

Honestly spoken, I still like the proposed language based on ETSI. I think it balances the duties of both parties (CAs and (potential) subscribers) fairly. If we look into the hard requirements of the proposed language it has three duties for the CA:

1. They need to have “non-discriminatory” practices
2. They need to describe in their “terms and condition” with whom they do business
3. and they have to do business with everybody who meets the requirements

 

Regarding 1: I understand this as something internal of the CA. This will need to be checked by the Auditor in the annual compliance audit and probably it will be discussed with the auditor every year again. But isn’t this exactly what we always need to do? If we wouldn’t always reflect on our understanding “non-discriminatory” probably the Jim-Crow-Laws would still be in place in the US

 

Regarding 2) This is more or less a one-time effort. The CA describes their target audience and with whom they don’t do business

 

Regarding 3) Shouldn’t this be the normal behavior? In Germany we even have a law (Allgemeines Gleichbehandlungsgesetz – Wikipedia

• sorry no English translation of this article available) that forbids discriminatory practices if they are based on race, ethnicity, gender, age, and plenty of other reasons

 

/Rufus

.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa_8Wk4Gs97udUDom%3DzjcQxH-kKKEV3zFwmW%2BiPTxps9Q%40mail.gmail.com.

[Pedro Fuentes]

Hello,

If we look at the Mozilla Policy, related to inclusion decisions, we see:

"We reserve the right to not include certificates from a particular CA in our root program. This includes (but is not limited to) cases where we believe that a CA has caused undue risks to users’ security, e.g. by knowingly issuing certificates without the knowledge of the entities whose information is referenced in those certificates ('MITM certificates'). Mozilla is under no obligation to explain the reasoning behind any inclusion decision."

This seems to add a certain level of arbitrariness, and my question is... how Mozilla is considering the "non-discriminatory" conduct to these aspects of the policy. Should we expect some changes in that respect?

OK, I'm forcing the situation here, but this is what I mean... while it's obvious that a CA should not do any discriminatory practice based "race, ethnicity, gender, age, and plenty of other reasons", I just also think that the CAs should have also the possibility to reserve certain rights of not making business with an individual or company... So in general I'm not super-comfortable with a too broad approach here.

[Ben Wilson]

Would a "SHOULD" work better?  Rather than making it a requirement, what if it were a recommendation?  Would that give CAs the needed flexibility?

[Tim Hollebeek]

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

 

--

[Aaron Gable]

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.

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.

[Ben Wilson]

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