On Thu, Dec 27, 2018 at 9:00 PM Ryan Sleevi <r...@sleevi.com> wrote: > I'm not really sure I understand this response at all. I'm hoping you can > clarify. > > On Thu, Dec 27, 2018 at 3:45 PM James Burton <j...@0.me.uk> wrote: > >> For a CA to intentionally state that they are going to violate the BR >> requirements means that that CA is under immense pressure to comply with >> demands or face retribution. >> > > I'm not sure I understand how this flows. Comply with whose demands? Face > retribution from who, and why? >
The CA must be under immense pressure to comply with demands from certain customers to determine that they don't have much of a choice but to intentionally violate the BR requirements and by telling community and root stores early they are hoping for leniency. The retribution by them customers could be legal which is outside of this forum but is but it's still relevant to them if that is the case. > >> The severity inflicted on a CA by intentionally violating the BR >> requirements can be severe. Rolling a dice of chance. Why take the risk? >> > > I'm not sure I understand the question at the end, and suspect there's a > point to the question I'm missing. > The CA is rolling the dice of chance, they are intentionally risking everything by violating the BR requirements and they know that such action can face sanctions or distrust in the wrong case. The question I asked is why are they taking the risk which leads from the first statement. > Presumably, a CA stating they're going to violate the BR requirements, > knowing the risk to trust that it may pose, would have done everything > possible to gather every piece of information so that they could assess the > risk of violation is outweighed by whatever other risks (in this case, > revocation). If that's the case, is it unreasonable to ask how the CA > determined that - which is the root cause analysis question? And how to > mitigate whatever other risk (in this case, revocation) poses going > forward, so that violating the BRs isn't consistently seen as the "best" > option? > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
