id-kp-OCSPSigning extended key usage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

id-kp-OCSPSigning extended key usage

Winter Mute
Hello,
The RFC 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.
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
Reply | Threaded
Open this post in threaded view
|

Re: id-kp-OCSPSigning extended key usage

OpenSSL - Dev mailing list
Bonjour,

SHALL is not equivalent to a SHOULD, but to a MUST. See RFC2119.

Cordialement,
Erwann Abalea

Le 12 sept. 2017 à 02:46, Winter Mute <[hidden email]> a écrit :

Hello,
The RFC 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.
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
Reply | Threaded
Open this post in threaded view
|

Re: id-kp-OCSPSigning extended key usage

Mischa Salle
In reply to this post by Winter Mute
Hi,


On Tue, Sep 12, 2017 at 2:46 AM, Winter Mute <[hidden email]> wrote:
Hello,
The RFC 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
Reply | Threaded
Open this post in threaded view
|

Re: id-kp-OCSPSigning extended key usage

Winter Mute
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" <[hidden email]> wrote:
Hi,


On Tue, Sep 12, 2017 at 2:46 AM, Winter Mute <[hidden email]> wrote:
Hello,
The RFC 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
Reply | Threaded
Open this post in threaded view
|

Re: id-kp-OCSPSigning extended key usage

OpenSSL - Dev mailing list
➢ 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?

Look at check_delegated() in ocsp/ocsp_vfy.c  It returns an error.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev