On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to