Re: Cautionary Period

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Alfonso,

Very good point. It is true that some thin clients may not have a time
reference available but may simply support a nonce mechanism. So you are
quite right to say that delegating a path validation to a TTP allows
execution environments to be unaware of the current-time.

Another argument is that some thin clients may not be aware of the value or
even the existence of a cautionary period associated with some policy. That
cautionary period may even change. So it is required to manage that value at
the policy level (which means the server level) rather than locally at the
client level.

Denis


> 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