Re: Cautionary Period Straw Poll

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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


> Here are the results of the Straw Poll.
> 
> Ought to support cautionary period: 2
>         Alfonso De Gregorio <agregorio@xxxxxxx>
>         Todd Glassey <todd.glassey@xxxxxxxxxxxxxxxx>
> 
> Ought NOT support cautionary period: 14
>         Santosh Chokhani <chokhani@xxxxxxxxxxxx>
>         Russ Housley <rhousley@xxxxxxxxxxxxxxx>
>         Ambarish Malpani <ambarish@xxxxxxxxxxxx>
>         Sanjeev Shukla <sanjeevshukla@xxxxxxxxxxx>
>         Yuriy Dzambasow <yuriy@xxxxxxxxxxxx>
>         Paul Hoffman <phoffman@xxxxxxx>
>         Peter Yee <pyee@xxxxxxxxxxxxxxx>
>         Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>
>         Alex Deacon <alex@xxxxxxxxxxxx>
>         Al Arsenault <awa1@xxxxxxxx>
>         Rich Salz <rsalz@xxxxxxxxxx>
>         Tom Gindin <tgindin@xxxxxxxxxx>
>         Trevor Freeman <trevorf@xxxxxxxxxxxxx>
>         Michael Myers <myers@xxxxxxxxxxxxx>
>         Sean P. Turner <turners@xxxxxxxx>
> 
> Other response: 2
>         Denis Pinkas <Denis.Pinkas@xxxxxxxx>
>         Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>
> 
> 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