Subject: RE: Cautionary Period Straw Poll

From: Santosh Chokhani <[email-masked]>
Date: Tue, 15 Jan 2002 14:03:37 -0500

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

I believe this because I am.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 1:05 PM
To: [email-masked]
Subject: Cautionary Period Straw Poll

 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 09:24:54 +0100

Santosh,

> I believe this because I am.

Quite an interresting technical argument.  :-)

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 29 Jan 2002 08:17:35 -0500

Here are the results of the Straw Poll.

Ought to support cautionary period: 2
	Alfonso De Gregorio <[email-masked]>
	Todd Glassey <[email-masked]>
	
Ought NOT support cautionary period: 14
	Santosh Chokhani <[email-masked]>
	Russ Housley <[email-masked]>
	Ambarish Malpani <[email-masked]>
	Sanjeev Shukla <[email-masked]>
	Yuriy Dzambasow <[email-masked]>
	Paul Hoffman <[email-masked]>
	Peter Yee <[email-masked]>
	Stephen Farrell <[email-masked]>
	Alex Deacon <[email-masked]>
	Al Arsenault <[email-masked]>
	Rich Salz <[email-masked]>
	Tom Gindin <[email-masked]>
	Trevor Freeman <[email-masked]>
	Michael Myers <[email-masked]>
	Sean P. Turner <[email-masked]>

Other response: 2
	Denis Pinkas <[email-masked]>
	Peter Sylvester <[email-masked]>

While there are certainly many members of the mail list that did not share 
an opinion, the scale is clearly tilted toward the exclusion of cautionary 
period support from PKIX DPV requirements and protocols.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 30 Jan 2002 10:13:26 +0100

Dear co-editor,

:-)

You counted me in the "Other response" category, and I am grateful for this,
... since the straw poll question was not correctly raised.

In an e-mail sent on January 14, I said:

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

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

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

Let us now see the implications, if the cautionary period is not known to
the server (which is what you wanted).

I believe that the DPV protocol has to be usable to verify the validity 
of a certificate used in the context of a data-origin-authentication 
with-integrity service. The client must be able to apply locally a
cautionary period.

Today we have a status which means:

   1) the certificate is valid according to the validation policy.

Since *all* the rules are not handled by the server, this status becomes
inappropriate. It should be changed into:

   1) the certificate is conditionally valid according to the validation
      policy.
 
In order to be able to apply *locally* an additional rule, i.e. the
cautionary period, the client needs additional information to support this
status.

If the revocation status of the certificate under query is obtained using an
OCSP service, then thisUpdate MUST be returned.

thisUpdate is the time at which the status being indicated is known to be
correct

If the revocation status of the certificate under query is obtained using a
base CRL, then thisUpdate MUST be returned.

thisUpdate indicates the issue date of the CRL.

If the revocation status of the certificate under query is obtained using a
base CRL and a delat CRL, then thisUpdate from the delta CRL MUST be
returned.

thisUpdate indicates the issue date of the delta-CRL.

CONCLUSION

The "price to pay" to handle *locally* the cautionary period is thus:

  1) to change the current status "the certificate is valid" 
     into "the certificate is conditionally".

  2) to return an additional parameter to copy the field "thisUpdate" 
     obtained from an OCSP response, a base CRL or a delta CRL.

Handling the cautionary period at the server would be simpler, with 
the major additional argument indicated in my e-mail from January 14:

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

After reading this conclusion, it might be possible that some people would
like to change their vote, or that additional people would like to express
their opinion about option 1 and option 2.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 30 Jan 2002 08:54:34 -0500

>... since the straw poll question was not correctly raised.

I tried to be accurate.

>cautionary period, the client needs additional information to support this

I disagree.  The certificate is valid; the is no need for a condition.

The client must determine whether a valid certificate is sufficient for 
processing the signature.  I assume that we all agree that a valid 
certificate is necessary.  If there are other conditions beyond a valid 
certificate, then the client must take actions beyond asking the DPV server 
to determine whether those conditions have been met.

In the case of cautionary period, the client will wait the appropriate 
amount of time, then the client will use DPV to determine whether the 
certificate is valid.  If so, the client must perform other checks, 
including signature verification.

>OCSP service, then thisUpdate MUST be returned.

OCSP provides the status for one certificate.  DPV constructs a 
certification path and then validates it.  If OCSP is employed, it will be 
used for each certificate in the path.  It is not clear to me which 
thisUpdate is going to be useful to the client.

If any of the OCSP responses include nextUpdate, it might be useful to 
return the earliest nextUpdate value from the set of responses. If CRLs (or 
delta CRLs) are used, the earliest nextUpdate value could be useful.

>      obtained from an OCSP response, a base CRL or a delta CRL.

I disagree with both of your conclusions for the reasons indicated above.

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 30 Jan 2002 08:51:09 -0800

At 4:21 PM +0100 1/30/02, Denis Pinkas wrote:
>Once again, I am not advocating the handling of ANY validation rule at the
>client, but instead the handling of ALL the validation rules at the server,
>hence the solution indicated just above is only to illustrate the problem,
>but not the solution I would like to go with.

It is somewhat distressing to see one of the editors of a 
requirements document actively ignoring the consensus of the Working 
Group on what should and should not go in the requirements document. 
If someone writing a protocol that meets these requirements wants to 
extend the protocol, they can. But the WG has pretty much said "it is 
not a requirement" and the requirements document should reflect that.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 30 Jan 2002 16:21:04 +0100

Russ,

 

 
 
> to determine whether those conditions have been met.

Do not forget that DPV servers are supposed to be a single place of inquiry
for thin clients. Anyway, the client is unable to take any action concerning
a cautionary period, unless it is made aware of "thisUpdate".
 
> including signature verification.

It is impossible to know how long to wait, unless the client is aware of the
value of the field thisUpdate.

> thisUpdate is going to be useful to the client.

First, the one about the certificate under the query, usually a leaf
certificate. But you are right, theoritically, all the fields thisUpdate 
from the certification path would need to be considered. Handling the
definition of the cautionary period, IF ANY, at the server offers simplicity
and hides all this complexity.

I am not advocating the handling of ANY validation rule at the client, 
but instead the handling of ALL the validation rules at the server.

 

To this respect we both agree.  :-)

Denis