Subject: Cautionary Period Straw Poll

From: "Housley, Russ" <[email-masked]>
Date: Tue, 15 Jan 2002 13:05:22 -0500

From the previous thread (which seems to have died down), I think that 
everyone understands the Cautionary Period concept.  I am trying to 
determine whether there is a constituency for Cautionary Period in DPV.

I would like people that have an opinion to vote by sending a message to 
the list.  The message should be structured as follows:

           To: [email-masked]
           Subject: RE: Cautionary Period Straw Poll

           I believe that DPV protocols developed by the PKIX working group
           [ought to | ought not] include support for a cautionary period.

           [I belive this because ...]

If you feel the need to reply to the rationale posted by  someone, please 
make that posting on the other thread.  Please do not clutter the straw 
poll voting with a debate.

Thanks for your assistance and cooperation,
   Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 16 Jan 2002 08:42:49 +0100

Russ,

Before lauching a straw poll, I would appreciate that you answer to the
e-mail that I sent you on Monday 14. You have not refuted the arguments.

That e-mail is copied below.

If there is a straw poll, then it is between option 1) and option 2).

Regards,

Denis

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

===========================================================================

---

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

I  believe that DPV protocols developed by the PKIX working group
ought to include support for a cautionary period.

alfonso

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 16 Jan 2002 09:56:18 -0800

I believe that DPV protocols developed by the PKIX working group
ought not include support for a cautionary period.

I belive this because the cautionary period is of no value, and will 
likely confuse, the principle users of DPV users, namely systems that 
need to decide immediately whether a signature in front of them 
should be allowed for identification.

The cautionary period is of some value in DSV, although it is not 
clear whether or not it will be confusing there as well. Knowing what 
your trusted DSV server's cautionary period is may or may not useful; 
knowing what your own cautionary period is useful. DSV should either 
allow the user to give definitive inputs to the cautionary period 
calculation from the DSV server, or it should not include the 
cautionary period at all.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Wed, 16 Jan 2002 10:13:04 -0500

I believe that DPV protocols developed by the PKIX working group ought not
include support for a cautionary period.

I belive this because I believe that time stamps are more than adequate to
support most applications in determining the validity of a certificate
and/or signature, and adding a cautionary period just adds unnecessary
complexity to the DPV protocols.

Yuriy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Jan 2002 20:06:04 +0000

I believe this for reasons already stated (e.g. by Paul Hoffman)
and also because I believe we shouldn't make DPV even more
dubious (there - I tried again:-).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Rich Salz <[email-masked]>
Date: Wed, 16 Jan 2002 18:34:56 -0500

I am against cautionary periods; I believe the confusion and complexity
greatly outweighs the gain.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 22 Jan 2002 07:23:13 -0500

I believe this because of the reasons stated by Ambarish (1/11/2002 at 12:48),
Russ (1/16/2002 at 9:24), Yuriy (in this thread), Rich (in this thread), and Al
(in this thread).

spt