Re: [SOLVED] OCSP resp. invalid if processed at same second as generated

null@example.com (john) — Tue, 18 Feb 2014 22:30:37 +0000

The validate date function being used is the one for certificates that is checking for notBefore and notAfter in certificate validity. The one-second window is there for OCSP responses. This detail is on the list of things to address at some point.

[SOLVED] OCSP resp. invalid if processed at same second as generated

null@example.com (Zeddi) — Wed, 11 Dec 2013 09:50:23 +0000

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 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:

Responses can contain three times in them - thisUpdate, nextUpdate
and producedAt. The semantics of these fields are:
- thisUpdate: The time at which the status being indicated is known
to be correct
- nextUpdate: The time at or before which newer information will be
available about the status of the certificate
- producedAt: The time at which the OCSP responder signed this
response.

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)

    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

wolfSSL - Embedded SSL Library — [SOLVED] OCSP resp. invalid if processed at same second as generated

Re: [SOLVED] OCSP resp. invalid if processed at same second as generated

[SOLVED] OCSP resp. invalid if processed at same second as generated