On Thursday, March 26, 2020 at 2:23:11 PM UTC-7, Ryan Sleevi wrote: > On Thu, Mar 26, 2020 at 4:45 PM Ian Carroll via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > > Hi all, > > > > A recent thread on CAs using contractual terms to revoke certificates has > > made me want to bring up a topic that I am surprised does not come up more: > > removing the control of revocation from CAs and moving it to the user > > agent. While this is an idea that requires the backing of a user agent (for > > which I have none), I think it's worthwhile to float as a future prospect. > > You only focused on keyCompromise. Was that intentional? > > If it was, it seems like it might be missing the other scenarios > captured in the Baseline Requirements. CAs are required to have > legally enforceable Subscriber Agreements / Terms of Use with their > Subscribers (certificate holders), as a condition to issuing a > certificate. This is covered in 9.6.3 of the Baseline Requirements. > > That places certain obligations upon the Subscriber (certificate > holder). That's a risk tradeoff, and relies on the legal system rather > than a technical system, to enforce certain expectations. If it was > intentional to omit that, it's unclear if you're proposing to > deprecate it or replace it with some other mechanism, such as the CA > requiring that the Subscriber execute legally enforcable agreements > with all possible Relying Parties beforehand. If it was unintentional, > working through the design more is worthwhile. > > Some of this was already plumbed in the past, related to Certificate > Transparency and name redaction, in the context of "hostile redaction" > and "hostile unredaction". In effect, transitions of that mechanism to > purely technical come with it new risks for hijinks and shenanigans.
Hi Ryan, I don't see a reason why any obligation in 9.6.3 is not fulfillable by changing the obligation from a subscriber's notification to revoke to the CA, to an obligation for the subscriber to notify appropriate user-agents for revocation. It is intentional (and rather the entire point) that this proposal does not allow the CA to act unilaterally for the subscriber. I also don't see a reason why my proposal is limited to key compromise; while I did indeed focus on it for much of the post, all CRL revocation reasons can be encompassed by using either (a) the proof of possession of a key or (b) a CA issuing an incident report to user agents to trigger the revocation manually. There are, admittedly, potential problems to this sort of revocation method at scale, as it would be unfortunate to require an enterprise to put all of their private keys into a single database, rather than just directing the CA to perform the revocation based on their prior trust relationship. However, one could imagine many reasonable solutions to this, i.e. embedding a "revocation key" in certificates, or proving domain ownership as an alternative proof method. Can you expand on why you believe this sort of technical-oriented proposal might introduce more risks? If anything, I would say we would significantly reduce risk by consolidating part of a fragmented ecosystem into the clients the user trusts for their browsing. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
