On Tuesday, September 10, 2019 at 6:53:47 AM UTC-7, Robin Alden wrote:
> > The aforementioned comments, however, indicate CAs have reported that
> > Microsoft does [require the EKU chaining].
> I agree that statement is true, but I think it inadvertently misleads.
>
> We cannot speak for Microsoft about what their requirements for
> id-kp-OCSPSigning are, and we are not aware of documentation from Microsoft
> that sets out the answer, but we do have experience that sheds some light on
> the matter.
>
> The Scenario
> ===
> We are a root CA.
> In compliance with Mozilla CA policy we signed a constrained intermediate CA
> certificate whose public key corresponded to a private key held by a customer
> organization.
> The constrained intermediate CA was to sign end entity certificates.
> The constrained intermediate CA was not directly to sign OCSP responses, but
> instead was to sign an OCSP responder certificate that would be used to sign
> OCSP responses.
>
> The intermediate CA certificate included an EKU, but the EKU did not include
> id-kp-OCSPSigning.
>
> The first certificate that the intermediate CA was to sign was the OCSP
> responder certificate, and the OCSP responder certificate was to include an
> EKU with id-kp-OCSPSigning.
>
> The Problem
> ===
> The customer was using Microsoft's Certificate Authority platform to issue
> end entity certificates using the Intermediate CA.
>
> The customer found they were unable to issue the OCSP responder certificate
> (including id-kp-OCSPSigning) because the Microsoft CA software would not
> issue such a certificate since the signing CA (i.e. the intermediate CA) had
> an EKU but did not include id-kp-OCSPSigning. I.e. Microsoft's Certificate
> Authority requires EKU chaining.
>
> An 'obvious' solution would have been to re-issue the Intermediate CA
> certificate and include id-kp-OCSPSigning in its EKU. Obviously wrong in
> this case since had we done so the Intermediate CA (i.e. our customer) would
> then have been able to sign OCSP responses for any certificate issued by our
> Root CA.
>
> Another solution would have been to re-issue the Intermediate CA certificate
> and omit the EKU extension altogether but this would have been against policy
> since the BRs require the EKU to be present for a CA to be considered
> technically constrained.
>
> The fix
> =
> The work around was for us to create for our customer a second CA certificate
> that had an EKU including id-kp-OCSPSigning and used the same public key and
> subjectDN as the Intermediate CA certificate, but this time for us to sign it
> with an untrusted CA.
>
> We anticipate that the customer could also have created a self-signed CA for
> themselves using the Intermediate CA key, but did not test that.
>
> The Microsoft CA Platform was then happy to sign an OCSP responder
> certificate including id-kp-OCSPSigning from this second untrusted CA.
> Since the key and subjectDN for the untrusted CA are the same as the key and
> subjectDN of the Intermediate CA certificate, this OCSP responder certificate
> also chains up through the Issuing CA to our trusted root.
>
> The OCSP responder could now be provisioned and the Intermediate CA could
> then begin to issue end entity certificates whose OCSP responses were signed
> by the OCSP responder certificate's key.
>
> The take-away
>
> The OCSP responses for the end entity certificates worked fine with browsers
> on the web.
> As far as the relying parties were concerned, the only certificate that
> included id-kp-OCSPSigning was the OCSP responder certificate. No other
> certificate in the chain included id-kp-OCSPSigning.
>
> So, while it is true to say that "Microsoft does require the EKU chaining",
> for id-kp-OCSPSigning the only place we have observed them to require it is
> in the Microsoft Certificate Authority software.
>
> We have no reason to believe that their operating systems or browsers require
> EKU chaining for id-kp-OCSPSigning in the web PKI.
>
> Does anyone have any evidence to the contrary?
>
> Regards
> Robin Alden
> Sectigo Limited
This sounds right to me and I definitely remember ADCS behaving this way. Also
the CRLF_IGNORE_INVALID_POLICIES flag will let you override and issue
regardless, but obviously not recommended because it overrides all policy
errors.
Thanks,
Santhan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
