On Thu, Jul 2, 2020 at 8:44 AM Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > On 02/07/2020 13:31, Corey Bonnell via dev-security-policy wrote: > > Wouldn't adding the nocheck extension make the subCA certificate > irrevocable, > > thus in the case of a subCA certificate with serverAuth and ocspSigning > EKUs, > > violate the spirit (and maybe the wording?) of sections 4.9.7 and 4.9.10 > of > > the BRs, which mandate the availability of revocation services for the > subCA > > certificate? > > I guess that you could still revoke via a CRL based mechanism. > id-pkix-ocsp-nocheck relevance seems limited to RFC 6960 Section > 4.2.2.2.1. - I don't think it touches CRL interpretation. > > However, I'm struggling to come up with a reason why one would want an > issuing CA which is also a delegated OCSP Responder for its issuing CA, > even if such a thing is RFC and BR compliant! You wouldn’t! This was originally part of SC31 (forbidding this), but moved to “cleanups and clarifications” because of the logical intersection of the many requirements is, as was pointed out to me as well, that such a thing is not permitted, and not desired. I focused on nocheck because that’s a *clear and unambiguous* violation of policy, and doesn’t rely on any interpretation of EKU chaining. As others have rightfully pointed out, if the EKU is present, it is a delegated responder, full stop. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
