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] <mailto:[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] <mailto:[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/PUZPR03MB6129AC5BB6EC14FA7C4B9062F0229%40PUZPR03MB6129.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
