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

["Piyush Jain" <[e-mail]>]

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

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

> 
> 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".

 
> 
> -Martin