Subject: When is Timestamp applied?

From: Sean Turner <[email-masked]>
Date: Wed, 14 Jul 1999 12:06:23 -0500

Denis,

At the meeting today you mentioned that the draft doesn't specify when
the timestamp is applied, either when the data was received or when the
signature was applied.  BUt, the slides you threw up from the ISO text
clearly indicated that the timestamp is applied when the signature is
generated.  I think the draft should either
- specify that the time in the timesatamp is the TSA's signture time or
- there should be field included (a choice) to indicate that the time is
when the data was received or when the TSA's signature was generated.

Otherwise, the meaning of the timestamp is very ambiguious.

spt

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 15 Jul 1999 11:41:49 +0200

Sean,

You are perfectly right, we need to say more in the document. Since the
protocol is transport independent but the time between the request and the
response is transport dependent, we need to indicate in the TST some
information to say whether the time is:

1) the time of reception of the request by the TSA,
2) the time when the request was entered/processed in the crypto engine of
the TSA,
3) the time which is en the request left the crypto engine of the TSA (if
the signature time can be estimated, then the signature time may be
anticipated).

Case 1. This case is relevant to smtp and ftp, where all the requests will
be time stamped according to the SAME date of reception.

Case 2. This case is relevant to sockets and HTTP, when there is a single or
few requests.

Case 3. This case is mostly relevant when the requester indeed is not
interrested in a time stamp, but by a signed time only. Under that
circumstance the time in the TST will be the closest to the time of the
response.

Since the STIME working group wanted to address this concern but was told
during their meeting that signed time will be addressed by PKIX, it would
make sense that we cover that case (I noticed that Steve Kent said in the
meeting that we should not). This is where time below the second is
important.

When there is no hash present in the response we could assume that the last
case applied. However, this would impose a specific implementation. I would
rather allow some kind of flexibility and RECOMMEND to allow the TSA to
indicate which case applies. The main reason is that in any case it is
simpler for an implementation to provide the case 2, i.e. the time when the
request was entered/processed in the crypto engine.

So the proposal would be to include a flag that would say which of the three
cases has been used by the TSA

The next question is then : should the requester be able to request which
case he would like to be supported ?
I would like to avoid this and thus not add any new parameter in the
request.

Instead I would rather RECOMMEND what the TSA SHOULD do for every case of
transport keeping in mind that it can use whatever scheme he likes, in
particular the case 2.

The proposal is thus :

1) to recommend for every transport which of the three cases should be used,

2) to recommend when there is no hash present in the request to use case 3,
3) to allow the TSA to include a flag (taking the values 0, 1 and 2) stating
to which instant the time of time stamping applies.

If there is some consensus around this proposal, I will then propose an ASN1
translation of it, along which new text.

Regards,

Denis

---

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 15 Jul 1999 07:46:32 -0700

I have a small question....

----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 15, 1999 2:41 AM
Subject: Re: When is Timestamp applied?

> meeting that we should not). This is where time below the second is

Why doesn't PKIX assign these efforts in a delegated manner to STime and
make the STime folks produce a schedule for "it". It seems to me that PKIX
is swelling to address the totality of the PKI enablement world, and you
know - this is likely to be appropriate. However my feeling is that PKIX
would be warrented in allowing other fledgling orgs like STime and its more
developed bretheren like the XML DigSig groups to offload some of the core
enablement at the application construct levels. PKI will be the forum where
these all come together in the IETF and to my mind that reinforces the
structure and the operations of the Security Area and its local Directorates
actions in the furtherance of the marketplace.

I see this as a big win potentially for the PKIX Chairs and the IETF as a
whole since it will mandate putting in place something thast defines IntraWG
processes to handle a "formal delegation" of responsibility.

Todd

---

From: Sean Turner <[email-masked]>
Date: Thu, 15 Jul 1999 17:53:37 -0500

Denis,

I agree that all of the examples you present are true, but I hope the difference
between 2 and 3 are pretty close to zero ;)

I think to keep it simple we should just go with when the signature was applied,
whether that be right when the TSA gets the data or at some later time (I assume
a properly acting TSA will sign the data ASAP).  I know there are differences
between the time when signature is asked for and when the signature generation
is completed, but like I said earlier I hope they are really really small (i.e.,
negligible).

spt

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jul 1999 16:43:07 -0400

>I have a small question....

<deleted message from Denis>

>actions in the furtherance of the marketplace.

Todd, the secure time WG has a well dfined charter, and it does not include
time stamping.  PKIX amended its charter to encompass time stamping, but
only to the extent that it relates to PKI.  We have adequate intra-WG
relationships among the groups you cite in your message.  XMLDigSig has
nothing to do with this topic, at least at this time.

>processes to handle a "formal delegation" of responsibility.

If you feel that the process is not working, feel free to raise the
question with the Security ADs.

Steve