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

[[e-mail] (Martin Rex)]

another followup to myself, in order to clarify.
Martin Rex wrote:
> Piyush Jain wrote:
> >  
> > > Anyhow, I think that rfc2560bis can not (and should not) make suggestions
> > > for specific values.  What values would your OCSP implementation use for
> > > "good" or "unknown" responses for the same CA?  Those values look like
> > > they might be from the right ballpark.
> > 
> > 2560-bis states that these values correspond to those in CRLs.
> > Implementations that I know of set these values from the CRL for good
> > responses and use current time for unknown responses.
> > 
> > This is how 2560 defines these fields
> > - 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


The original guidance in rfc2560 for thisUpdate/nextUpdate is fine with me.


> 
> > So for non-issued, thisUpdate should be start of CAs validity interval (all
> > certs are revoked until they get issued) and nextUpdate should be current
> > time (a certificate with that serial can be issued anytime). 
 
What I meant (and failed to clarify) is that rfc2560bis should *NOT* define
special values for thisUpdate/nextUpdate that are specific to the
"not issued reported as revoked/certificateHold" situation, so I
effectively disagree with the latter statement.


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.

The semantics that you might have been looking for is "nextUpdate not set".


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.


-Martin