Hi Ryan, I agree with Rob that a CSR contains all the SANs of a certificate request is not necessarily sufficient PoP. A bit of PKI fan fiction to illustrate:
Assume that a Subscriber, a company named Foobarbaz, Ltd., has a TLS certificate for foobarbaz.com. A marketing director for Foobarbaz catches wind of a hot deal on gTLD domain registrations and instructs IT to purchase registrations for 100 or so domains and setup mirrors of their corporate website on each of those domains. In preparation, IT creates 100 CSRs with the same key pair as the original corporate website’s certificate (because a single 100 SAN cert is “too big”); each CSR has a single SAN dNSName corresponding to the new domain name to be purchased. Right before IT goes to purchase the domains, the marketing director also learns that the hot deal isn’t so great as the renewal fee for those domains “will bankrupt the @!$%^ company!” (their words, not mine). So, IT never follows through on purchasing the domains. Fast forward a few months later, the IT person gets a bit overzealous with “git add” and uploads the 100 CSRs to GitHub. A disgruntled customer of Foobarbaz, still steaming at the company for their bad customer service after Foobarbaz shipped them a broken widget toy for their kid’s birthday, comes across these publicly available CSRs and downloads them. The hot deal on gTLD domains is still ongoing, so they pay the $0.88 and register one of the domains Foobarbaz was going to register but never carried through. They create an account at the same CA that issued the original foobarbaz.com and submit the CSR for their newly registered domain and complete DCV. The certificate gets issued, and they immediately request revocation. Since the CA believes that submission of a CSR with all the SANs constitutes PoP, they also revoke the certificate for foobarbaz.com since the two certificates share a public key. Foobarbaz.com is now unreachable, and our villain goes to bed with a grin on their face. There are mitigations that the CA can put in place to lower the chances of that from happening (such as binding a submitted public key to a specific Subscriber account), but even that may be flawed since it’s essentially TOFU (the first Applicant to submit the CSR “wins”). Given these concerns, I don’t think it necessarily follows that a CSR that contains all SANs of a given certificate request constitutes PoP in all cases. Thanks, Corey From: [email protected] <[email protected]> On Behalf Of Ryan Sleevi Sent: Thursday, February 3, 2022 7:51 PM To: Rob Stradling <[email protected]> Cc: Doug Beattie <[email protected]>; Jesper Kristensen <[email protected]>; Kathleen Wilson <[email protected]>; [email protected] Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates 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] <mailto:[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> 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 <mailto:[email protected]> [email protected] Sent: Wednesday, February 02, 2022 17:02 To: Jesper Kristensen; <mailto:[email protected]> [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] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Jesper Kristensen Sent: Wednesday, February 2, 2022 11:41 AM To: [email protected] <mailto:[email protected]> Cc: Kathleen Wilson <[email protected] <mailto:[email protected]> > Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates You don't often get email from <mailto:[email protected]> [email protected]. <http://aka.ms/LearnAboutSenderIdentification> Learn why this is important 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] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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] <mailto:[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 <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHH4C7ahu4yqK59rmtRP8cPLFZCwfVsSwtmtsk%2BUtHHVLA%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/BN7PR14MB2178458A8A643A45390FAC9192299%40BN7PR14MB2178.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
