Rob, Can you help me understand the threat model a bit more?
If Alice signs a CSR for good.example, doesn’t that demonstrate some degree of binding between good.example and that key? If Alice becomes a Subscriber with that CSR, she has demonstrated a POP in the context of good.example. Let’s say Eve obtains that CSR. Unless Eve can demonstrate control of good.example, then she, as a Subscriber, hasn’t demonstrated a POP in the context of good.example, has she? That is, I _think_ what you’re hinting at is something similar to what Doug was touching on, but a little bit different. Namely, - If Eve can use the CSR (that asserts good.example) for evil.example, then Eve shouldn’t be assumed to have demonstrated control - If the CSR lacks any such binding to a domain, and lacks any CA challenge string (ala the Onion approach), then neither Eve nor Alice should be assumed to have demonstrated control However, I’m not sure why a CSR, signed for good.example, and used by the Subscriber with whom a good.example certificate was issued to, wouldn’t be sufficient for POP. Am I missing something obvious? On Thu, Feb 3, 2022 at 7:20 PM Rob Stradling <[email protected]> wrote: > tl;dr A CSR is not sufficient proof of possession; but even if it was, > it's not sufficient proof of intent. > > > Jesper wrote: > > 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. > > +1 > > A CSR's self-signature proves only that the corresponding private key was > in the possession of whoever generated that CSR. It doesn't prove that it > was the Subscriber who generated that CSR, and I would say that "suspicion > of CSR generation" is a weak signal. 😉 > > I think it's also important to look carefully at what a CSR is intended > for. It's a Certificate Signing Request, not a Certificate Revocation > Request. In general, whoever generated a CSR did not, at the time it was > generated, intend that CSR to be used as proof of key compromise; and since > CSRs are immutable and are sometimes made public (i.e., "CSR compromise" is > not a thing), it would be dangerous to later treat a vanilla CSR as proof > of key compromise. > > I think that to actually prove key compromise to the CA, a Subscriber or > third party would need to do one of the following: > > 1. Self-sign some sort of "Key Compromise Request" (KCR) that a CA can > unambiguously treat as a declaration of key compromise by a holder of that > key. Ideally a KCR would be a new type of object that can't be parsed as a > CSR (e.g., see > https://secure.sectigo.com/products/RevocationPortalDetails?action=2a); > or, as some folks have done, a KCR could be a CSR that contains some sort > of textual indication of intent such as "subject:CN=This CSR is intended to > prove key compromise". > 2. Send the private key to the CA. > > > Doug wrote: > > 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. > > -1 > > If a CSR "contains all SAN values", it just means that whoever generated > that CSR wanted to Request the Signing of one or more Certificates > containing those SAN values. > > ------------------------------ > *From:* 'Doug Beattie' via [email protected] > *Sent:* Wednesday, February 02, 2022 17:02 > *To:* Jesper Kristensen; [email protected] > *Cc:* Kathleen Wilson > *Subject:* RE: Revocation Reason Codes for TLS End-Entity Certificates > > 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/MW4PR17MB4729D4D09BE56D01C28C249FAA289%40MW4PR17MB4729.namprd17.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729D4D09BE56D01C28C249FAA289%40MW4PR17MB4729.namprd17.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/CAErg%3DHH4C7ahu4yqK59rmtRP8cPLFZCwfVsSwtmtsk%2BUtHHVLA%40mail.gmail.com.
