On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy < [email protected]> wrote:
> My question is the following: is it allowed to issue an OCSP Responder > certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, This will fail, not because of policy reasons, but because of technical reasons (not Firefox). The code (for Firefox) is https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888 , with the most salient logic at https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884 , although the explanation in https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869 explains the technical reasons. > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a > possible, mandatory or forbidden option for such CAs? > This is not forbidden by policy. That is, a technically constrained subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth. As I see in the practice, if a technically constrained CA signs the OCSP > response itself, it can be done without the "id-kp-OCSPSigning" EKU but > with the "digitalSignature" KU bit in the CA certificate. > Correct, if the id-kp-OCSPSigning EKU is missing from the technically constrained intermediate, direct signing still works. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
