Generally, I'm in favor of transparency requirements, and many of Ryan's ideas would be useful or interesting to pursue. Transparency is often the first and best step towards improving business practices. And the entire purpose of a CPS is to disclose the business practices that implement a particular certificate policy (e.g. the Baseline Requirements). So I think it's entirely appropriate that Mozilla and other root policies consider and implement disclosure policies that mandate that certain security-relevant business practices be disclosed. Such requirements have even appeared in the Baseline Requirements from time to time, and should continue to do so.
Unfortunately, some CAs have chosen to use CPSs that have very little content other than "we comply with the baseline requirements". Root programs have taken a variety of stances on this in the past. For example, Mozilla has required CAs to actually disclose which validation methods they use, as opposed to which they _might_ use (all of them!). On the other hand, for example in Shanghai, some have argued that there is nothing wrong with a CPS that does not disclose anything about how CAs implement any of the policy requirements. I personally find myself in the transparency camp, and would prefer that when the details of how a CA complies with a particular requirement is security relevant, it would be an improvement if those details were disclosed. But that's in conflict with the "Default Non-disclose" policy that many people, both on the root program and CA side, have advocated for. I would personally find it very unfortunate if the trend continues, and we have increasingly vacuous CPSs that contain no relevant information. But in the absence of requirements to disclose relevant practices, I'm not surprised that that's a trend that has been embraced by some CAs. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Robin Alden via dev-security-policy > Sent: Tuesday, April 14, 2020 8:13 PM > To: r...@sleevi.com > Cc: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: RE: Terms and Conditions that use technical measures to make it > difficult to change CAs > > > .. There’s plenty of precedent in having Root Policy or the Baseline > > Requirements require a CP/CPS explicitly state something; examples > > such as the CAA domain name, the problem reporting mechanism and > > contact address, and compliance to the latest version of the BRs. > > > > If we apply that idea here, it might make sense to require the CA’s > > CP/CPS make a clear and unambiguous statement about whether or not > > they engage in X as a practice. I’m not quite sure what X should say, > > but the idea is that it would be transparent to Relying Parties > > wanting to evaluate a CA, as well as to User Agents when evaluating > > whether or not a given CA's practices provide a service relevant to > > user's of that software product. While it's conceivable that sites are > > already having these practices disclosed to them, having a consistent > > and public disclosure would help bring transparency into what CAs are > > engaging in this practice, and which have committed not to use > > revocation in this way, which can help make it easier to compare the > > trustworthiness of CAs up-front. > > I am ambivalent to the idea of having a list of business practices, presumably > over and above those required in law, that CAs must publish to the > community. > I suppose that CAs' existing contractual terms, particularly for large > subscribers such as enterprise organizations, are negotiated between the > two parties and so are typically known only to the CA and to the subscriber. > For other individual subscribers a standard subscriber agreement published in > advance more likely applies. > I'm sure that some subscribers will be happy to have additional oversight of > contractual terms rather than rely on their own reading and understanding of > the contract they sign, while others would not choose it, were that choice > available to them. > > Paraphrasing Jeremy's answer, actions speak louder than words. > Are these things that have been done, or things that contracts permit? > Is it words or actions that you seek to restrict? > > Kathleen posted this on the Mozilla PKI Policy github. > https://github.com/mozilla/pkipolicy/issues/208 > saying > > ".. some CAs have Terms and Conditions which say that if the customer > > moves to (or even tries to use) another CA, all of their certificates > > will be revoked. Enforcing all revocations (independent of reason) > > supports this bad behavior by CAs, helping them to hold their > > customers hostage. But if CAs always add the CRLReason for > > revocations, we can selectively enforce revocation for certain > > reasons, and have varying levels of enforcement (e.g. overridable > > versus > > not-overridable) > > Enforcing or restricting some revocation reasons is an interesting idea but I > think that selective implementation of revocation based on the concept of > there being 'good' and 'bad' revocation reasons has an implicit challenge. It > changes the certificate life-cycle. > > Simplistically, the life of a certificate today is either: > Issue - use - expire; or > Issue - use - revoke, > and in each case no further management of the certificate's state is possible > by either the CA or the subscriber after the terminal event. However, if there > are 'bad' revocations that will be ignored the life-cycle gets another step > under certain circumstances: > Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. > This requires both that the user is able to request a second revocation for a > different reason after an earlier revocation, and also that the CA has further > obligations to take actions concerning this certificate after it had been > initially revoked, e.g. re-revoking if misissuance or subscriber key > compromise were detected. > > Regards > Robin Alden > Sectigo Limited
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
