Re: Cautionary Period

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

Most people are "accepting the risk", just because most of them ignore 
the risk.

I do agree that it is not always possible to apply a cautionnary
period. In such a case, a risk is necessarilly taken. However, there are
cases where, it is possible to lower the risk. This is possible for two
security services:

- non repudiation and
- data origin authentication with integrity.

For these cases, the support of a cautionary period allows to lower the
risk.

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

This complexity argument does not stand. It is the reverse: simplicity !

Clients just ignore whether the policy includes or not a cautionary period.
This is simplicity. 

There is no obligation for a policy to include a cautionary period, this is
only one possibility.

Clients need to be able to process an additional status. If they do not want
to take advantage of that status, they can even consider it as equivalent to
"not valid". This is certainly not adding complexity.

Regards,

Denis

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