> .. 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
