Questions re: Upcoming changes to revocation reasons

If you have any questions regarding the announcement below, feel free to ask and discuss them here.

5 Likes
  1. How does signing a revocation request with the certificate private key "demonstrate a compromise" of that key?

How is it different from the private key being used by a web server to establish a TLS session with a browser?

  1. "All requests for revocation which are authenticated using the key of a Subscriber who did not originally order the certificate, but who has demonstrated control over all names in that certificate"

vs later

"So we will interpret a request of this kind as "evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate", and use the reason "cessationOfOperation" instead."

Should one of "all names" / "all of the domain names" say "any" rather than "all"?

4 Likes

We have no way to know who made the request to revoke -- all we know is that the request was signed using the certificate's private key. Whoever is making the request to revoke wants us to know that they control the private key. Therefore we must assume that it has been compromised.

Obviously yes, this assumption is faulty. There are many situations in which the original Subscriber makes a request to revoke the cert and uses the cert's private key instead of their own Subscriber key to authenticate that request (heck, there are some ACME clients which always use this method to request revocation, regardless of the reason). But from the ACME server side, we have no way to know, so it behooves us to assume the worst.

No, revocation via this authentication mechanism only works when the requesting Subscriber who controls all of the names in the certificate in question.

4 Likes

I'm not sure why that assumption must be made. Mozilla requires overwriting the requested reason only when there is verifiable evidence of compromise. The fact that someone has the key does not demonstrate compromise. If anything, the fact that a revocation request is being submitted with a different (or no) reason is evidence against key compromise.

That reads to me as though a subscriber who controls all names must be allowed to revoke the certificate, but it does not rule out allowing a subscriber who controls some incomplete subset to do so.

6 Likes

I'm not sure this is allowed in the current baseline requirements? 4.9.1.1 item 3 states:

  1. The CA obtains evidence that the Subscriber’s Private Key corresponding to the
    Public Key in the Certificate suffered a Key Compromise;

If I revoke my cert with keyCompromise, how is that not "evidence"? The BR do not state I need to "demonstrate" controle over the key. It just states "evidence". And I think the revocation reason keyCompromise is evidence enough?

6 Likes

Everything @aarongable mentioned in the news posting noted this clause:

For Client Developers, does that mean we generally do not need to worry about updating our clients in the foreseeable future, and it will be acceptable for quite some time to submit an inapplicable/alternative reason (even though LetsEncrypt will ignore it and log the reason in accordance with these new guidelines)? Past actions by ISRG and the goal of continuous automated renewals lead me to believe this interpretation is correct, but I'd like to be sure no actions by developers are necessary.

6 Likes

This is correct. However, we have a long-standing policy of not allowing a Subscriber who controls only some of the names on a certificate to revoke that certificate -- doing so effectively leads to denial of service attacks. That policy is not changing.

Recall that a Subscriber is not required to prove control over the private key corresponding to the public key in the certificate that they order. So it is possible that a malicious Subscriber could observe the public key in a target's certificate, request their own certificate containing the same public key, and then revoke their own certificate with reason keyCompromise. Under your interpretation, this would require us to revoke the target's certificate as well, even though its private key has not actually been compromised. This is a denial of service attack, and this is why we require that the revoker demonstrate control over the private key in order for the revocation to propagate to other certificates that share the same key.

Yes. Although we do completely reject revocation requests for inapplicable reasons (such as "cACompromise", which a Subscriber is not allowed to assert), revocation requests for all of the allowed reasons ("unspecified", "keyCompromise", "superseded", and "cessationOfOperation") will continue to succeed, with the reason code silently overwritten if necessary.

7 Likes

Wonderful! Thank you!

4 Likes

I'm now wondering which grounds of the BR mandate a CA to revoke all certificates with a certain public key when the private key has been leaked. If that ground is also 4.9.1.1 sub 3, then the BR do not require demonstration of the leakage, but evidence is enough.

Also, how would you be able to issue a certificate with a certain public key, if you don't have the private key? AFAIK the CSR needs to be signed with the private key and this is checked by the CA. Although technically I can't see this requirement in the BR :roll_eyes: Maybe my searc-FU isn't good enough or it isn't required..

4 Likes

See What could Let’s Encrypt do to make client dev easier? - #24 by petercooperjr

4 Likes

Yes, it's possible, as apparently the signing of a CSR with the private key or other proof of posession of the private key isn't mandated by the BR, but LE does mandate it by only allowing self-signed CSRs. So while not always the case, in the case of LE, getting a cert with a certain public key also requires access to the accompanying private key. Therefore, still in at least the case of LE, the denial of service attack mentioned by @aarongable isn't viable.

5 Likes

Yeah, I'm with @Osiris on this as well. I'm guessing the scenario they're trying to consider is one where an "attacker" has a CSR but not the private key itself, which is in theory possible since CSRs only have "public" information so they might get "leaked" more readily. Or something like that.

4 Likes

But the CSR would also include the specific hostname(s), so that's no dice in almost certainly ever circumstance. It's almost impossible to have the possibility to validate random hostnames and it would be a heck of a coincidence you just happen to have controle over the hostname somehow. Modyfing the CSR would also invalidate the signature (at least now that SHA-1 is forbidden :stuck_out_tongue:)

4 Likes

CSRs are not considered private information, and are frequently posted online (including in this support forum!) or left somewhere visible to the public. Possession of a CSR is explicitly not equivalent to proof of control over a private key:

MRSP 6.1.1 End Entity TLS Certificate CRLRevocation Reasons: keyCompromise
A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation.

A very common circumstance is the purchase of a domain name. Suppose that someone owns thousands of domains, and uses the same key in all of the individual certs for every domain that they own. Suppose further that I purchase one of those domains from them. Then I could copy their CSR for that domain, request issuance using that CSR, revoke my own cert for reason keyCompromise, and thereby revoke all of their other certificates.

6 Likes

As I understand a CSR is just a Public Key plus some meta data that the CA signs and returns as Certificate that has the Public Key and more meta data (and some meta data removed).

4 Likes

Approximately correct. They are just a public key plus some metadata, but hopefully the CA doesn't just sign it and return it as a certificate -- that way lies misissuance :slight_smile: For Let's Encrypt's purposes, they're essentially just a transport format for a public key. The only other pieces we care about are the must-staple extension and ensuring that the list of names matches the original order, but neither of those is carried directly into the final certificate.

4 Likes

Obviously, I was only referring to the content of the CSR and Cert. Not the certification process itself.

3 Likes

Sorry, what I meant was, the current wording seems contradictory. Although re-reading, maybe it's just ambiguous.

I read A as referring to non-original subscribers who demonstrate control over all names. (easy)

But I read B as referring to original subscribers who no longer control all of the names. To me, that means 'who controls none, or some, but not all, of the names' rather than the implied opposite of A, which would be 'who controls none of the names'. (Or, using wording closer to the original, 'who no longer controls, or is no longer authorized to use, any of the domain names in the certificate.')

3 Likes

I can see how this can be confusing. I've spend too much time on Patents, so maybe this slight edit of @aarongable's text is more clear:

All requests for revocation which are authenticated using the key of a Second Subscriber, who did not originally order the certificate but who has demonstrated control over all names in that certificate, will result in the certificate being revoked with reason "cessationOfOperation", regardless of the requested reason. This is because the new requirements state that the various allowed revocation reasons MUST only be used when the CA has a specific reason to use them (as with "keyCompromise" above) or when the certificate’s Subscriber (the First Subscriber) requests them. But in this case, someone other than the certificate Subscriber (the First Subscriber) is requesting revocation - the Second Subscriber is. So we will interpret a request of this kind as "evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all [each and every one of] of the domain names in the certificate", and use the reason "cessationOfOperation" instead.

6 Likes

Is there an explanation somewhere for how that would work?

1 Like