Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

[[e-mail] (Martin Rex)]

Piyush Jain wrote:
> > The original guidance in rfc2560 for thisUpdate/nextUpdate
> > is fine with me.
> 
> [Piyush] Which original guidance? There is a note that says that these
> values correspond to the values in the CRL.

The meaning of thisUpdate/nextUpdate as described in rfc2560 section 2.4:

   http://tools.ietf.org/html/rfc2560#section-2.4

   2.4 Semantics of thisUpdate, nextUpdate and producedAt

   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.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.


> 
> > You specific guidance on nextUpdate := current Time is actually
> problematic!
> >   http://tools.ietf.org/html/rfc2560#section-4.2.2.1
> > 
> >                Responses whose nextUpdate value is earlier than
> >    the local system time value SHOULD be considered unreliable.
> > 
> > because a nextUpdate = "current Time" on the OCSP responder may often
> > result in nextUpdate < "current Time" on the OCSP client when processing
> > the OCSP response.
>
> [Piyush] Servers typically add a skew and clients typically assume a skew
> when they process the response.


I tend to distinguish these three:
  -  servers defensively adding "slack" (when creating timestamps),
     positive slack for timestamps in the future, negative slack for
     timestamps that represent current time or time in the past.
  -  clients accounting for clock skew when comparing timestamps
     from received or cached PDUs to current time
  -  clients additionally allowing a grace period for revocation
     information that is outdated (i.e. beyond it's accompanying nextUpdate)


During verification of CRLs, my client code ignores thisUpdate, does
_not_ use a clock skew for nextUpdate, and would allow a user-configurable
grace period.


> > 
> > The semantics that you might have been looking for is "nextUpdate not
> set".
> 
> [Piyush] Agreed. Not set implies newer responses are available all the time.

The "nextUpdate not set" semantics also discourages a client from caching
this revocation information.  There may be situations or environments,
when this is desired, but the impact on the client processing latency and
OCSP responder load should be carefully weighed.


> 
> > 
> > I believe, however, that the OCSP responder should not return "nextUpdate
> > not set" for the not-issued situation if it would return nextUpdate
> > several hours or days into the future for "good", "unknown"
> > or CRL-originated "certificateHold" situations.
>
> [Piyush] What is the reason for this belief? I bet it contradicts with the
> rationale behind marking the reason code as "onHold".

Technically, the "good" status is no less temporary than the certificateHold
status (that includes the CA-asserted and CRL-published certificateHold).


-Martin