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: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> im 
Auftrag von Ben Wilson <bwil...@mozilla.com>
Datum: Mittwoch, 27. Oktober 2021 um 05:26
An: dev-secur...@mozilla.org <dev-security-policy@mozilla.org>
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 
<j...@letsencrypt.org<mailto:j...@letsencrypt.org>> 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 
<bwil...@mozilla.com<mailto:bwil...@mozilla.com>> 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 
> <bwil...@mozilla.com<mailto:bwil...@mozilla.com>> 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 
> "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%2bunsubscr...@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<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 
"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/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 
"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/AM8PR10MB4305383F358D9A718BB9CA299E859%40AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM.

Reply via email to