While trying to validate an OCSP response by an OpenSSL OCSP responder running on my laptop, I came across a problem with validation of the timestamps.

For example, the OCSP response contains the following timestamp:

Produced At: Dec 11 07:52:00 2013 GMT

The response arrives at the OCSP client (running wolfSSL embedded SSL 2.7.0) within <1 second, so that the system time on the OCSP client is still Dec 11 07:52:00 2013 GMT when the following code inside 'DecodeSingleResponse' function in ctaocrypt/src/asn.c is executed (note that the XVALIDATE_DATE define expands to the default ValidateDate-implementation using the complete <time.h> facility):

    if (!XVALIDATE_DATE(cs->thisDate, cs->thisDateFormat, BEFORE))
        return ASN_BEFORE_DATE_E;

This call yields an ASN_BEFORE_DATE_E error although I thought that the OCSP response should be treated as valid from the second on it says so - in my example Dec 11 07:52:00 2013 GMT.

RFC2560, chapter 2.4 says:

I understand that it's arguable whether to treat the exact same second as valid or invalid.
I am just wondering if this scenario may happen to a lot more people with OCSP responders which update the revocation status on demand and transmission/processing delays of <1 second.

I for myself changed the last if-statement in the DateGreaterThan-function from

    if (a->tm_year == b->tm_year && a->tm_mon == b->tm_mon &&
        a->tm_mday == b->tm_mday && a->tm_hour == b->tm_hour &&
        a->tm_min  == b->tm_min  && a->tm_sec > b->tm_sec)

to

    if (a->tm_year == b->tm_year && a->tm_mon == b->tm_mon &&
        a->tm_mday == b->tm_mday && a->tm_hour == b->tm_hour &&
        a->tm_min  == b->tm_min  && a->tm_sec >= b->tm_sec)

so that this "special" case works.

Any further thoughts on this?
- Daniel