On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy < [email protected]> wrote:
> A major difficulty I found in trying to report compromised keys to CAs was > in finding a reporting address to use. Now, by itself, that could be > solved > by making CCADB reporting addresses be authoritative, but that would also > require standardisation of reporting types, and it's a whole rabbit hole. > There are also many other reasons why someone might want to examine the CPS > that pertains to a particular certificate, so it makes sense to be able to > easily find that document as and when required. > > Being unable to find the correct CPS for a CA had several causes: > > 1. Certificates don't *have* to have a cPSuri (although the vast majority > do); > > 2. cPSuri, when present, doesn't point at a CPS, but rather at a CA's > repository, which often contains a myriad of documents which often are > unclearly related to the certificate in hand; > > 3. When a relevant-looking CPS is found, it can be in a non-English > language, with no clear pointers to the location of the (Mozilla-required) > non-authoritative English translation of that document. > > My various sub-proposals are, unsurprisingly, closely aligned to these > sub-issues. > > 1. Make cPSuri mandatory I really appreciate that you first framed the problem you were trying to solve, before offering a solution. Despite my disagreement (and I do not support these ideas), knowing the problems you’re trying to solve with them at least help us try to find better solutions :) I don’t think you can just be dismissive about “it bloats certificates” when we continue to see that presents a challenge to new protocols. Just look at the work on certificate compression in the IETF. We really don’t need to be stuffing everything into subscriber certificates, especially when it’s relevant to who the issuer is. We also need to make sure we are optimizing for the right case - the vast majority of certificates who, for their entire lifetime, have no need to express the CPS URI, and would waste countless bytes (and electrons and fossil fuel) unnecessarily. This is exactly the sort of case CCADB is supremely positioned to solve, efficiently. In fact, all of these problems can be addressed by CCADB improvements, providing programmatically readable data while also making use of efficiencies and economies of scale. There were alternatives, for sure; the notion of machine readable CPSes is *why* we have CPS structure in the first place, but getting “CPS Validation” the way we have ALV is... a bigger change. Luckily, CAs can configure CCADB themselves. When there's no link to a CPS, in any way shape or form, I'm left flailing > around in the giant CCADB CSV o' doom to figure out where the CPS lives, > and > that... ain't easy. In one case, I sent a problem report to *completely* > the wrong CA. If each certificate had a link to the right place, that > problem, at least, couldn't happen. I can understand and appreciate CSVs are hard. I don’t think they justify costing users and providers tens of millions of dollars to make your life easier. Which is what those bytes cost, in very real terms. That’s ... not a good trade-off. To that end, figuring out ways to make this data easier, or open-source tools to assist and transform, is not at all unreasonable. 2. Make the cPSuri actually point to the relevant CPS That doesn’t really capture what a CPS is. There can be many relevant CPSes to a single certificate, both for a single path and multiple paths. That’s literally how audits came to be - to support the model of multiple CPSes. So a statement like “the relevant CPS” is going to be flawed, for better or worse. That’s a much bigger change to make (in how policies are managed). Despite the merits of forbidding the policy-based approach proposed by the ABA PAG, the problem reporting email is probably the least compelling reason for scrapping that :( However, that seems moot if addressed as above? The problem is that a CA's repository, or "online information provided by > the CA", typically looks something like this: > > * CPS for Device PKI > * Frambingaling CP and CPS v2.1 > * Latest Certificate Practice Statement for Small Furry Creatures > * Subscriber Agreement and Addendum for Something Something > > ... and so on. How I get from "I have a certificate that I need to > report", > which contains an issuer CN and not much else, to the correct document out > of that list above, is a non-trivial problem. Having the cPSuri point *to > the CPS* would completely solve that. So would CCADB. crt.sh is one easy way for one to link things. Do you disagree? If Mozilla Policy made normative that there be some form of binding problem reporting statement for each issuer certificate, would that address your problem or not? 3. Require non-English language CPSes to link to the English translation CCADB can solve this. It also seems a lower priority, in light of the earlier alternatives? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
