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.
