It seems clear to me that a CSR cannot be proof of possession. It doesn't require a poorly-behaving reseller or RA. It just requires that a subscriber both a) upload their CSR somewhere, and then b) allow their domain registration to lapse. Then some other actor can register the same domain and re-use the public CSR to request issuance. The domain registrar, hosting provider, RA, and CA have all done everything by the book, but the latter actor does not have possession of the key in that CSR.
The issue here is fundamentally that CSRs are not bound to a time. They contain no indicator of when or in what context they were signed. Brainstorming here: what if the ACME protocol were augmented to say that the CSR submitted in a Finalize Order request should contain a new extension (say, `acmeOrder`) whose value is the unique "finalize url" contained within the order object being finalized. This would bind the CSR to an Order, which can only be finalized once, and so would immediately show if a CSR was being re-used from a previous issuance. (Including an extra extension in the CSR should be unproblematic because it is widely accepted that CAs should not blindly copy extensions from a CSR to the final certificate.) Do we think this slightly-modified CSR would count as sufficient proof of possession? Non-ACME CAs could use similar techniques to encourage subscribers to include unique values in their CSRs at issuance time as well. Aaron On Mon, Feb 7, 2022 at 4:46 AM 'Doug Beattie' via [email protected] <[email protected]> wrote: > Picking up a CSR from a repository or public location and submitting that > to a CA as POP is certainly a bad idea for the reasons already discussed, > but if the CA can confirm that the Subscriber is supplying it (or supplied > it with their cert request), can’t that be used as POP? For example, > within an enterprise account where an Enterprise RA could provide the CSR > post issuance (or ideally the CSR with all the SANs to be used for > issuance). Wouldn’t that work? > > > > > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Ryan Sleevi > *Sent:* Saturday, February 5, 2022 7:56 PM > *To:* Matthew Hardeman <[email protected]> > *Cc:* Jesper Kristensen <[email protected]>; Ryan Sleevi < > [email protected]>; [email protected] > *Subject:* Re: Revocation Reason Codes for TLS End-Entity Certificates > > > > I’m not sure - was that question directed at me? > > > > Hopefully it’s clear why I’m concerned about that, but the proposal being > made makes me think that may not be clear? Specifically, this introduces > the “hoop jumping” concern and shifts the burden to every Subscriber to do > something new and different, versus the status quo today, and that seems a > serious step back. > > > > On Sat, Feb 5, 2022 at 5:23 PM Matthew Hardeman <[email protected]> > wrote: > > Rather than accept the presentation of any arbitrary CSR over a given key > as proof of possession of a key for purposes of revocation request, why not > require that the party purporting possession/control/knowledge of the key > instead create a CSR with a randomly chosen (by CA) value in the CSR > subject like CN=rev-req-01233456789.revoketarget.com? > > > > This is unburdensome in the sense that any party with the key and any > technical capabilities relevant to PKI should be able to perform this task > without any new or additional tooling. It also has the advantage that it > could be part of an automatic protocol if desired, but also could be > implemented in a manual protocol. Further, it introduces no risk to or > from any parties who may previously have treated a CSR as an artifact > requiring no protection. > > > > On Sat, Feb 5, 2022 at 2:58 PM Jesper Kristensen <[email protected]> > wrote: > > I saw someone describe how they reused the key across customers for memory > saving (but still one cert per customer domain) in a help thread on Let's > Encrypt community forums. But I don't know if they were also accepting > customer uploaded certs. I think my main point is that if we decide that a > CSR is POP, we need to start telling people that a CSR needs to be kept > secret, because that is not obvious now, and we can think of scenarios > where someone might share CSRs today, which may be insecure practice in the > future. > > > > Den lør. 5. feb. 2022 kl. 20.24 skrev Ryan Sleevi <[email protected]>: > > Are we just coming up with random hypotheticals here? > > > > Do you know of any provider that does this? > > > > Is there any counter-proposal for how to ensure that Subscribers with > certificates today can reliably revoke their existing certificates? Or are > folks coming up with these scenarios actively rejecting this as a valid > need? > > > > I don’t disagree that, as with anything, we have risks. I think Rob’s > scenario points, somewhat, to the need to curtail domain reuse as narrowly > as possible (hours, not years). > > > > I’d be curious to know what the alternatives folks are proposing, or > whether it really is to tell Subscribers “tough, you’ve got another hoop to > jump through to get these certificates revoked”. Because if we’re willing > to do that, wouldn’t it be better to instead do something like mandate all > CAs support ACME, to at least provide a consistent protocol for this? > > -- > 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_WiQmexceytd6zGNDDV_E24XfOQX-_QuTE-3yBZzrJc0SA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WiQmexceytd6zGNDDV_E24XfOQX-_QuTE-3yBZzrJc0SA%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/CAErg%3DHHroicfQk4dW2-AeSu%3DamR9YnKumN%3DGJgWx5yygXNVvGQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHroicfQk4dW2-AeSu%3DamR9YnKumN%3DGJgWx5yygXNVvGQ%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/PUZPR03MB6129EB7D6B26F466C8CACED8F02C9%40PUZPR03MB6129.apcprd03.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB6129EB7D6B26F466C8CACED8F02C9%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/CAEmnErc328gH8tAuQtd9nRY6F0JO2BHVvmt8K3cTQz8jq0tPwQ%40mail.gmail.com.
