On Fri, Feb 4, 2022 at 9:38 AM Corey Bonnell <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/CAErg%3DHFgczDA5i-m%2BFiJAV1WfD3Guh1gGpWXTaJs3LaJGsE9Zw%40mail.gmail.com.
