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] <mailto:[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 <http://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] <mailto:[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] <mailto:[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] <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_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.
smime.p7s
Description: S/MIME cryptographic signature
