as clients may want to reuse csr for renewal (like some key pinning), wouldn't it better to bind csr to acme account? or like only allow first acme account that used that csr(hash entire csr file) considered have POP내 Galaxy에서 보냄 -------- 원본 이메일 --------발신: "'Aaron Gable' via dev-security-policy@mozilla.org" <dev-security-policy@mozilla.org> 날짜: 22/2/8 03:31 (GMT+09:00) 받은 사람: Doug Beattie <doug.beat...@globalsign.com> 참조: r...@sleevi.com, Matthew Hardeman <mharde...@gmail.com>, Jesper Kristensen <jesperm...@gmail.com>, dev-security-policy@mozilla.org 제목: Re: Revocation Reason Codes for TLS End-Entity Certificates 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.AaronOn Mon, Feb 7, 2022 at 4:46 AM 'Doug Beattie' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> 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: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Ryan SleeviSent: Saturday, February 5, 2022 7:56 PMTo: Matthew Hardeman <mharde...@gmail.com>Cc: Jesper Kristensen <jesperm...@gmail.com>; Ryan Sleevi <r...@sleevi.com>; dev-security-policy@mozilla.orgSubject: 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 <mharde...@gmail.com> 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 <jesperm...@gmail.com> 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 <r...@sleevi.com>: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 "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/CACAF_WiQmexceytd6zGNDDV_E24XfOQX-_QuTE-3yBZzrJc0SA%40mail.gmail.com.-- 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%3DHHroicfQk4dW2-AeSu%3DamR9YnKumN%3DGJgWx5yygXNVvGQ%40mail.gmail.com.
-- 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/PUZPR03MB6129EB7D6B26F466C8CACED8F02C9%40PUZPR03MB6129.apcprd03.prod.outlook.com. -- You received this message because you are subscribed to a topic in the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/RVFnJJRuUag/unsubscribe. To unsubscribe from this group and all its topics, 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/CAEmnErc328gH8tAuQtd9nRY6F0JO2BHVvmt8K3cTQz8jq0tPwQ%40mail.gmail.com. -- 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/620180aa.1c69fb81.96294.2250%40mx.google.com.
