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.

El miércoles, 27 de octubre de 2021 a las 9:24:25 UTC+2, 
[email protected] escribió:

> 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 
> <https://de.wikipedia.org/wiki/Allgemeines_Gleichbehandlungsgesetz>
>
>    - 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
>
>  
>
> *Von: *[email protected] <[email protected]> im Auftrag von 
> Ben Wilson <[email protected]>
> *Datum: *Mittwoch, 27. Oktober 2021 um 05:26
> *An: *[email protected] <[email protected]>
> *Betreff: *Re: Policy 2.8: MRSP Issue #129: Require non-discriminatory CA 
> conduct
>
> 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
>
>  
>
> On Tue, Oct 26, 2021 at 8:14 AM Josh Aas <[email protected]> wrote:
>
> 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.
>
> On Tue, Oct 19, 2021 at 4:54 PM Ben Wilson <[email protected]> wrote:
> >
> > 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
>  
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2Ffab61408608feed365a9446ac47560a34c06cf85&data=04%7C01%7Crufus.buschart%40siemens.com%7Cdacd98614a64468c766e08d998f98bc0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709019828112932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KzCNXr5Up8rg%2FVaSRSxF2J%2Bth29553Kax6TBdbOWe1Y%3D&reserved=0>
> >
> > 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 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Flabels%2F2.8&data=04%7C01%7Crufus.buschart%40siemens.com%7Cdacd98614a64468c766e08d998f98bc0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709019828122886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KrAvbOJ6DjF373V5Q3kuhwU%2BBBCa%2B%2F8R7WN47fLNDJ8%3D&reserved=0>
> )
> >>
> >> 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
>  
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fg%2Fmozilla.dev.security.policy%2Fc%2FNjMmyA6MxN0%2Fm%2FasxTGD3dCAAJ&data=04%7C01%7Crufus.buschart%40siemens.com%7Cdacd98614a64468c766e08d998f98bc0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709019828132836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jKzMo2m7kFy2A%2Bn%2BxgkvLFXamygh4r%2Fp0qrXs6vb9Kc%3D&reserved=0>).
>  
> 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
> >
> > --
> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtabsOaZP88JXg5qP%252BGjZoAvc0n4_Y2Y%252B63KF94h2OoTDDQ%2540mail.gmail.com&data=04%7C01%7Crufus.buschart%40siemens.com%7Cdacd98614a64468c766e08d998f98bc0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709019828132836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VdoOEIDZXS%2FmZx8PflKkCZhYUKZ5OGQ2AHO4hQVycXs%3D&reserved=0>
> .
>
>
>
> -- 
> Josh Aas
> Executive Director
> Internet Security Research Group
> Let's Encrypt: A Free, Automated, and Open CA
>
> -- 
> 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%2B1gtaa_8Wk4Gs97udUDom%3DzjcQxH-kKKEV3zFwmW%2BiPTxps9Q%40mail.gmail.com
>  
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtaa_8Wk4Gs97udUDom%253DzjcQxH-kKKEV3zFwmW%252BiPTxps9Q%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crufus.buschart%40siemens.com%7Cdacd98614a64468c766e08d998f98bc0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637709019828142799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LQX0yzVOyUE6%2Bp%2B%2FwvZ%2FqXoORp1ZPWvEMnrfqD0969A%3D&reserved=0>
> .
>

-- 
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/0a9c8a35-7134-413a-87d1-d9681be1f91bn%40mozilla.org.

Reply via email to