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

[[e-mail] (Martin Rex)]

Stefan Santesson wrote:
> 
> Those fields are not treated in any special way depending on what status
> you provide in a response.

I agree that there is intentionally *no* special treatment for thisUpdate
and nextUpdate, i.e. they should probably be similar to traditional
situations when certificateHold appears on a CRL.

But since this synthesized "certificateHold" revocation for a not-issued
certificate does not originate from a CRL, an implementor might wonder
what to put into these fields when changing existing code, in particular
existing code that would copy values from the CRL for "certficateHold"
that originates from a CRL.

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.

-Martin



> On 4/2/13 3:36 PM, "Peter Rybar" <[e-mail]> wrote:
> 
> >Stefan,
> >
> >When revoked for "not-issued" is created by OCSP server then according to
> >actual rfc2560bis is unclear, what must be included in thisUpdate and
> >nextUpdate fields.
> >Rfc2560bis must also define rules for value of thisUpdate and nextUpdate
> >fields.
> >
> >
> >RFC 2560:
> >   - 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