Comment by filleokus | Hacker News Reader

Comment by filleokus | Hacker News Reader

> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST include an id-pkix-ocsp-nocheck extension.

>For example, consider a certificate like https://crt.sh/?id=2657658699 . This certificate, from HARICA, meets Mozilla's definition of "Technically Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However, because it includes the OCSP Signing EKU, this certificate can be used to sign arbitrary OCSP messages for HARICA's Root!

>This also applies to non-technically-constrained sub-CAs. For example, consider this certificate https://crt.sh/?id=21606064 . It was issued by DigiCert to Microsoft, granting Microsoft the ability to provide OCSP responses for any certificate issued by Digicert's Baltimore CyberTrust Root. We know from DigiCert's disclosures that this is independently operated by Microsoft.

So my understanding is this: The CA's have issued certificates/sub-CA certs without the proper extension (or with too many extensions), causing those to be able to sign a OCSP response. And the Online Certificate Status Protocol (OSCP) is used to check the revocation status of certificates with the CA.

So, this would allow e.g Microsoft to generate a fake OCSP response? That would perhaps be useful in some kind of MITM-attack scenario?

While not good, perhaps not an end of the world problem either? However, I wonder how much problem will come for people needing to replace those soon to be revoked sub-CA certs...

Many of the violations discussed on the security lists are not end of the world at all. The 63-bit instead of 64-bit serial number entropy issue is a good example of this. But the strict enforcement of all violations makes it easier to spot bad actors or at least those who aren't competently handling all of the requirements to be a CA. Bottom line: the entire CA system is built on trust.

Would you trust someone who doesn't take issues seriously because they think they're small or unimportant?

EDIT: reading the full report, it seems that the underlying risk is that if one of the intermediate CAs were to be compromised, even if it was revoked it could theoretically forge an OCSP response that it is still valid (and as a trusted CA issue certs for anything). So the response is very appropriate given the potential impact.

The nocheck thing confused the hell out of me.

As I understand it: the issue isn't the nocheck; it's where the OCSPSigning EKU is. You're supposed to see OCSPSigning on end-entity (CA:NO) certificates; the purpose of the EKU is to delegate a non-CA cert the authority to revoke certificates for its parents. When you see that EKU on a CA:TRUE cert, what you're really seeing expressed is that CA's parent delegating OCSP for the root; ie, the CA is granting its customer the right to control revocation for the whole CA.

What nocheck expresses is: "you can't trust this OCSP Delegated Responder to revoke itself, because that's silly; seek confidence in its validity elsewhere". "Elsewhere" apparently usually means "the fact that this certificate has a very short lifetime", which is feasible for an end-entity cert but not so much for a CA.

My understanding is that nocheck (or, lack of it) is how Ryan spotted these certificates, but isn't really the big problem with them.

If intermediate certificate private key leaks, basically you can block revocation. As you can sign OCSP message with this certificate. Kinda defeats purpose of revocation.

But as far as I know, browsers are not failing hard on OCSP failure, if you can mitm the connection possibly you can block OCSP requests too.

The author claims it’s a problem because one sub-CA can effectively un-revoke its own certificate and certificates from other sub-CAs. That’s bad because it defeats the most important purpose of revocation.

If someone compromises a key, typically, you would want to revoke it. However, if that key also allows to revocation to be reversed, you’re in trouble.

I’ve explained more in a top-level comment: https://news.ycombinator.com/item?id=23747524

Reply on news.ycombinator.com