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. Aaron On Wed, Feb 2, 2022 at 9:02 AM 'Doug Beattie' via [email protected] <[email protected]> wrote: > Hi Jesper, > > > > Here’s my opinion on your 3 questions below, marked with “Doug:” > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Jesper Kristensen > *Sent:* Wednesday, February 2, 2022 11:41 AM > *To:* [email protected] > *Cc:* Kathleen Wilson <[email protected]> > *Subject:* Re: Revocation Reason Codes for TLS End-Entity Certificates > > > > You don't often get email from [email protected]. Learn why this is > important <http://aka.ms/LearnAboutSenderIdentification> > > It seems that some of the criteria in the draft policy are subjective to > some degree. At the same time the policy leaves zero margin for error (If X > then you MUST use this code, otherwise you MUST NOT). The combination of > these two seems to ensure that mistakes will happen, and we will see a > continuous stream of incident reports where a CA and a community member > disagrees about a subjective aspect of these criteria. Could the policy be > updated to give the CA freedom to choose in gray areas? > > > > Doug: I don’t have an opinion on that one because I don’t tally understand > which subjective statement you’re referring to. > > > > > > There have already been several posts in this thread discussing if a CSR > can be considered proof of possession of a private key. I don't think a CSR > is secret and therefore cannot automatically be considered proof of > possession, and I think the policy should state that explicitly. > > > > Doug: If the CSR contains all SAN values in the issued certificate (and > the certificate has the same public key as that CSR), then that binds the > key to the domains and I believe this is sufficient POP. If this is not > the case when the CSR is provided prior to issuance, a CA could ask the > subscriber for a new CSR with all of the SANs (and same public key) as PoP > during a request for revocation. I’d be interested to know if others agree > with this. > > > > > > > > The policy says revocations before the effective date does not need to be > changed. What about revocations after the effective date? What if a > certificate was revoked as superseded and later the CA receives evidence of > key compromise? Must the reason code then be changed? > > > > Doug: It’s my understanding that once a certificate is revoked and put on > a CRL, you can never change the reason code.. > > > > > > > > Den tir. 1. feb. 2022 kl. 19.04 skrev Kathleen Wilson <[email protected] > >: > > I have re-written the bright green text in the draft policy > <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> > to separate out the scope of revocation from the requirement to use the > keyCompromise reason. > > > > So the proposed text is as follows: > > == > > 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 requests that the CA revoke the certificate > for this reason. > > > The scope of revocation depends on whether the certificate subscriber has > proven possession of the private key of the certificate. > - If the certificate subscriber has previously demonstrated or can > currently demonstrate possession of the private key of the certificate, > then the CA MUST revoke all instances of that key across all subscribers. > - Otherwise, the CA SHOULD limit revocation to only the instance of that > key that the certificate subscriber had submitted the Certificate Signing > Request (CSR) for. > > == > > > > I will continue to appreciate your feedback on this, and especially your > input on how to make this more accurate. > > > > Thanks, > > Kathleen > > > > > > -- > 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/24a3a885-dfd3-45f1-a5aa-9928c89fe6c1n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/24a3a885-dfd3-45f1-a5aa-9928c89fe6c1n%40mozilla.org?utm_medium=email&utm_source=footer> > . > > -- > 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/CACAF_WgAmV1uopbEKAEmW0n6kwyTSKaT-HegsYjbJsbJET_gXg%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WgAmV1uopbEKAEmW0n6kwyTSKaT-HegsYjbJsbJET_gXg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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/PUZPR03MB61291B7C47429DB6E6726857F0279%40PUZPR03MB6129.apcprd03.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB61291B7C47429DB6E6726857F0279%40PUZPR03MB6129.apcprd03.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEmnErdPQ_We8AV%2Biw-LmqqVfmw3okRSTTjPGaTdNna-baOAww%40mail.gmail.com.
