RE: Cautionary Period

["Deacon, Alex" <alex@xxxxxxxxxxxx>]

Right, it seems pretty clear to me from the paragraph in section 4.1 copied
below that the cautionary period only impacts the status of the signature
that was created by the certificate at some point in the recent past....not
the status of the certificate itself.  So I agree that this is a DSV
concept, not a DPV concept.

"When the public key within the certificate is used to verify some usage
from the recent past, it is possible to apply a cautionary period to further
reduce the risk. In such a case, the policy MAY indicate a minimum delay to
be observed between the time T in the past, i.e. when the use of the private
key took was supposed to take place, and the time of the current
verification." 

BTW, I think the word "took" in that last sentence is stray and should be
removed.

Regards,
Alex


> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx]
> Sent: Friday, January 11, 2002 11:10 AM
> To: Alfonso De Gregorio
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: Cautionary Period
> 
> 
> 
> Alfonso:
> 
> > > 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.
> 
> There are many application contexts where the concept of a cautionary 
> period is irrelevant.  For example: TLS.  The client will 
> either accept the 
> server's certificate for establishment of the TLS-protected 
> session, or it 
> will reject it.
> 
> So, when does it matter?  Non-repudiation of a high-value 
> transaction. In 
> such a context, it is very important to know when a transaction take 
> place.  The PKIX working group has done a lot of work on TSP 
> to fill this 
> requirement.
> 
> Let's assume that the constrained client wants to validate such a 
> transaction.  The TSP timestamp provides the date/time of 
> interest.  It can 
> ask the DPV server if the signer's path was valid at the time 
> that the 
> signature was generated.
> 
> In my view, the cautionary period only impacts the signature on the 
> transaction.  The DPV server does not validate this signature.  Has 
> adequate time passed since the signature was applied to 
> ensure that recent 
> compromise of the end-entity private key has been reported?  
> I submit that 
> this a signature validation question, not a certification 
> path validation 
> question.
> 
> Russ
> 
> 
> 
> 
> ==============================================================
> ==============
> ================
> This e-mail, its content and any files transmitted with it 
> are intended
> solely for the addressee(s) and are PRIVILEGED and 
> CONFIDENTIAL.  Access by any other party is unauthorized 
> without the express
> prior written permission of the sender.  If 
> you have received this e-mail in error you may not copy, 
> disclose to any
> third party or use the contents, attachments or 
> information in any way, Please delete all copies of the e-mail and the
> attachment(s), if any and notify the sender. 
> Thank You.
> ==============================================================
> ==============
> ================
>