3 Replies Latest reply on Aug 21, 2016 2:08 AM by dánielk63456349

    OCSP validation: treating thisUpdate as the response signature date. Bug ?

    Mathieu Fortin Level 1

      Hi all


      According to RFC 6960, the following date fields in an OCSP response are defined as:

      thisUpdateThe most recent time at which the status being indicated is known by the responder to have been correct.

      The time at which the OCSP responder signed this response.


      When validating a signer against an OCSP response, Acrobat seems to consider the thisUpdate field as the date the OCSP response was signed. For example:

      An OCSP with the following fields:

      thisUpdate: Fri Apr 29 07:29:58 EDT 2016

      nextUpdate: Fri Apr 29 10:40:38 EDT 2016

      producedAt: Fri Apr 29 10:35:38 EDT 2016


      will yield the following result in Acrobat:

      The OCSP Response was signed by "OCSP Authority" on 2016/04/29 07:29:58 -04'00' (<--- thisUpdate) and is valid until 2016/04/29 10:40:38 -04'00'.


      Aside from showing erroneous information, this becomes a real problem when the OCSP Responder is using validation information which is older than the responder certificate (thisUpdate < responder certificate notBefore). In that scenario, validation fails with not yet valid exception since thisUpdate is used as signature date, which is before the certificate existence.


      Any info on this ? Am I wrong with my assumptions ?

        • 1. Re: OCSP validation: treating thisUpdate as the response signature date. Bug ?
          IsakTen Level 4

          Here's the relevant part of OCSP 2560:


          2.5 Response Pre-production

          OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response.


          What that means is that producedAt indicates when the OCSP response was actually produced. It has no bearing on the time period for which this OCSP response is valid. The Acrobat wording in the Certificate Viewer may be a bit off, but it conveys, IMO, the information the user needs, i.e. the starting time for this OCSP to be used.

          • 2. Re: OCSP validation: treating thisUpdate as the response signature date. Bug ?
            Mathieu Fortin Level 1

            I wouldnt mind if it was just the wording. But like I explained, since it considers (wrongly) the thisUpdate as the signing time, it validates that this signing time falls between the notBefore and notAfter values of the OCSP responder certificate. So it fails when thisUpdate is set before the ocsp certificate existence. If producedAt was used as the signing time (like the RFC describes), this error would probably not occur.


            In other words, lets say we issue ocsp responders for short time periods, it seems they cannot produce responses with thisUpdate prior to their existence, even though they are using validation info directly from their parent CA (whose validation info dates back from the beginning). I dont see anything in the RFC which prohibits thisUpdate set to a time BEFORE the ocsp responser certificate notBefore (I may be wrong here).


            I know this case is covered by the Archive Cutoff extension, but considering the thisUpdate as the signing time instead of producedAt looks like a bug IMO.

            • 3. Re: OCSP validation: treating thisUpdate as the response signature date. Bug ?

              I think I just ran into this problem too. In my case users need to be able to validate PDF files off-line in a network environment where Internet access is prohibited. Also long-term archival is expected by embedding revocation information and protecting them with document time stamps.

              What I found is that Adobe Acrobat Pro DC (version 15.006.30201) will nicely validate all signatures with embedded OCSP responses after they are created. However, the next day these validations fail, as Adobe wants to download revocation data which it obviously can't due to lack of Internet access. I go like "Why does it want to download revocation NOW when all embedded information was OK YESTERDAY?" Acrobat also wrote that OCSP response is expired. I digged into RFCs looking for expiry of OCSP responses but I couldn't find any (I only found NextUpdate which is NOT the expiry of the revocation information). So this means that latest Adobe products (both Acrobat and Reader DC) cannot handle OCSP responses rendering this type of revocation useless.

              So it sure looks like a bug the way OCSP responses are handled. I wonder why not many others have come across this problem before?