Hi, Thanks for the clarification. Per the spec, then, a certificate designated to sign OCSP responses is required to have the ocsp-sign bit in the key usage extensions set. How does openssl handle cases where this requirement is violated?
On Sep 12, 2017 3:27 PM, "Mischa Salle" <mischa.sa...@gmail.com> wrote: > Hi, > > > On Tue, Sep 12, 2017 at 2:46 AM, Winter Mute <zshr...@gmail.com> wrote: > >> Hello, >> The RFC <https://tools.ietf.org/html/rfc6960#section-4.2.2.2> states >> that: >> >>> OCSP signing delegation SHALL be designated by the inclusion of >>> id-kp-OCSPSigning in an extended key usage certificate extension >>> included in the OCSP response signer's certificate. >> >> The use of "SHALL" rather than "MUST" indicates that this recommendation >> can be ignored. >> > > SHALL is equivalent to MUST, see RFC2119: > .... MUST This word, or the terms "REQUIRED" or "SHALL"... > I think you're thinking of SHOULD. > > Cheers, > Mischa > > How does openssl handle OCSP responses signed by certificates that do not >> have id-kp-OCSPSigning in the extended key usage certificate extension >> when the responses are not signed by the issuing CA directly? >> What informs this decision/policy? >> Are there any security implications in including or excluding OCSP-sign >> in the extended key usage extension? >> >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
