RE: Cautionary Period

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Alfonso, Denis,
    I disagree with the need for cautionary period in the DPV
protocol. Here is my reasoning:

The rationale for cautionary period, is the argument that a CRL/
OCSP response is necessarily out of date, because it takes some
time to discover, report and process a revocation request. This
means that a certificate should not be trusted for some time
after you have received it - to ensure that the revocation
information is current.

In most practical systems that I have seen, people are more than
willing to accept the risk of using a certificate if it is not
currently revoked - most people don't want to wait till the next
CRL is published, or wait till a CA has been given enough of a
margin to be able to process revocation requests. For example, in
the credit card world, we use our cards and get our mechandise
immediately, even though it would take some time to report the
loss of a credit card.

I think adding cautionary period to this protocol would just add
unnecessary complexity.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Alfonso De Gregorio [mailto:agregorio@xxxxxxx]
> Sent: Friday, January 11, 2002 9:06 AM
> To: Denis.Pinkas@xxxxxxxx; Housley, Russ
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: Cautionary Period
> 
> 
> 
> Hi Russ, hi Denis, hi Everyone,
> 
> > I encourage everyone to read DPV and DPD requirements 
> document, and post 
> > their view on this subject.  I believe that the document 
> expresses Denis' 
> > view on the issue.  My view is that cautionary period is a not a 
> > requirement for DPV or DPD.  However, cautionary periods 
> might be used as 
> > part of an application-specific risk mitigation mechanism 
> when trying to 
> > determine the validity of a particular signature.  For 
> example, waiting for 
> > cautionary period before considering a signature to be valid on a 
> > high-value electronic contract may be prudent.  Therefore, 
> cautionary 
> > periods might be supported in DSV (delegated signature validation).
> 
> In order to observe the cautionary-period-delay at application level
> the execution environment must be current-time-aware.
> DPV target execution environments are assumed to be constrained, at 
> least by a processing and/or communication point of view. 
> Constrained execution environments, such as telephones and PDA,
> are not necessarily current-time-aware (or have time-sources not
> necessarily trusted).
> Delegating a path validation to a TTP allows execution environments
> to be unaware of the current-time. 
> So, IMHO, cautionary periods should be a requirement for DPV.
> 
> alfonso
>