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

From: "Covey, Carlin" <[email-masked]>
Date: Tue, 23 Jan 2001 09:22:57 -0800

Russ, I think Denis is saying that if the client trusts the DPV
server's good/bad response, why wouldn't it also trust the timestamp
that the DPV server put on the response (obviating the need for a
third-party timestamp).  Denis, did I get that right?

I suppose the client might believe that the DPV server was honest,
but not a very good timekeeper.  Seems a stretch though....

I have a question on an earlier email in this thread. Perhaps I 
misinterpreted something.  I'm puzzled why we would want timestamps 
on individual CRLs in the case of post-facto validation of a certificate.  
The CRL contains information that indicates its validity period.  
Presumably if a timestamp were placed over the CRL later, the timestamp
would indicate the current time, not the validity time of the CRL.
(A timestamping server that back-dates timestamps doesn't seem very
trustworthy.)  Why would I care whether the CRL for a certain week three
months ago now had today's timestamp on it?  (I'm sure I must have missed
something in the discussion.)

Regards,

Carlin

-------------------------------------
- Carlin Covey
  Cylink Corp. 

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

Russ,

Your statement is too short so that I can understand what you do not
understand. :-)

Could you elaborate a little bit more, or maybe some one else could explain
better than I can.

Denis

> Denis:
> 
> I do not understand your point.
> 
> Russ
> 
> At 04:48 PM 1/23/2001 +0100, Denis Pinkas wrote:
> >[Denis]
> >
> >The additional problem to be considered is that the structure of the
answer
> >in case (a) would be different from the answer in the case of a
current-time
> >checking, since one structure would include individual time stamps while
the
> >other would not.
> >
> >[Russ]
> >
> >Why does the DPV need a 3rd party time stamp on the CRLs?  It can keep
> >track using its own clock as long as it has a trusted time source.  The
> >STIME working group is going to provide a straightforward mechanism for
> >that...
> >
> >[Denis * new answer]
> >
> >If you use the evidence, it is because you do not trust the "valid"
answer
> >from the server (otherwise, you would not need the evidence). Hence you
> >would not trust either the clock from the server.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 23 Jan 2001 18:45:55 +0100

Carlin,

Thanks for trying to explain.

> third-party timestamp).  Denis, did I get that right?

No. Unfortunately. If the relying party is willing to trust the signed
"valid" response obtained from the DPV server's by the client, then he does
not need any additional proof such as CRLs certification path or whatever.
If the relying does not trust the response then he will ask for the proof
(such as certification path and revocation information).  

Also note that the time stamp is not issued by the DPV server, but requested
by the DPV server. The DPV server acts as a client from a TSA server.

> but not a very good timekeeper.  Seems a stretch though....

Not exactly. See above.

> The CRL contains information that indicates its validity period.

If keys signing CRLs were never compromised nor revoked, time stamping would
not be necessary. Since CAs are not mandated to publish any information
about the revocation of a key after the end of the validity period, it is
necessary to prove that the signature was done during the period of the
validity of the certificate, unless it can be made sure that the key can
never be compromised or never be found from a brute force attack. Since we
can never be sure of these two conditions, time stamping guards against that
threat.

> would indicate the current time, not the validity time of the CRL.

The time stamp needs to be placed either before the key is compromised (or
revoked) or before the end of validity of the certificate of the key that is
intended to be protected, which ever is the sooner. See the TSP document for
further details.

> something in the discussion.)

You did. :-)  I hope that the explanations above give you the answer.

Regards,

Denis