On Wed, Feb 2, 2022 at 1:45 PM 'Aaron Gable' via [email protected] <[email protected]> wrote:
> I appreciate the effort to balance the concerns of > 1) How do we let a subscriber revoke for keyCompromise even if their key > has been stolen and deleted?; and > 2) How do we prevent a third party who has never held the key from > revoking for keyCompromise? > > I think that the currently-proposed text does a reasonably good job of > striking that balance, but I fear that it is too complex. In particular, I > think that the different "cascading revocation" scenarios, particularly > combined with the no-future-issuance requirement raised by Doug, are > complex enough that they would be likely to be implemented incorrectly. > > I would propose the following slightly different attempt to strike the > balance: > > ``` > keyCompromise (1) > The CRLReason keyCompromise (1) MUST be used when one or more of the > following occurs: > - the CA obtains verifiable evidence that the certificate subscriber’s > private key corresponding to the public key in the certificate suffered a > key compromise; > - the CA is made aware of a demonstrated or proven method that exposes the > certificate subscriber’s private key to compromise; > - there is clear evidence that the specific method used to generate the > private key was flawed; > - the CA is made aware of a demonstrated or proven method that can easily > compute the certificate subscriber’s private key based on the public key in > the certificate (such as a Debian weak key, see > https://wiki.debian.org/TLSkeys); or > - the certificate subscriber *has proved possession of their private key* > and requests that the CA revoke the certificate for this reason. > > <the bit about "MAY be used" goes here> > > Otherwise this CRLReason MUST NOT be used. > ``` > > This proof of possession could happen at issuance time, at revocation > time, or at any other time prior to revocation. Subscribers who want to be > able to revoke for reason keyCompromise even if their key is stolen and > deleted can prove possession at issuance time. CAs that want all of their > subscribers to be able to do so can require proof of possession for > issuance. > > I believe this is essentially the same thing that Doug Beattie is > proposing. I recognize that it is different from what Ryan Sleevi is > proposing. Yes, this prevents someone who has never proved possession of > their own key from requesting a keyCompromise revocation if they have lost > their key. But it also provides an avenue for that proof of possession to > have happened ahead of time, and prevents someone who has never held the > key from DOSing legitimate subscribers. > Yes, I appreciate the attempt to strike a balance here, but I'm not sure whose interests it's balancing versus the harm? That is, the proposal here, which similar to Doug, basically forbids Subscribers from requesting revocation for keyCompromise unless they did something in the past, or do extra work now. Why is that good? Why is that necessary to shift the complexity to billions of Subscribers, versus trying to find a clearer way for CAs? That's perhaps why I find it somewhat unsatisfying - we're saying to Subscribers "You should have known better", rather than trying to make sure their wishes are respected, and users are protected. Am I overlooking part of the balancing equation? Is it just, as Jesper highlighted, that we're worried that CAs won't understand their obligations? -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFydTcGXkDOan3YJvbRVzznvmQ%2Bv1cWYMibh1V4jhXoTQ%40mail.gmail.com.
