> 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
