Hi Doug, I wasn’t trying to require POP, just limiting the the capabilities without POP. I definitely believe subscribers should be able to request for their certificates without any POP.
On Fri, Jan 28, 2022 at 9:46 AM Doug Beattie <[email protected]> wrote: > Hi Ryan and Kathleen > > > > I read Ryan’s email (below) and also the Mozilla draft policy located here > > > https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit#heading=h.nyvo79h06g28 > > > > and I think there is an inconsistency being introduced in this latest > Mozilla policy draft statement: > > > > ** If the certificate subscriber has not previously provided and can no > longer provide proof of possession of the private key, they may still > request revocation due to keyCompromise, and that revocation SHOULD be > limited in scope to only the certificate issued to that certificate > subscriber, even if the key in the CSR is used by other certificates. > > > > The Mozilla policy permits revocation for key compromise even if the > applicant has not and cannot demonstrate proof of possession, but Ryan’s > comments requires proof of possession (when requesting or when revoking). > > > > Do we need to tighten up the Mozilla policy to align with the requirement > to demonstrate proof of possession? > > > > Doug > > > > > > > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Ryan Sleevi > *Sent:* Friday, January 21, 2022 3:02 PM > *To:* Ryan Sleevi <[email protected]> > *Cc:* Kathleen Wilson <[email protected]>; > [email protected]; [email protected] <[email protected] > > > *Subject:* Re: Revocation Reason Codes for TLS End-Entity Certificates > > > > > > > > On Thu, Jan 20, 2022 at 8:19 PM Ryan Sleevi <[email protected]> wrote: > > If the goal is to ensure that key compromise is only used if: > > A) The Subscriber wants it (i.e. not by the CA as part of a contract > dispute or part of some other policy or business practice detrimental to > end users) > > B) The key was compromised (even if the Subscriber doesn't want it revoked) > > > > then it seems like changing bullet #5 to simply being that the Subscriber > requests the revocation with keyCompromise should be sufficient? > > > > One thing that was pointed out to me off-list is the fact that TLS > issuance doesn't require a demonstration of key control to go from > Applicant -> Subscriber (e.g. CSR validation is not required). That's > because for TLS, we're obtaining evidence that the domain holder > _authorized_ the key, not necessarily that the domain holder _holds_ the > key. Yes, I'm aware, there are plenty of debates to be had about this > point, but at least this reflects the long-standing practices, > expectations, and assurances, so hopefully we can agree that it's at least > how the system works today. > > > > Thus, under today's scenario, this introduces an interesting possibility. > > - Alice creates a CSR for good.example, using Key 1 > - Alice applies at CA Foo with their CSR, becoming an Applicant. After > demonstrating control over good.example, Alice becomes a Subscriber > - The CSR for Alice is by no means a secret, or toxic, asset - it's > merely a statement of the request. Alice happens to leave their CSRs on > GitHub, because why not? > - Eve is up to no good, and wants to start making trouble in the > neighborhood. Eve obtains a copy of Alice's CSR, and applies to CA Foo, but > this time, for evil.example > - Because the CA does not check / use the attributes from the CSR, but > instead uses their (API || Web Form), the CSR is not really bound to any > request. After all, it's not a proof of possession instrument, just a way > of conveying an authorized key. > - Eve is able to complete any necessary challenges for evil.example, > authorizing Key 1 to be used with Eve's domain. > > > - Yes, this means Alice "could" MITM Eve, but recall, Eve is up to > shenanananigans > > > - Eve, as Subscriber, requests that CA Foo revoke evil.example{Key 1} > for Key Compromise > - CA Foo, on receiving the request, revokes the certificate for > evil.example. > - CA Foo then examines their systems, and sees that Key 1 is *also* used > by Alice's good.example certificate - and revokes that as well > - Eve has now managed to deny service to Alice, by using the policy > for abuse > > The proposed language from Kathleen in the present form is basically > performing a proof of key possession at revocation request time, since it's > not guaranteed to have been performed at issuance time. > > > > Watson's observation, and my critique, was that at the time revocation is > needed, this may not be possible, and that just raises barriers for > Subscribers at that point. > > > > I think it's fair to observe that, in order to have the cascading effect, > there's a good argument for wanting to have some proof of possession of the > key being held, at *some* point, in order to do such a cascading > revocation. Whether that's at issuance time (e.g. the CA uses the CSR or, > like some CAs, ACME, to do a PoP/authorization check), or at revocation > time (as the policy current proposes), there are only a few mitigations for > Eve's abuse. > > > > An alternative approach would be to scope the degree of cascade for a key > compromise revocation - where Eve's certificate is revoked (based on Eve's > self-attestation), but Alice's is left unharmed unless/until Eve, or any > other party, can actually demonstrate the proof of compromise. This scopes > the harm, but does open up interesting subtleties around ensuring that CAs > are actually performing the correct cascades. > > > > Those are the four mitigations I could figure out, namely: > > - Check POP at issuance time > - Check POP at revocation time > - Scope keyCompromise revocations without POPs to the requesting > Subscriber > - Use a separate POP for keyCompromise revocation (e.g. account key / > revocation keys, as with ACME) > > But perhaps there are more worth considering that I've overlooked? > > > > The current language adopts the "at revocation time", but I'd be worried > that sets up the "surprise tax" that when it's time for revocation, you > don't realize you can no longer do the thing you should have done sooner. > Based on CA delayed revocations due to subscriber surprises, I'd be worried > about exacerbating the server-operator-surprise factor, and so "it'd be > nice" to have it done at issuance time. But that's also a rather > significant ecosystem change to accomplish, because it involves not just > CAs, but every Applicant making a change, and potentially changes to > issuance protocols/practices, and it's a fairly extensive "tax" on > productivity if the only benefit/need is for revocation. > > -- > 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%3DHG4Rd3LPSVc5RQ%2BZJUtOfhJCDW%2B7tjTxy0YcHpOgeDb4w%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG4Rd3LPSVc5RQ%2BZJUtOfhJCDW%2B7tjTxy0YcHpOgeDb4w%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%3DHEK7y0Qy18t6SafrO0N-wYa6H%3DTN1-Xc%2BzONot_AsTMHg%40mail.gmail.com.
