There's some related technical background in this 2014 bug report on Firefox rejecting a TLS server certificate issued by such an intermediate CA with the problematic 'OCSP Signing' EKU: https://bugzilla.mozilla.org/show_bug.cgi?id=991209#c7
The problem with intermediate CAs with the 'OCSP Signing' EKU being able to sign OCSP responses for any sibling certificates issued by the root CA seems to have been recognized for a while. But in this case, Mozilla allowed and ignored the 'OCSP Signing' EKU for vendor interop with existing intermediate CAs. Mozilla products would reject such OCSP responses, but the CA policy on issuing intermediate CA certificates with the 'OCSP Signing' EKU was not fixed.
The situation seems to be that the MSADCS policy on requiring the 'OCSP Signing' EKU on the intermediate CA certificate is incorrect, and clients validating OCSP responses signed by a delegated OCSP responder certificate do not require the 'OCSP Signing' EKUs on the issuing (intermediate/root) CA certificate(s): https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
This is in contrast to e.g. the TLS serverAuth EKU, where these EKUs chain: a technically constrained CA certificate must have a TLS serverAuth EKU in order to issue end-entity certificates with a TLS serverAuth EKU.
The 'OCSP Signing' EKU on the intermediate CA certificate is unnecessary: the intermediate CA does not need the EKU to sign OCSP responses directly, nor to issue a delegated OCSP responder certificate with the 'OCSP Signing' EKU. The unnecessary 'OCSP Signing' EKU on the intermediate CA certificate is harmful, because it may be interpreted as a delegated OCSP responder certificate for the issuing root CA, capable of signing OCSP responses for any certificate issued by the root CA.
The workaround for MSADCS is to use an untrusted CA certificate (e.g. self-signed) with the same public key and subject DN as the intermediate CA to issue the OCSP responder certificate, adding the 'OCSP Signing' EKU to both the OCSP responder certificate and the workaround-CA. The resulting OCSP responder certificate with the 'OCSP Signing' EKU will validate as an OCSP responder certificate for the actual intermediate CA, without including the 'OCSP Signing' EKU in the CA certificate.
This BR policy violation approach seems to be an attempt to highlight the security problems and fix this long-standing issue, limiting the use of the 'OCSP Signing' EKU in order to protect clients from OCSP responses signed by intermediate CA certificates that were not intended to be delegated OCSP responder certificates for their root CAs.
The problem with intermediate CAs with the 'OCSP Signing' EKU being able to sign OCSP responses for any sibling certificates issued by the root CA seems to have been recognized for a while. But in this case, Mozilla allowed and ignored the 'OCSP Signing' EKU for vendor interop with existing intermediate CAs. Mozilla products would reject such OCSP responses, but the CA policy on issuing intermediate CA certificates with the 'OCSP Signing' EKU was not fixed.
Specifically, MSADCS (Microsoft software used to issue certificates) requiring the CA certificate to have the 'OCSP Signing' EKU, "by design": https://support.microsoft.com/en-us/help/2962991/you-cannot-...
The situation seems to be that the MSADCS policy on requiring the 'OCSP Signing' EKU on the intermediate CA certificate is incorrect, and clients validating OCSP responses signed by a delegated OCSP responder certificate do not require the 'OCSP Signing' EKUs on the issuing (intermediate/root) CA certificate(s): https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
This is in contrast to e.g. the TLS serverAuth EKU, where these EKUs chain: a technically constrained CA certificate must have a TLS serverAuth EKU in order to issue end-entity certificates with a TLS serverAuth EKU.
The 'OCSP Signing' EKU on the intermediate CA certificate is unnecessary: the intermediate CA does not need the EKU to sign OCSP responses directly, nor to issue a delegated OCSP responder certificate with the 'OCSP Signing' EKU. The unnecessary 'OCSP Signing' EKU on the intermediate CA certificate is harmful, because it may be interpreted as a delegated OCSP responder certificate for the issuing root CA, capable of signing OCSP responses for any certificate issued by the root CA.
The workaround for MSADCS is to use an untrusted CA certificate (e.g. self-signed) with the same public key and subject DN as the intermediate CA to issue the OCSP responder certificate, adding the 'OCSP Signing' EKU to both the OCSP responder certificate and the workaround-CA. The resulting OCSP responder certificate with the 'OCSP Signing' EKU will validate as an OCSP responder certificate for the actual intermediate CA, without including the 'OCSP Signing' EKU in the CA certificate.
This BR policy violation approach seems to be an attempt to highlight the security problems and fix this long-standing issue, limiting the use of the 'OCSP Signing' EKU in order to protect clients from OCSP responses signed by intermediate CA certificates that were not intended to be delegated OCSP responder certificates for their root CAs.