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.


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

Reply via email to