Subject: Re: Cautionary Period

From: "Housley, Russ" <[email-masked]>
Date: Fri, 11 Jan 2002 14:09:35 -0500

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: Denis Pinkas <[email-masked]>
Date: Mon, 14 Jan 2002 10:20:06 +0100

Russ,

(text deleted) 

> server's certificate for establishment of the TLS-protected session, or it

True, but the reverse sentence is also true: "There are application contexts
where the concept of a cautionary period is relevant".
 
> place.  The PKIX working group has done a lot of work on TSP to fill this

Non-repudiation is not the single security service where a cautionary period
is relevant. It is also relevant for data origin authentication with
integrity.

> ask the DPV server if the signer's path was valid at the time that the

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

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

> The DPV server does not validate this signature.  Has

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 ?

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.

Denis