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
