Subject: Re: Cautionary Period

From: Alfonso De Gregorio <[email-masked]>
Date: Fri, 11 Jan 2002 20:42:01 +0100

Denis, 

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

Agreed.

Thanks,
alfonso

---

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 11 Jan 2002 18:26:44 -0800

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:[email-masked]]
> Sent: Friday, January 11, 2002 11:10 AM
> To: Alfonso De Gregorio
> Cc: [email-masked]
> 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.
> ==============================================================
> ==============
> ================
>

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 14:33:27 +0100 (MET)

It seems possible to me that a server indicates in a response
a date in the past for which the 'ok'-status is definitive,
or example the earliest date in CRLs etc., in order to avoids 
the client to check these details. 

If one wants to make statements about the future, i.e. to
respond to a a 'now' request, the answer would always be,
'so far, ok, but (You have to check later|I'll send another
answer later)'.

I don't think it is necessary for a server to
indicate: "not sure, come back in one day".

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 16 Jan 2002 09:24:53 -0500

Denis:

> > 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.
>
>True, but the reverse sentence is also true: "There are application
contexts
>where the concept of a cautionary period is relevant".
>
> > So, when does it matter?  Non-repudiation of a high-value transaction.
In
> > place.  The PKIX working group has done a lot of work on TSP to fill
this
> > requirement.
>
>Non-repudiation is not the single security service where a cautionary
period
>is relevant. It is also relevant for data origin authentication with
>integrity.

It does not matter for key management (key transport or key agreement).  It 
sometimes matters for signatures.  It does not when actions are taken 
immediately after the signature validation, then the signature is never 
checked again.  It is most relevant when the signature (and the signed 
data) are stored for an extended period of time.

> > 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.
>
>Since it is not possible to know when the signature was generated,
>an upper limit of that time is use instead: the date of the time-stamp
>applied over the digital signature or the date included in an audit record
>See the DPV requirements document at:
>http://www.imc.org/draft-ietf-pkix-dsv-req.
>
>The correct sentence is thus: "It can ask the DPV server if the signer's
>path was valid at the time that the time-stamp was applied over the digital
>signature".

I think we are trying to say the same thing.

> > transaction.
>Since a cautionary period cannot be applied in the context of a
>confidentiality service or an authentication service, the right wording
>would be : "the cautionary period only impacts the use of a certificate
>in the context of a non-repudiation service or a
>data-origin-authentication-with-integrity service".

Again, I think we are trying to say the same thing.  The signature 
validation is the central event.  The certificate is being validated as a 
necessary condition to the signature validation.

> > 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.
>
>The basic question is how clients can take advantage of a DPV server in the
>case where a cautionary period exists and in the context of a
>non-repudiation service or a data-origin-authentication-with-integrity
>service ?

This is the crux of our disagreement.  I argue that cautionary period is a 
concept that relates to a single signature, not to the certificate that 
contains the public key used to validate the signature.  If there is any 
protocol that should include the cautionary period concept, it is the DSV 
protocol -- not the DPV protocol.

>There are two options whether :
>
>1) the cautionary period has to be known by the client
>    (which is what your arguments mandate).
>
>2) the cautionary period is known by the server
>    (which is what my arguments mandate).
>
>In the context of a non repudiation service, clients must necessarilly know
>either the date of the time-stamp or the date of the audit record.
>
>In the context of a data-origin-authentication-with-integrity service,
>clients must necessarilly know the purported date of the digital signature.
>
>With option 1, clients must locally manage the cautionary period for each
>supported policy and locally compare it either with the date of the
>time-stamp or the date of the audit record, or the the purported date of
the
>digital signature. This makes management actions more difficult
>(and makes also thin clients fater) since if that period changes,
>local tables need to be updated in each client application.
>
>With option 2, clients do not need to manage that information locally since
>it is part of the policy supported by the server. They simply need to send
>to the server either the date of the time-stamp or the date of the audit
>record, or the purported date of the digital signature.
>
>The goal of these protocols is to delegate as much as possible all the
>validation conditions to a server. The cautionary period does not
>make an exception.

I disagree.  The goal of these protocols is to delegate the certification 
path construction and validation to a server.  The client is still 
responsible for all actions that use the public key in the server validated 
certificate.  If one of those actions is signature validation in a context 
where cautionary period applies, then the client is responsible for 
observing the cautionary period.  If the server were performing the public 
key operation (as it is in DSV), then the server would be responsible for 
observing the cautionary period.

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