Summary of some OCSP client tests: - `Root` is self signed, and does not have any EKU's - 'ICA' is signed by 'Root' with the EKU ServerAuth and ClientAuth - 'ICA 2' is signed by 'Root' with the EKU ServerAuth, ClientAuth and OCSPSigning - 'Server certificate' is signed by `ICA` with the EKU ServerAuth and ClientAuth - Both `ICA 2` and `ICA` have their own delegated OCSP responder certificate. - `ICA 2` signs an OCSP response for `ICA` and overrules the response created by the delegated responder.
certutil (Windows): Recognizes but rejects the revoked response openssl (Ubuntu & MacOS): Accepts the response ocspcheck (MacOS): Accepts the response Output and script located on: https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d On Mon, 6 Jul 2020 at 12:09, Dimitris Zacharopoulos <ji...@it.auth.gr> wrote: > On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy > wrote: > > As follow up to Dimitris comments I tested the scenario where a > > sibling issuing CA [ICA 2] with the OCSP signing EKU (but without > > digitalSignature KU) under [ROOT] would sign a revoked OCSP response for > > [ICA] also under [ROOT] > > https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d > > > > I was actually surprised to see that certutil fails to validate decode > the > > OCSP response in this scenario. But this doesn't say it's not a problem > as > > other responders or versions might accept the response. > > > > I will try to perform the same test on Mac in a moment. > > Thank you very much Paul, this is really helpful. > > Dimitris. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
