On 04/09/2019 17:14, Ryan Sleevi wrote: > On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson <ben.wil...@digicert.com> wrote: > >> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder >> certificate itself (not the CA that issues the OCSP responder certificate). >> I don't think I've encountered a problem before, but I guess it would >> depend >> on the implementation? > > > Correct. Mozilla does not require the EKU chaining, in technical > implementation or in policy. The aforementioned comments, however, indicate > CAs have reported that Microsoft does. That is, the assertion is that > Microsoft requires that issuing CAs bear an overlapping set of EKUs that > align with their issued certificates, whether subordinate CAs, end-entity, > or OCSP responders. Mozilla requires the same thing with respect to > id-kp-serverAuth, but the Mozilla code has a special carve-out for > id-kp-OCSPSigning that both doesn't require it on intermediate CAs, but > also allows it to be present, precisely because of the presumed Microsoft > requirement. >
This Microsoft requirement is highly unfortunate, because unless there is an explicit RFC permission that allows OCSP clients to reject OCSP certificates from delegated OCSP responder certificates with CA:TRUE, yet accept them from issuing CA certificates with CA:TRUE; clients will be required by RFCs to accept bogus OCSP responses signed by SubCA certificates that contain the EKU for Microsoft compatibility. This is especially bad if the SubCA is controlled by an entity other than its direct parent CA. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
