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.
