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
