On Sat, Mar 28, 2020 at 6:39 PM Ian Carroll via dev-security-policy < [email protected]> wrote:
> 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 see. - Who do you see the user agents that hundreds of millions of subscribers should notify? - What do you do for a new user agent entering the market? - How should a user agent respond if some user agents are notified, and they aren’t? - How does the user agent know that the Subscriber is authorized? - What legal remedies exist if the Subscriber fails to do so? I can understand and appreciate your desire to remove the CA from the equation. If issuance was not tied to CAs performing validation, this would make sense. However, attempting to decouple issuance from revocation is well known to create a large host of problems. It doesn’t seem the proposal is fleshed out to think about those second order effects, let alone the first order effects. Do you plan on writing it up more? Have you spent much time analyzing where it might fall apart? 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. And what happens if you lose the revocation key? This idea bears remarkable semblance (and weaknesses) to other key-based naming schemes, which is that loss of private key (not loss of control; loss) is incredibly common. Proof of domain ownership was addressed extensively during CT redaction discussions, as previously mentioned. Among other things, it seems like it makes it incredibly easy to exercise a DDOS at scale, by causing revocation of a Subscriber’s certificates, rather than misissuance. Is the assumption that this idea only works when all certificates are automated and all issuance is instantaneous (rather than distributed out of band, even when automated)? 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. I can totally understand and appreciate the appeal. It seems like it might benefit from doing some basic threat modeling of your modest proposal, and continuing to work until you’ve fleshed it out into something more cohesive and comprehensive. Hopefully, the above questions help highlight some of the challenges and limitations. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
