> In this adversarial example, where a rogue CSR is obtained, such as for one > of these BygoneSSL-style expired/unregistered domains, the fundamental > question it seems we’re asking is: is signing a CSR for that name an > authorization for that key to be used with that name?
I have no problem with the idea of treating a CSR that contains SAN(s) as authorization by the key holder for certificate(s) to be issued that contain both the corresponding public key and those SAN(s); but I do have a problem with the idea of later treating that same CSR as authorization by the key holder for the key to be considered proven-compromised just because somebody (who may or may not be the key holder) happens to be in possession of a copy of that CSR. Corey's BygoneSSL scenario isn't the one I was thinking of. My concern is that the nature of a "Subscriber" might not always be as simple as we might like. Consider this scenario: Alice generates a CSR and leaves a copy of it in a public GitHub repository. Alice requests a certificate for her domain by providing the CSR to a certificate reseller, who forwards it to the CA. The CA, who considers the reseller to be the Subscriber, asks the reseller to prove domain control. The reseller works with Alice to prove domain control. The CA issues the certificate. The CA sends the certificate to the reseller. The reseller forwards the certificate to Alice. Alice installs her certificate and expects it to work until expiry. Alice leaves a copy of her CSR in a public GitHub repository. Eve discovers Alice's CSR and grabs a copy of it. Attack 1 (where the CA treats anyone's proof-of-possession of the CSR as equivalent to proof-of-possession of the private key): Eve goes directly to the CA and requests revocation of Alice's cert, selecting Key Compromise as the reason, and presenting Alice's CSR as "proof". The CA accepts this "proof". The CA revokes Alice's cert. Alice is surprised! Attack 2 (where the CA treats only the Subscriber's proof-of-possession of the CSR as equivalent to proof-of-possession of the private key): Eve correctly guesses that Alice obtained her cert via a particular certificate reseller. Eve requests a certificate by providing Alice's CSR to the same certificate reseller, who forwards it to the CA. The CA notices that it already has suitable validation records for this Subscriber (the reseller) that are < 398 days old. The CA issues the certificate (without requiring the reseller to again prove control of Alice's domain name). The CA sends the certificate to the reseller. The reseller forwards the certificate to Eve. Eve can't use the certificate, but that was never her intent anyway. Eve asks the reseller to revoke her cert, selecting Key Compromise as the reason, and presenting Alice's CSR as "proof". The reseller forwards this revocation request to the CA. The CA accepts this "proof". The CA revokes Eve's cert. The CA also revokes Alice's cert, since it has the same key as Eve's cert and belongs to the same Subscriber (the reseller). Alice is surprised! ________________________________ From: Ryan Sleevi <r...@sleevi.com> Sent: 04 February 2022 16:31 To: Corey Bonnell <corey.bonn...@digicert.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; Jesper Kristensen <jesperm...@gmail.com>; Kathleen Wilson <kwil...@mozilla.com>; Rob Stradling <r...@sectigo.com>; dev-security-policy@mozilla.org <dev-security-policy@mozilla.org>; r...@sleevi.com <r...@sleevi.com> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, Feb 4, 2022 at 9:38 AM Corey Bonnell <corey.bonn...@digicert.com<mailto:corey.bonn...@digicert.com>> wrote: 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: I think you may be conflating my remarks with Doug’s? I wasn’t proposing an “all sans” rule, but a “subscriber” rule - see below. 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. To be clear, I was suggesting that the question of “have they proven POP” is about whether the subscriber, who provided the CSR and validated the domain, is the one who initiates the revocation request. In this adversarial example, where a rogue CSR is obtained, such as for one of these BygoneSSL-style expired/unregistered domains, the fundamental question it seems we’re asking is: is signing a CSR for that name an authorization for that key to be used with that name? And, if it is, what privileges are afforded to the Subscriber account? I think you and Rob are arguing either that a) A CSR shouldn’t be seen as authorization for that domain to use that key or b) That zero privileges are afforded and some separate demonstration of control is needed I’m not sure how b would work though, because even systems like bootstrapping a revocation key are still working on the assumption that the entity who presented the CSR and performed the domain validation challenge is authorized to bootstrap said key. If the CSR isn’t the source of that authorization, where does it flow? It would seem that, if we take the CSR out of the mix, you’re looking to bootstrap some form of challenge-response protocol, similar to DNS challenge/response. Which, to be fair, a CSR can be as well, as we saw with .onion. But how well does that align with how the WebPKI works today, and has worked for decades? Is there a connection I’m failing to make here? -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729369B095106D92DA04C3AAA299%40MW4PR17MB4729.namprd17.prod.outlook.com.
