Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Marc,
    I don't agree with your first sentence. A CA might have a policy of
only updating its database periodically (for example because it keeps
the database itself offline and a read-only copy online). In that case,
even a responder that has direct access to the CAs database, might
still want to set nextUpdate.

In a spec like this, I would rather tell people what it means if they
do something rather than dictate policy to them.

Regards,
Ambarish


Marc Branchaud wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Mike, Paul;
> 
> Yer right, specifying just "CRL" is way too restrictive.  Just to make sure
> we agree, the text is the same as before with the first two sentecnes
> removed, i.e.:
> 
>   The nextUpdate field SHOULD NOT be included if the responder has direct
>   access to the CA's revocation database (i.e. it can obtain revocation
>   information in real time).  When it is included, the nextUpdate field
>   SHOULD be interpreted to mean that fresh revocation information should be
>   available no later than nextUpdate's time, and may be available sooner.  In
>   general, nextUpdate is not a guarantee of the lifetime of a response's
>   validity.  Clients SHOULD use their own local policies to determine how
>   long they believe a response to be valid, regardless of the presence of the
>   nextUpdate field in the response.
> 
> S'cool?
> 
>                 Marc
> 
> 
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        ambarish@valicert.com
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303