I did do some testing on EKU chaining in Go, but from my understand this works the same for Microsoft:
An OCSP responder certificate with Extended Key Usage OCSPSigning, but an issuing CA without the EKU (result: certificate specifies an incompatible key usage) https://play.golang.org/p/XSsKfxytx3O The same chain but now the ICA includes the Extended Key Usage OCSPSigning (result: ok) https://play.golang.org/p/XL7364nSCe8 Microsoft requires the EKU to be present in issuing CA certificates: *Issuing CA certificates that chain to a participating Root CA must be constrained to a single EKU (e.g., separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case. https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements <https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements> (8)* Technically constraining issuing CA’s based on the EKU as Microsoft requires feels like a good thing to do. But if we leave out the OCSPSigning EKU we must leave out all EKU constraints (and talk to Microsoft) or move away from delegated OCSP signing certificates and all move to CA signed responses. On Thu, 2 Jul 2020 at 14:11, Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > On 02/07/2020 12:52, Pedro Fuentes via dev-security-policy wrote: > > If we look at the BR, it says: > > "[^**]: Generally Extended Key Usage will only appear within end entity > certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate > CAs MAY include the extension to further protect relying parties until the > use of the extension is consistent between Application Software Suppliers > whose software is used by a substantial portion of Relying Parties > worldwide." > > > > Therefore, in my humble opinion it's fully logical to understand this > requirement "as it's written", which is to restrict the CA and protect > relying parties... In other words, the BR is clearly saying that the > meaning of the EKU in SubCAs MUST be understood as a constraint and NOT to > express the EKU of the certificate itself. > > Pedro, > > I think that the problem here isn't what the BRs indicate the reading of > EKUs in a CA certificate should be. > > It's that RFC 6960 (Section 4.2.2.2) states that > > > OCSP signing delegation SHALL be designated by the inclusion of > > id-kp-OCSPSigning in an extended key usage certificate extension > > included in the OCSP response signer's certificate. > > > In other words, if a certificate X (CA or otherwise) contains that EKU > value, by definition, it becomes a valid delegated OCSP responder > certificate, regardless of the intentions surrounding EKU interpretation > in CA certificates. Thus, OCSP responses signed by that X, on behalf of > X's issuing CA, _would_ be properly validated by compliant RP software. > If a hostile party grabs hold of the private key for the CA certificate, > their harm is not limited to the PKI described by the original CA > certificate, but extends to all of the sibling certificates of X > > Now, it's true that the BRs also require the id-pkix-ocsp-nocheck > extension too, but RFC 6960 does not require it (it's just the way to > say "trust this delegated cert for as long as it is valid", and don't > consult OCSP/CRLs). > > Regards, > > Neil > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
