Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:
>> On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:
>>
>> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>>>
>>>
 static inline unsigned int constant_time_msb(unsigned int a) {
 -  return 0 - (a >> (sizeof(a) * 8 - 1));
 + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
 }

>>> The replacement is not right.  This function is supposed to return
>>> 0xfff for inputs with the high bit set, and 0x000 for inputs
>>> with the high bit not set.  Could you try:
>>>
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>>   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
>>> }
>>>
>>> Just in case the compiler is promoting "a" to the (larger?) size
>>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
>>> while a signed "a" would be promoted "correctly".
>>>
>> Look again, he is casting a to signed, then doing an 
>> arithmetic right shift to extend the msb (sign bit) 
>> to the rest of the word.  This works on 3 conditions:
> I saw what he's doing.  casting (a) to an int, instead of leaving
> it unsigned is not an improvement.  On the assumption that it made
> a difference for this compiler, I proposed an alternative that tests
> whether promotion to the type of the shift's right operand is taking
> place.  It would be good to know whether explicitly casting the shift
> width to an int helps.  Also that 8 could be replaced by CHAR_BIT
> just in case.
>

Yeah, sizeof returning a size_t that is wider than int, causing
promotion of the left argument of the shift operator prior to evaluation
seems a plausible explanation for this behavior.

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 18:33, Viktor Dukhovni wrote:

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:


static inline unsigned int constant_time_msb(unsigned int a) {
-  return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

 static inline unsigned int constant_time_msb(unsigned int a) {
   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
 }

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".

Look again, he is casting a to signed, then doing an
arithmetic right shift to extend the msb (sign bit)
to the rest of the word.  This works on 3 conditions:

1. The platform is actually using twos complement.
2. The signed right shift function invoked by the C
  compiler is a sign-preserving ("arithmetic") shift.
3. The compiler wasn't written by a fanatic who put
  the "right shift of negative signed values is
  undefined" rule above common sense.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[openssl-users]

> On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:
> 
> On 10/12/2015 18:33, Viktor Dukhovni wrote:
>> On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
>> 
>> 
>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> -  return 0 - (a >> (sizeof(a) * 8 - 1));
>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>> }
>>> 
>> The replacement is not right.  This function is supposed to return
>> 0xfff for inputs with the high bit set, and 0x000 for inputs
>> with the high bit not set.  Could you try:
>> 
>> static inline unsigned int constant_time_msb(unsigned int a) {
>>   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
>> }
>> 
>> Just in case the compiler is promoting "a" to the (larger?) size
>> of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
>> while a signed "a" would be promoted "correctly".
>> 
> Look again, he is casting a to signed, then doing an 
> arithmetic right shift to extend the msb (sign bit) 
> to the rest of the word.  This works on 3 conditions:

I saw what he's doing.  casting (a) to an int, instead of leaving
it unsigned is not an improvement.  On the assumption that it made
a difference for this compiler, I proposed an alternative that tests
whether promotion to the type of the shift's right operand is taking
place.  It would be good to know whether explicitly casting the shift
width to an int helps.  Also that 8 could be replaced by CHAR_BIT
just in case.

-- 
Viktor.



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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 19:13, Benjamin Kaduk wrote:

On 12/10/2015 12:09 PM, openssl-us...@dukhovni.org wrote:

On Dec 10, 2015, at 12:45 PM, Jakob Bohm  wrote:

On 10/12/2015 18:33, Viktor Dukhovni wrote:

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:



static inline unsigned int constant_time_msb(unsigned int a) {
-  return 0 - (a >> (sizeof(a) * 8 - 1));
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}


The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

 static inline unsigned int constant_time_msb(unsigned int a) {
   return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
 }

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".


Look again, he is casting a to signed, then doing an
arithmetic right shift to extend the msb (sign bit)
to the rest of the word.  This works on 3 conditions:

I saw what he's doing.  casting (a) to an int, instead of leaving
it unsigned is not an improvement.  On the assumption that it made
a difference for this compiler, I proposed an alternative that tests
whether promotion to the type of the shift's right operand is taking
place.  It would be good to know whether explicitly casting the shift
width to an int helps.  Also that 8 could be replaced by CHAR_BIT
just in case.


Yeah, sizeof returning a size_t that is wider than int, causing
promotion of the left argument of the shift operator prior to evaluation
seems a plausible explanation for this behavior.

Please stop the misinformed guesswork and read the
disassembly posted.

The compiler in question gets confused by the long
sequence of nested inline expressions and looses the
truncation from 32 bit unsigned to 8 bit unsigned
char in the shuffle.

Changing back to the old form of constant_time_msb
simplifies the parse tree just enough to avoid the bug.

Unfortunately, as a comment in the 1.0.2 source code
explains, the old form relies on a language feature
not guaranteed by the C standard, which is probably
why the implementation was changed to the one
currently in 1.0.2.

And to those who still don't understand how the old
implementation worked:

1. By casting the unsigned a to a signed int, the msb
  of interest becomes the sign bit.

2. By shifting right the 2's complement signed int by
  the number of non-sign bits (31 on this target),
  the sign bit gets replicated to the other bits so
  negative values (those with the msb set) become -1,
  while positive values (those with the msb clear)
  become +0.

3. Casting back to unsigned int results in the
  desired value of 0x or 0x .

On the ARM platform, shifting right by 31 bits can be
done to the second input of any arithmetic
instruction, thus making it execute in 0.5 instruction
time if combined with some other operation.  Thus the
compiler moves the shift backwards through some
arithmetic steps in the zero testing, resulting in the
code you see in the posted disassembly.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Erwann Abalea]

Bonsoir,

The OCSP responder can respond « unknown » if it doesn’t know the status of the 
requested certificate. « Unknown » can generally not be used when the issuer is 
not known, because such a response is signed, and if the responder doesn’t know 
about the issuer, it can’t choose its own certificate to use to sign the 
response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, 
wrong signature, incomplete in scope, expired, whatever…), « unknown » is a 
correct answer. « revoked » is also a correct answer if an expired CRL is found 
declaring the requested certificate as revoked. « tryLater » is also a correct 
answer, even « internalError » if we consider the CRL as part of the internal 
state of the responder.

Erwann Abalea
erwann.aba...@docusign.com

Le 10 déc. 2015 à 18:29, socket 
> a écrit :

Hi Walter,

I agree with your addition regarding the fact that it is not saying the cert is 
good, it's saying unknown. However, my understanding of the RFC is that unknown 
should be returned when the OCSP service does not know about the certificate 
issuer. I'm not sure that's the case.

Regarding the response verification, we are used the CA Designated Responder 
(Authorized Responder). meaning that the issuer of serial 0x500c8bd was the 
same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing 
shows that this only affects the "response verification (OK/FAILED)" not the 
certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden 
email]> wrote:
Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:
TEST #2: Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile 
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert 
CERTS/0x500c8bd-revoked.pem -url 
http://ocspresponder:8080

Response verify OK
CERTS/0x500c8bd-revoked.pem: unknown
This Update: Dec 9 20:48:26 2015 GMT

as you can see the client was NOT informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 values ...

We are using a 3rd party vendors OCSP service, and I am of the opinion that an 
OCSP service should provide a revoked response regardless of the time validity 
of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed by the 
same signing cert that signed the cert you want to validate?

or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both 
CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?

Walter

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

Re: [openssl-users] OCSP service dependant on time valid CRLs

[socket]

Thanks for chiming in Erwann.  This OCSP service is CRL based. The software
I am using has a "default signing certificate". I also have #X CA specific
signing certificates for each CA in our lab PKI. It chooses to use the
default signing certificate for all unknown issuers (like if someone
explicitly queries the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in
this situation is to return unknown. I recognize your name as an authority
in pkix, but is this documented anywhere? I would like to be able to
justify to my customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the
expired CRL returns a status of revoked, but when validating this same
certificate against the OCSP service it says unknown. I guess i just have
to get over that they are different and that a certificate can have a
different status depending on who you ask.

Looking forward to any follow on thoughts...

--Dan

On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <
ml-node+s6102n61627...@n7.nabble.com> wrote:

> Bonsoir,
>
> The OCSP responder can respond « unknown » if it doesn’t know the status
> of the requested certificate. « Unknown » can generally not be used when
> the issuer is not known, because such a response is signed, and if the
> responder doesn’t know about the issuer, it can’t choose its own
> certificate to use to sign the response.
>
> If your OCSP responder is CRL based, and the CRL is not valid (badly
> encoded, wrong signature, incomplete in scope, expired, whatever…),
> « unknown » is a correct answer. « revoked » is also a correct answer if an
> expired CRL is found declaring the requested certificate as revoked.
> « tryLater » is also a correct answer, even « internalError » if we
> consider the CRL as part of the internal state of the responder.
>
> Erwann Abalea
> [hidden email] 
>
> Le 10 déc. 2015 à 18:29, socket <[hidden email]
> > a écrit :
>
> Hi Walter,
>
> I agree with your addition regarding the fact that it is not saying the
> cert is good, it's saying unknown. However, my understanding of the RFC is
> that unknown should be returned when the OCSP service does not know about
> the certificate issuer. I'm not sure that's the case.
>
> Regarding the response verification, we are used the CA Designated
> Responder (Authorized Responder). meaning that the issuer of serial
> 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV).
> However, my testing shows that this only affects the "response verification
> (OK/FAILED)" not the certificate status returned (good/revoked/unknown).
>
> --Dan
>
>
> On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] < href="x-msg://5/user/SendEmail.jtp?type=nodenode=61622i=0"
> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
>
>> Hi Dan,
>>
>> On 10.12.2015 16:27, daniel bryan wrote:
>>
>> *TEST #2: *Next test was using OCSP:
>>
>> [dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile
>> VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert
>> CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080
>>
>>
>>
>> *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec
>> 9 20:48:26 2015 GMT*
>>
>> as you can see the client *was NOT *informed the certificate was revoked.
>>
>> and also that it is not good -> unknown, revoked and good are the 3
>> values ...
>>
>>
>> We are using a 3rd party vendors OCSP service, and I am of the opinion
>> that an OCSP service should provide a revoked response regardless of the
>> time validity of the CRL.
>>
>> does the OCSP responder cert be the signing cert itself or was it signed
>> by the same signing cert that signed the cert you want to validate?
>>
>> or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both
>> CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?
>>
>>
>> Walter
>>
>>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html
> To start a new topic under OpenSSL - User, email
> ml-node+s6102n3...@n7.nabble.com
> To unsubscribe from OpenSSL - User, click here
> 
> .
> NAML
> 

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 11:45 AM, Jakob Bohm wrote:
> 3. The compiler wasn't written by a fanatic who put
>   the "right shift of negative signed values is
>   undefined" rule above common sense.

This is only implementation-defined behavior, not undefined behavior. 
It is not permitted to crash the system or launch the missiles. 
(n1256.pdf 6.5.7 paragraph 5.)

-Ben
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 09/12/15 23:13, Benjamin Kaduk wrote:
> On 12/09/2015 05:04 PM, Matt Caswell wrote:
>>
>> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>>> Hi Matt,
>>>
>>> I could build and execute the constant_time_test. I have attached the .c
>>> file and test results. 34 tests have failed. All failures are
>>> around constant_time_eq_8. This is the function I had mentioned in the
>>> earlier mails.
>> Not quite all. There is also a failure right at the beginning of your
>> log in constant_time_is_zero_8. Although it looks very similar to the
>> constant_time_eq_8 failure.
>>
>> As to the failure it is very strange. This is the function doing the test:
>>
>>  int test_binary_op_8(unsigned
>> char (*op) (unsigned int a, unsigned int b),
>> const char *op_name, unsigned int a,
>> unsigned int b, int is_true)
>> {
>> unsigned char c = op(a, b);
>> if (is_true && c != CONSTTIME_TRUE_8) {
>> printf( "Test failed for %s(%du, %du): expected %u "
>> "(TRUE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_TRUE_8, c,__LINE__);
>> return 1;
>> } else if (!is_true && c != CONSTTIME_FALSE_8) {
>> printf( "Test failed for  %s(%du, %du): expected %u "
>> "(FALSE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_FALSE_8, c,__LINE__);
>> return 1;
>> }
>>  printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
>> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
>> c,__LINE__,is_true?"TRUE":"FALSE");
>> return 0;
>> }
>>
>>
>> and the output we see in the log file is:
>>
>> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
>> 4294967295 at line 85
>>
>> That big number in the output is actually 0x7FFF in hex. The
>> variable that it is printing here is "c" which is declared as an
>> "unsigned char".
>>
>> Please someone correct me if I'm wrong but doesn't the C spec guarantee
>> that a "char" is 8 bits? In which case how can the value of "c" be
>> greater than 255?
> 
> C does not make such a guarantee, though recent-ish POSIX does.  (This
> system is a windows one, thought, right?)
> 
> In any case, due to C's type promotion rules, it's very difficult to
> actually use types narrower than 'int', since integers get auto-promoted
> to int at integer conversion time.  This has extra-fun interactions with
> varargs functions, depending on the platform ABI in use.  (Always cast
> NULL to a pointer type when passing to a varargs function; this does
> cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
> to (int)-1, since C type conversions are supposed to be
> value-preserving, but it is certainly possible that the windows ABI is
> doing something I don't expect.  Adjusting things so that the format
> specifier and the type passed to printf match (whether by casting c to
> int or qualifying the format specifier) might help.

Thanks Ben.

It's not 100% clear to me that we are dealing with a system where a char
has more than 8 bits, but it certainly seems like a plausible
explanation for what is going on. Especially when you look at the
implementation of constant_time_eq_8:

static inline unsigned char constant_time_eq_8(unsigned int a, unsigned
int b)
{
return (unsigned char)(constant_time_eq(a, b));
}

The function "constant_time_eq" here returns an "unsigned int". The
whole purpose of "constant_time_eq_8" is to provide a convenience
function to create an 8 bit mask. If the number of bits in an unsigned
char > 8 then this code is going to fail!

Jaya - please could you try the attached patch to see if that resolves
the problem. Please try re-executing both your SSL/TLS tests and the
constant_time test. Let me know how you get on.

Thanks

Matt

From 9649f5fac40438608f010d1cd25d0d553e2c0fae Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Thu, 10 Dec 2015 09:33:24 +
Subject: [PATCH] Fix constant time assumption that char is 8 bits

The constant time code assumes that a char is 8 bits. In reality the C
standard does not guarantee this, so it could be longer than this. There was
a reported issue due to this on WinCE.
---
 crypto/constant_time_locl.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/crypto/constant_time_locl.h b/crypto/constant_time_locl.h
index c786aea..08f4647 100644
--- a/crypto/constant_time_locl.h
+++ b/crypto/constant_time_locl.h
@@ -49,6 +49,8 @@
 
 # include "e_os.h"  /* For 'inline' */
 
+# define CONSTTIME_8BITMASK  0xff
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -142,7 +144,7 @@ static inline unsigned int constant_time_lt(unsigned int a, unsigned int b)
 
 static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int b)
 {
-return (unsigned char)(constant_time_lt(a, b));
+return (unsigned char)(constant_time_lt(a, b) & CONSTTIME_8BITMASK);
 }
 
 static inline unsigned int 

Re: [openssl-users] OPENSSL_VERSION_NUMBER and TLSv1_1 & TLSv1_2 supports

[zosrothko]

Le 08/12/2015 18:16, Jakob Bohm a écrit :

On 07/12/2015 11:52, zosrothko wrote:

Hi Jacob
I saw that in ssl.h, the 'NO' particule means no support of as for 
example

/* Don't use RFC4507 ticket extension */
# define SSL_OP_NO_TICKET0x4000L

What does mean the 'NO' in SSL_OP_NO_TLSv1_1? Should  not be the test
reversed as below?



The define is for a flag that can be passed to some other SSL functions
to turn off the TLSv1_1 support during a single execution, hence the
"NO" in its name.

Because those flags are only defined in OpenSSL versions that include
the thing to turn off (at least if not disabled when compiling OpenSSL
itself), I suggested using the very existence of the flag definition
as a way to determine if the thing is included in the OpenSSL version
where the copy of "ssl.h" was taken from.
Thanks for your explanation which makes your proposal clearer for any 
newcomer of OpenSSL




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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 04:47, Viktor Dukhovni wrote:
> On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:
> 
>> unsigned char c = op(a, b);
>> if (is_true && c != CONSTTIME_TRUE_8) {
>> printf( "Test failed for %s(%du, %du): expected %u "
>> "(TRUE), got %u at line %d\n", op_name, a, b,
>> CONSTTIME_TRUE_8, c,__LINE__);
> 
> It is best to not leave "c" to the vagaries of stdarg argument
> handling.  Rather, it would better to explicitly convert it to an
> unsigned long, and print that.
> 
>> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
>> 4294967295 at line 85
> 
>> That big number in the output is actually 0x7FFF in hex.
> 
> Actually it is 0x, that is a 32-bit "-1".

Doh! Thanks. Looks like a bug in the online converter I was using:
http://www.binaryhexconverter.com/decimal-to-hex-converter

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] force to use /dev/random for openssl fips module

[Ethan Rahn]

xxiao,

have you changed the code to also increase the timeout and not try to use
other devices to get entropy? If /dev/random is blocking at the time, it
may run into issues trying to look for other sources of entropy than giving
up.

On Tue, Dec 8, 2015 at 8:25 PM, xxiao8  wrote:

> I don't know how critical is the DEVRANDOM for openssl-fips, in e_os.h I
> saw this:
> 
> #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
> 
> we have a hardware RNG that is feeding /dev/random via:
> 
> /sbin/rngd -r /dev/hwrng -W 4000
> 
> so the /dev/random will never block, I thus change e_os.h to force usage
> of /dev/random(per our fips code reviewer's request, who thinks I need
> change that for fips):
> 
> #define DEVRANDOM "/dev/random"
> 
> this looks fine, however I don't know if it's really the right thing to
> do, after this change my system starts to have issues(silent reboot),
> changing this line back everything runs normally.
>
> any help is appreciated.
>
> xxiao
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Failed TLSv1.2 handshake

[Nounou Dadoun]

Update: after I disabled aes-gcm the server selected 
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) and the connection succeeded 
(disabling aes-gcm also disabled the available ciphers with SHA384 so it's not 
clear whether that was the culprit or not).

So things are working again but still not sure what the interop problem was, 
thanks for the help ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:
> C does not make such a guarantee, though recent-ish POSIX does.  (This
> system is a windows one, thought, right?)

There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.  But I think there is various code that assumes that
char is 8 bit, and I doubt you can get OpenSSL working on such a
system.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
> 
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

This looks a revert of commit
d2fa182988afa33d9e950358de406cc9fb36d000

It was changed because of the implementation defined behaviour,
and we would like to avoid that.  See RT ticket #3558.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jayalakshmi bhat]

Hi Matt,

Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.

static inline unsigned int constant_time_msb(unsigned int a) {
-*return 0 - (a >> (sizeof(a) * 8 - 1));*
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

Changed constant_time_msb implementation as shown above. All the tests
passed. I have attached the dis-assembly of the code for both successful
case and failure case.  This was requested by Jakob.

Regards
Jaya

On Thu, Dec 10, 2015 at 2:48 AM, Matt Caswell  wrote:

>
>
> On 09/12/15 23:13, Benjamin Kaduk wrote:
> > On 12/09/2015 05:04 PM, Matt Caswell wrote:
> >>
> >> On 09/12/15 11:44, Jayalakshmi bhat wrote:
> >>> Hi Matt,
> >>>
> >>> I could build and execute the constant_time_test. I have attached the
> .c
> >>> file and test results. 34 tests have failed. All failures are
> >>> around constant_time_eq_8. This is the function I had mentioned in the
> >>> earlier mails.
> >> Not quite all. There is also a failure right at the beginning of your
> >> log in constant_time_is_zero_8. Although it looks very similar to the
> >> constant_time_eq_8 failure.
> >>
> >> As to the failure it is very strange. This is the function doing the
> test:
> >>
> >>  int test_binary_op_8(unsigned
> >> char (*op) (unsigned int a, unsigned int b),
> >> const char *op_name, unsigned int a,
> >> unsigned int b, int is_true)
> >> {
> >> unsigned char c = op(a, b);
> >> if (is_true && c != CONSTTIME_TRUE_8) {
> >> printf( "Test failed for %s(%du, %du): expected %u "
> >> "(TRUE), got %u at line %d\n", op_name, a, b,
> >> CONSTTIME_TRUE_8, c,__LINE__);
> >> return 1;
> >> } else if (!is_true && c != CONSTTIME_FALSE_8) {
> >> printf( "Test failed for  %s(%du, %du): expected %u "
> >> "(FALSE), got %u at line %d\n", op_name, a, b,
> >> CONSTTIME_FALSE_8, c,__LINE__);
> >> return 1;
> >> }
> >>  printf( "Test passed for %s(%du, %du): expected %u got %u at line
> %d
> >> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
> >> c,__LINE__,is_true?"TRUE":"FALSE");
> >> return 0;
> >> }
> >>
> >>
> >> and the output we see in the log file is:
> >>
> >> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> >> 4294967295 at line 85
> >>
> >> That big number in the output is actually 0x7FFF in hex. The
> >> variable that it is printing here is "c" which is declared as an
> >> "unsigned char".
> >>
> >> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> >> that a "char" is 8 bits? In which case how can the value of "c" be
> >> greater than 255?
> >
> > C does not make such a guarantee, though recent-ish POSIX does.  (This
> > system is a windows one, thought, right?)
> >
> > In any case, due to C's type promotion rules, it's very difficult to
> > actually use types narrower than 'int', since integers get auto-promoted
> > to int at integer conversion time.  This has extra-fun interactions with
> > varargs functions, depending on the platform ABI in use.  (Always cast
> > NULL to a pointer type when passing to a varargs function; this does
> > cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
> > to (int)-1, since C type conversions are supposed to be
> > value-preserving, but it is certainly possible that the windows ABI is
> > doing something I don't expect.  Adjusting things so that the format
> > specifier and the type passed to printf match (whether by casting c to
> > int or qualifying the format specifier) might help.
>
> Thanks Ben.
>
> It's not 100% clear to me that we are dealing with a system where a char
> has more than 8 bits, but it certainly seems like a plausible
> explanation for what is going on. Especially when you look at the
> implementation of constant_time_eq_8:
>
> static inline unsigned char constant_time_eq_8(unsigned int a, unsigned
> int b)
> {
> return (unsigned char)(constant_time_eq(a, b));
> }
>
> The function "constant_time_eq" here returns an "unsigned int". The
> whole purpose of "constant_time_eq_8" is to provide a convenience
> function to create an 8 bit mask. If the number of bits in an unsigned
> char > 8 then this code is going to fail!
>
> Jaya - please could you try the attached patch to see if that resolves
> the problem. Please try re-executing both your SSL/TLS tests and the
> constant_time test. Let me know how you get on.
>
> Thanks
>
> Matt
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


changes.7z
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;

Hmm, right-shifting a negative value is implementation-defined behavior,
so I don't think that this construct would necessarily be portable to
all systems.  It's not clear to me what purpose the "0 - " was supposed
to perform in the original version, though.

In any case, it seems that the '8' literal there ought to be CHAR_BIT
().  I am curious what value CHAR_BIT has in the environment
that Jaya is running in.

-Ben

> } 
>
> Changed constant_time_msb implementation as shown above. All the tests
> passed. I have attached the dis-assembly of the code for both
> successful case and failure case.  This was requested by Jakob. 
>

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Viktor Dukhovni]

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:

> static inline unsigned int constant_time_msb(unsigned int a) {
> -  return 0 - (a >> (sizeof(a) * 8 - 1));
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

The replacement is not right.  This function is supposed to return
0xfff for inputs with the high bit set, and 0x000 for inputs
with the high bit not set.  Could you try:

static inline unsigned int constant_time_msb(unsigned int a) {
  return 0 - (a >> ((int)(sizeof(a) * 8 - 1)));
}

Just in case the compiler is promoting "a" to the (larger?) size
of sizeof(a), which would cause an unsigned "a" to get a zero MSB,
while a signed "a" would be promoted "correctly".

--
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jeffrey Walton]

On Thu, Dec 10, 2015 at 6:55 AM, Jayalakshmi bhat
 wrote:
> Hi Matt,
>
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
>
> static inline unsigned int constant_time_msb(unsigned int a) {
> -return 0 - (a >> (sizeof(a) * 8 - 1));
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

Forgive me for commenting... That looks questionable to me. C has some
non-intuitive rules, and usually one casts to an unsigned type during
shifts to avoid undefined behavior.

I would definitely build out a test case for it. Ensure the test cases
include a value with and without the high bit set on a 2's compliment
machine. Then, run it under GCC or Clang's Undefined Behavior
sanitizer. For GCC you need 4.9 or above. For Clang, you need 3.2 or
above.

I *think* Ben or Richard has a test build configuration that applies
the sanitizers.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP service dependant on time valid CRLs

[socket]

Hi Walter,

I agree with your addition regarding the fact that it is not saying the
cert is good, it's saying unknown. However, my understanding of the RFC is
that unknown should be returned when the OCSP service does not know about
the certificate issuer. I'm not sure that's the case.

Regarding the response verification, we are used the CA Designated
Responder (Authorized Responder). meaning that the issuer of serial
0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV).
However, my testing shows that this only affects the "response verification
(OK/FAILED)" not the certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <
ml-node+s6102n61605...@n7.nabble.com> wrote:

> Hi Dan,
>
> On 10.12.2015 16:27, daniel bryan wrote:
>
> *TEST #2: *Next test was using OCSP:
>
> [dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile
> VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert
> CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080
>
>
>
> *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec
> 9 20:48:26 2015 GMT*
>
> as you can see the client *was NOT *informed the certificate was revoked.
>
> and also that it is not good -> unknown, revoked and good are the 3 values
> ...
>
>
> We are using a 3rd party vendors OCSP service, and I am of the opinion
> that an OCSP service should provide a revoked response regardless of the
> time validity of the CRL.
>
> does the OCSP responder cert be the signing cert itself or was it signed
> by the same signing cert that signed the cert you want to validate?
>
> or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both
> CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?
>
>
> Walter
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> *smime.p7s* (5K) Download Attachment
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61605.html
> To start a new topic under OpenSSL - User, email
> ml-node+s6102n3...@n7.nabble.com
> To unsubscribe from OpenSSL - User, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61622.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 17:04, Benjamin Kaduk wrote:
> On 12/10/2015 05:55 AM, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> Thanks for the patch. Unfortunately patch did not work. I continued
>> debugging and found that issue was in constant_time_msb.
>>
>> static inline unsigned int constant_time_msb(unsigned int a) {
>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> 
> Hmm, right-shifting a negative value is implementation-defined behavior,
> so I don't think that this construct would necessarily be portable to
> all systems.  It's not clear to me what purpose the "0 - " was supposed
> to perform in the original version, though.

This function is supposed to copy the msb of the input to all of the
other bits...so the return value should either be one of 0x or
0x (obviously dependent on how big an int is). In the original
version the shift would give you just the msb, i.e. a value of 0 or 1.
After the "0 -" you get 0 or -1 (0x).

Interestingly I just checked the header file where this function is
defined and found this:

/*
 * Returns the given value with the MSB copied to all the other
 * bits. Uses the fact that arithmetic shift shifts-in the sign bit.
 * However, this is not ensured by the C standard so you may need to
 * replace this with something else on odd CPUs.
 */

This doesn't match up with the implementation - so I suspect the comment
predates the implementation - but Jaya's fix would put it back that way.

Matt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 11/12/2015 00:16, Kurt Roeckx wrote:

On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:

C does not make such a guarantee, though recent-ish POSIX does.  (This
system is a windows one, thought, right?)

There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.  But I think there is various code that assumes that
char is 8 bit, and I doubt you can get OpenSSL working on such a
system.


Target in question is traditional 32 bit ARM with 32 bit
instructions and 8 bit char.

Looks like a hard to fix compiler bug to me.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 10/12/15 11:55, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
> 
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }


Thanks. Have you analysed why the original version failed? Both versions
look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
bits). I'd really like to understand that before replacing it with
something else which apparently does the same thing. Perhaps you could
post some sample values for "a" and the return value, before and after
your change.

Thanks

Matt


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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

On 10/12/2015 17:53, Matt Caswell wrote:

On 10/12/15 11:55, Jayalakshmi bhat wrote:

Hi Matt,

Thanks for the patch. Unfortunately patch did not work. I continued
debugging and found that issue was in constant_time_msb.

static inline unsigned int constant_time_msb(unsigned int a) {
-*return 0 - (a >> (sizeof(a) * 8 - 1));*
+ return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
}

Thanks. Have you analysed why the original version failed? Both versions
look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
bits). I'd really like to understand that before replacing it with
something else which apparently does the same thing. Perhaps you could
post some sample values for "a" and the return value, before and after
your change.

Looking at the provided disassembly, it looks like the
1.0.2 version triggers a compiler bug which (at least)
forgets to mask the result down to 8 bits after inlining
in test_is_zero_8().   The missing mask with FF occurs
in multiple functions in the disassembly.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

[openssl-users] OpenSSL version 1.1.0 pre release 1 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.1.0 pre release 1 (alpha)
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 1 has now
   been made available. For details of changes and known issues see the
   release notes at:

http://www.openssl.org/news/openssl-1.1.0-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The alpha release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.0-pre1.tar.gz
  Size: 4990889
  SHA1 checksum: a058b999e17e0c40988bd7b9b280c9876f62684e
  SHA256 checksum: 
79da49c38464a19d1b328c2f4a3661849bd2eb3d54a37fdb6a56d9b8a18e87bd

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.0-pre1.tar.gz
openssl sha256 openssl-1.1.0-pre1.tar.gz

   Please download and check this alpha release as soon as possible. Bug reports
   should go to r...@openssl.org. Please check the release notes
   and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWaYrRAAoJENnE0m0OYESRh5gIAJ8WrkPPV8CW2xWmtyIjAxpz
7FvvpxBWHaBgJcCrvNomh2JJupXa+enWCTsskIyH0+FtS85VeOKNvQg68xbCOvLl
I0dWxMNb8SCxuagvEje8xGEnf8by8pZdYaK8ERASlNoGVIgN8CwppiKnY8c1yRYn
Ti0dUZLyVZvT5Qm2Q3k4pOvfS/+rvFjHiuUllFzfHlp6mdk4573w5eneoTINQvRK
OC8iAnSiINQWQvuiavLVIgw7VFBD1WC2iKWuSA3+31YuM8CUpvbbnJHh2QUfGkIw
oNTkflxgQJhk/txwqvCSzZsVddhvQLZtiRZYQcG4WUuskygCENeieJGPOXN6ioI=
=LY4X
-END PGP SIGNATURE-
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OCSP service dependant on time valid CRLs

[daniel bryan]

Hello,

I was researching how expired CRLs affect revocation checking via openssl.

* TEST #1: *The first test was to find out what status is returned when i
verify a certificate against the CRL:

[dan@canttouchthis PKI]$ openssl verify -CAfile CAS/cabundle.pem -CRLfile
CRLS/ABC-expired.crl -crl_check CERTS/0x500c8bd-revoked.pem




*CERTS/0x500c8bd-revoked.pem: C = us, O = ORG, OU = LAB, OU = ABC, OU =
D002, CN = test error 12 at 0 depth lookup:CRL has expiredC = us, O = ORG,
OU = LAB, OU = ABC, OU = D002, CN = test error 23 at 0 depth
lookup:certificate revoked*

as you can see the client *WAS* informed the certificate was *revoked*,
even though the CRL was expired.


*TEST #2: *Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert
CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080



*Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: Dec 9
20:48:26 2015 GMT*

as you can see the client *was NOT *informed the certificate was revoked.

We are using a 3rd party vendors OCSP service, and I am of the opinion that
an OCSP service should provide a revoked response regardless of the time
validity of the CRL.

I have read RFC 2560 & 6960 many times, and have not been able to find
explicit guidance on this scenario. I am interested in the community
opinion on this issue, and any pertinent mandatory guidance.

My end goal is either to convince our vendor to provide a revoked status
regardless of the CRLs expiration OR justify why an OCSP service should
ignore issuers with expired CRLs. I'm looking forward to any feedback
provided.

--Dan
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Walter H.]

Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:

*TEST #2: *Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile 
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert 
CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080


/Response verify OK
CERTS/0x500c8bd-revoked.pem: *unknown*
This Update: Dec 9 20:48:26 2015 GMT/

as you can see the client *was NOT *informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 
values ...


We are using a 3rd party vendors OCSP service, and I am of the opinion 
that an OCSP service should provide a revoked response regardless of 
the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed 
by the same signing cert that signed the cert you want to validate?


or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both 
CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?



Walter


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users