Re: [openssl-dev] id-kp-OCSPSigning extended key usage

2017-09-12 Thread Erwann Abalea via openssl-dev
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 
> 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


Re: [openssl-dev] id-kp-OCSPSigning extended key usage

2017-09-12 Thread Salz, Rich via openssl-dev
➢ 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


Re: [openssl-dev] id-kp-OCSPSigning extended key usage

2017-09-12 Thread 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"  wrote:

> Hi,
>
>
> On Tue, Sep 12, 2017 at 2:46 AM, Winter Mute  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


Re: [openssl-dev] id-kp-OCSPSigning extended key usage

2017-09-12 Thread Mischa Salle
Hi,


On Tue, Sep 12, 2017 at 2:46 AM, Winter Mute  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