On Tue, Apr 14, 2020 at 8:13 PM Robin Alden <[email protected]> wrote:
> 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 know it was more an aside, but I’m not sure I follow what you mean by “over an above”. Was that meant to suggest those required in law need not be documented? 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. Indeed, there’s real trade-offs here. Browsers selection of which CAs to trust is based on how well those CAs align with the browsers’ goals and needs. This is why we don’t just trust every Average Joe who knows how to run openssl via the cmdline, and why the Mozilla policy exists. There are two main ways to ensure that CAs’ actions are aligned with browsers’ needs: requirements & prohibitions on certain actions (e.g. browser policies, audit criteria, guidelines like the Baseline Requirements) and transparency (via CT, via CP/CPS, etc) 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? Why does this distinction matter? The reality is outright restricting either and/or both is challenging on a number of dimensions, least of all being that we continue to have trouble capturing basic technical requirements clearly and unambiguously (or at least, creative interpretations about ambiguity). The first step is to transparency to try and quantify this problem. 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. I mean, this is spot on the problem. The certificate lifecycle between different parties is misaligned, and this is an area where existing technologies don’t have easy answers. This isn’t a problem unique to CAs either; consider a Root Program A that explicitly requires revocation for Reason X, but a different Root Program B does not want to have certificates and sites stop working just Root Program A doesn’t like the certificate. Presumably, if a UA is going to define policies, such as around the reason codes to use and how and when they’re used, then it’s going to have to require that the CA be responsible for that certificate unless and until it hits one of those terminal reasons. These problems are “solvable”, but take time. Having more robust expressions for revocation is an approach worth exploring. Legacy clients would still treat them as absolutely rejected, but modern clients responding to modern problems can use these modern solutions. Regardless, starting work on a normative profile for CRL Reasons to reduce ambiguity seems... useful? If only to flesh out precisely the problem space involved where a CA has the near-universal power (when revocation checking is supported) to rescind a certificate arbitrarily, contrary to the browser, user, and site needs and desires. Having that sort of choke point, which spans a variety of software clients, and for which limited alternatives exist by necessity, seems bad for all. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
