Subject: RE: Post-facto queries [Was: RE: DPD & DPV requirements]

From: "Yuriy Dzambasow" <[email-masked]>
Date: Thu, 1 Feb 2001 07:44:41 -0500

Denis,

Thanks for the response.  Please see comments below.

Yuriy

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 10:00 AM
To: [email-masked]
Cc: PKIX-List
Subject: Re: Post-facto queries [Was: RE: DPD & DPV requirements]

Yuriy,

> I think Tom captures the essence of why post-facto queries are needed.  I
> don't think we can assume that every RP will maintain its own information
to
> support non-repudiation disputes in the future.

If you are interrested to support non-repudiation, then you had better to
save the proof. You can save it on a server if you wish. But that server is
only providing a safe storage.
yuriy> To support non-repudiation, all you need is the ability to retrieve
evidence to show that the signature was valid/invalid at the time in
question.  Where that is done should not matter, although some approaches
are better than others, and may be easier to prove in court.

> RPs should have a
> capability to rely on a service to do this for them, especially smaller
> institutions that do not want to go through the effort to implement such a
> capability within their organization.

At the time you first receive a signature you had better to make sure that
it is a valid one. So at the time you make the first verification, either
yourself or using a remote server (like DPV), it is easy to grasp the proof
and save it either locally or remotely. There is thus no need for
post-validation.
yuriy> I understand your solution, and I agree that some RPs will operate
this way.  But in some communities that I am working in, like mortgages,
smaller institutions desire the capability to perform a post-facto query.

> In addition, I think it is helpful to have a capability to perform
> post-facto queries when for some reason the DPV service is originally
> unavailable.

Making a query an hour later is fairly different from making the query 10
years later.
yuriy> But in essence, it is the same sort of query.  Was this signature
valid/invalid at some time before the present?

> For example, I am a contractor submitting a proposal to the
> Federal Government, and the proposal needs to be in by noon on Friday.  I
> complete my proposal, sign and timestamp it, and submit it at 11:55A.  The
> Federal Agency receives my proposal, but for some reason their DPV service
> is down for a few hours; therefore, the agency cannot validate my
signature
> on the proposal at that time.

There is no need to do what you describe. An acknowledge of receipt may be
sent to the sender without the need to validate the signature, if any. Note
also that the sender may be different from the sender.
yuriy> Some solutions I have seen don't send the receipt until the signature
has been validated.  Until then, the sender is told that a receipt is
pending.  Nonetheless, you still need to validate the signature at some time
before the present, regardless of how you handled the receipt.

> When it comes back up, the agency will want
> to know if my signature was valid when the proposal was submitted (at
> 11:55A), and not when the service comes back up.

If the service was down for only a few hours, this can easily be be done.
Doing it, 10 years later is a different story.
yuriy> Again, I think the request is not different, in that you are asking a
server to tell you if a signature was valid at some time before the present.
It should not matter if it is 10 hours before present, or 10 years before
present.  I understand the additional storage requirements on the server to
support requests that date back 10 years, but why would we say it is
acceptable to define a protocol that supports post-facto queries up to some
amount of time before present?

Denis

> Yuriy

---

From: Daniel Ash <[email-masked]>
Date: Thu, 1 Feb 2001 15:13:39 -0500

> Wouldn't your environment better be suited by a service that does not
> ask for a validity of a certificate chain, but for the validity of a
> signed document?  

Has there been any discusion in this group about a service such as this?  

-dan

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 5 Feb 2001 17:08:23 +0100 (MET)

> 
> Peter,
> 
> Thanks for the response.  Comments below.
> 
> Yuriy
> 
I'd like to resume:

X.509 path validation takes a date as an input for the
validation. So be it. This feature can be used in some
circumstances but one should be careful not to consider
it as a replacement of other services (long term validation). 

Expiration is similar to revocation in this workflow context.
If the originating user keeps a record of what was signed, 
and checks whether the 'acknowledge' has been received or not,
the sending user can validate its own cert and get a warning 
"cert expired" or "cert revoked", or "it might happen that your 
request be rejected because your credentials have expired, 
please do this and that"; 

Maybe the signing user just after sending out the text realised
that it was wrong, and immediately revokes his cert in order not
to get the document accepted.