Subject: Re: Cautionary Period

From: "Tom Gindin" <[email-masked]>
Date: Mon, 14 Jan 2002 18:33:24 -0500

Denis:

      You are correct that there are other services than NR for which
cautionary period is useful.  However, don't they all involve the
validation of signed data (and data to be kept for a considerable time, at
that)?  If they do, then cautionary period should go into DSV.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 01/14/2002 04:20:06 AM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    Alfonso De Gregorio <[email-masked]>, [email-masked]
Subject:    Re: Cautionary Period

Russ,

(text deleted)

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

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

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

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

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

> In my view, the cautionary period only impacts the signature on the
> 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
> 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 ?

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

> Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jan 2002 18:35:32 +0100

Tom,

> validation of signed data (and data to be kept for a considerable time, 

Is a week-end period a "considerable time" ? I do not think so. 
An e-mail sent on the friday may only be opened on the monday. 
Applying a cautionary period increases the confidence and reduces the risk.

> at that)?  If they do, then cautionary period should go into DSV.

Everybody agrees that a cautionary period certainly applies to DSV.

However, some thin clients would still like to use DPV to verify digital
signatures in particular in the context of data origin authentication with
integrity. I do not think it would be appropriate to say that it is not
possible and that the cautionary period, when it exists, shall only be
applied *locally* by the client.

Denis

---

From: Alfonso De Gregorio <[email-masked]>
Date: Wed, 16 Jan 2002 10:06:19 +0100

On Tue, Jan 15, 2002 at 06:35:32PM +0100, Denis Pinkas wrote:

I agree with Denis point of view.
In certain contexts (eg. data origin authentication with
integrity) some clients would still like to observe a 
cautionary period and use DPV.
Performing the cautionary-period observation at server-side
makes the life easier to clients and makes the set of target
execution environments larger (since let them to be unconscious
of the current-time).
Consider cautionary-periods a requirement for DPV does not make
necessarily the protocol more complex. Validation policies MAY
support cautionary periods.

Finally... we should delegate as much as possible all the validation
conditions to DPV servers.

alfonso