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,--
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.
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:
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
/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.
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
--
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.