Subject: RE: When is Timestamp applied?

From: Michael Zolotarev <[email-masked]>
Date: Thu, 15 Jul 1999 21:23:30 +1000

Denis, Sean,

Does a person who is not currently in Oslo have a right to say :)?

From the practical point of view, I do not see much benefit in putting extra detail into the stamp. What the time stamp is for? To provide an evidence that a datum existed AT LEAST at certain time. This CERTAIN time is just an astronomical time, which has no inherit reference to a particular TSA's implementation.
Just think about it: You've got a stamp, and it indicates one of your 3 cases - how do we interpret it?
Case 1. The time was 12.34.56.789, and it is a time the request entered the TSA box. Conclusion: the datum existed AT LEAST at that time.
Case 2. The time was 12.34.56.789, and it is a time the request was processed by the crypto. Conclusion:the datum existed AT LEAST at that time. It may have also existed some fraction of the seconds before. But nobody can provide any reasonable estimate of it. And even more important, no serious verifier will accept it as a valid argument.
Case 3. ...existed AT LEAST .... The conclusion is the same as in 2.

So, thinking practically, the flag may be not such a good thing.

However, it may worth saying in the draft that "TSA should take all possible care to ensure that the time indicated in the stamp is the earliest possible time that TSA could practically apply to the message".

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, July 15, 1999 7:42 PM
To: Sean Turner
Cc: [email-masked]
Subject: Re: When is Timestamp applied?

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

> 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: "Todd S. Glassey" <[email-masked]>
Date: Thu, 15 Jul 1999 07:45:09 -0700

----- Original Message -----
From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 15, 1999 4:23 AM
Subject: RE: When is Timestamp applied?

> From the practical point of view, I do not see much benefit in putting
extra detail into the stamp. What the time stamp is for? To provide an
evidence that a datum existed AT LEAST at certain time. This CERTAIN time is
just an astronomical time, which has no inherit reference to a particular
TSA's implementation.

> Case 1. The time was 12.34.56.789, and it is a time the request entered
the TSA box. Conclusion: the datum existed AT LEAST at that time.

No what this says is that the "counter that was running on the systems that
issued the stamp said the increment that this event happened at was
HH:MM:SS:HH".

The fact that we use a timebase style counter and that we have at some point
synchronized this counter with another counter that hold what we refer to as
a credible timesense, means that we as humans can interpret the context of
the counter as what we know as time.

What the system in question is about IMHO, is the remote issuance of an
event token that is refered to as a timestamp becuase the data in the token
that is used as the proof model is that counter-thing again... displaying
data in what we call "time format".

Becuase of this and that there is no local sense as to the validty of the
timebase under the system submitting the event for verification, the real
issue here is the latency in getting from the issuing body to the stamping
system. The proof model is then not relative to anyting that is in the
submitted token, if it happens to be accuirate, then all the better, but the
only binding part of the model is when the token is stamped at the "TSA"
system.

> Case 2. The time was 12.34.56.789, and it is a time the request was
processed by the crypto. > Conclusion:the datum existed AT LEAST at that
time. It may have also existed some fraction > of the seconds before. But
nobody can provide any reasonable estimate of it. And even more > important,
no serious verifier will accept it as a valid argument.

Yes this is exactly true!. The issue is that in an event logging model,
knowing what time the event got to the logger sets the "event proof time" as
that time. Not what time the event got to the event processing engine. That
is why we (both McNeil and I) have been standing on this soapbox about that
'Timestamping as a proofing model needs to be embedded in the system that
uses it' to have what we refer to as "the likely best level of legal
consequence"

BTW all - Can we use another word in these responses besides Datum, it
confuses the issues because of Datum Corp's entry into secure time.

> However, it may worth saying in the draft that "TSA should take all
possible care to ensure that the time indicated in the stamp is the earliest
possible time that TSA could practically apply to the message".

I propose that what is needed is a local model where the TSA style
technology is used in a vertical system, that is to say that the TS API as
defined by the current draft be amended so that it functions cleanly as an
embedded system as well as a distributed one.

My feeling is that if this were done that it would be possible to merge the
BERT token structures with the TSA model and get on with event logging as a
whole.

Todd

---

From: "Bill Lattin" <[email-masked]>
Date: Thu, 15 Jul 1999 08:27:19 -0700

I agree with Michael's analysis.  The granularity within a TSA will be of
limited practical use.

For someone trying to beat someone else to the "punch", I can envisage this
person trying to use a system that stamps earlier than another - this
situation will always exist regardless of flagging the 3 cases since
implementations will always differ.  Short of prescribing an actual
implementation that all must use, there will always be variations as to when
time was applied.

At least if the TSA's are synchronized to a National Timing Authority, most
could agree on the time.

Bill

> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Thursday, July 15, 1999 04:24
> To: Denis Pinkas
> Cc: [email-masked]
> >From the practical point of view, I do not see much benefit in
> putting extra detail into the stamp. What the time stamp is for?
> To provide an evidence that a datum existed AT LEAST at certain
> time. This CERTAIN time is just an astronomical time, which has
> no inherit reference to a particular TSA's implementation.
> Case 1. The time was 12.34.56.789, and it is a time the request
> entered the TSA box. Conclusion: the datum existed AT LEAST at that time.
> Case 2. The time was 12.34.56.789, and it is a time the request
> was processed by the crypto. Conclusion:the datum existed AT
> LEAST at that time. It may have also existed some fraction of the
> seconds before. But nobody can provide any reasonable estimate of
> it. And even more important, no serious verifier will accept it
> as a valid argument.
> However, it may worth saying in the draft that "TSA should take
> all possible care to ensure that the time indicated in the stamp
> is the earliest possible time that TSA could practically apply to
> the message".
>

---

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

Mike,

I'd actually be in favor of just saying that the time indicated in the timestamp should be when the TSA signed the data.

spt

---

From: Paul Koning <[email-masked]>
Date: Mon, 19 Jul 1999 14:20:56 -0400

>>>>> Sean Turner <[email-masked]> writes:

 > Mike, I'd actually be in favor of just saying that the time
 > indicated in the timestamp should be when the TSA signed the
 > data.

 >> time....

I think Mike's argument implies that constraining it to be "when the
TSA signed the data" is not necessary.

Another argument: protocol standards and protocol conformance
statements should be assertions about EXTERNALLY OBSERVABLE behavior.
This is a fundamental rule of standards design.

The definition Mike proposed has that property.  The one Sean proposed 
does not.

If I put a black box containing a TSA implementation in a lab and
send requests at it, I can verify that the time stamps returned are
not earlier than the request arrival time, and not later than the
response transmit time, but I have no way of knowing more than that.
Therefore the spec cannot and must not imply any more than that.

	paul

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jul 1999 09:57:37 +0200

Paul,

The token provides an evidence that a datum existed AT LEAST at the time
included in the token.

So no additional information is needed INSIDE the token. ... However, the
*security policy* of the TSA may be to indicate that the time that will be
placed inside the TST is the time of arrival in the FIFO or the time
associated with the crypto operation. This may make a few seconds of
difference. When the time is critical, some users may choose to use a TSA
using the time of arrival rather than the time of time stamping.

We may need to indicate this in the draft.

Denis

---

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 20 Jul 1999 07:37:45 -0700

Can we use another term besides Datum. It confuses the issue of Datum
Corporation being a timing services supplier here in PKIX.

Todd

---

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 20 Jul 1999 08:22:35 -0700

Actually Denis,

----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Paul Koning <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 20, 1999 12:57 AM
Subject: Re: When is Timestamp applied?

> The token provides an evidence that a datum existed AT LEAST at the time

So which "time" is this. The "time" that the source_system says the event
occured, the time the event reached this TSA or what? - and if the token
(TST) is totally free-form and there is no standard as to what the event is
supposed to look like, why then would I need a standard for the process of
making something that was as such, a moving target?

Why would I care about the protocol of creating a mark if the mark itself is
not the standardized entity?

>
> So no additional information is needed INSIDE the token...

My problem here is that there is no published end use model for the
services - to my knowledge, so how do you know what is actually needed in
the token structure itself? - The answer is that you dont. It seems to me
that what I am hearing is that the process is what is being standardized
here, and that is not the right goal in my book.

>However, the
> associated with the crypto operation.

You're still arguing here about what or which time to stick in the token and
the policy that attaches to it.

Yes, the security policy about the system and how it works must be available
to the person using the system or the person(s) validating events through
it. Depending on the Token Size constraints, this data may or may not want
to be included in the token itself, likewise if not included in the token
structure, it will need to be available by reference externally through some
facility.

> This may make a few seconds of
> difference. When the time is critical,

Ah Ha, here we are talking about "when time is crititical" which gets us
back to that we need better precision or at least user definable precision
in the token structure itself. And by the way, it sounds like there are
several different token structures now by your comments, So where then is
the interoperability between the different methods and how is it
accomplished?

>some users may choose to use a TSA

Much to everyone's chagrin I am sure, let me reiterate that the keys to
timestamping are the token structure that is provided, the method of getting
the "time data" into the process, and the system that applies the
"timesense" to the event structure in question to create the token itself.
The system should be built around proving the business issues of the
"proofing models" not the technical ones. This, IMHO, is clearly a system
where PKI has experienced too much streroidial input. The system that has
been developed is a very elegent mechanism that applies limited resolution
time to an event and stamps it remotely.

My feeling is that the big win here in timestamping is that we standardize
tokens and the mechanisms/processes to get secure time into systems. Let the
auditors prove that the tools we build actually build and manage the tokens
as we intend them too. This is the win here.

> We may need to indicate this in the draft.

What the draft really needs is a new edition that takes into account that
the actual system producing the timestamps could easily be either SW or HW
in nature, and that it can run in the same context as the server that is
dependant on its auditing. It needs at the very least a mechanism to specify
whether the event in question is marked with absolute or relative time, and
what the timebase resolution is, if its absolute. It also needs to policy of
the event etched into the token so that it can be freerenced externally or
later as a stand-alone event proof or atleast referencable. Perhaps a
standard set of POLICY OIDS would work here for that.

If we don't take into account the end use models, then what "it" is, is a
distributed, network segragated, model for applying a limited resolution
timestamp, from an undefined timesource to an object that its trust model
cannot prove. What is usually referred to as the qunitiessential Trusted
Third Party System -  ala "It works becuase I said it did - nee-ner,
nee-ner, nee-ner".

Am I wrong or what have I missed here?

> Denis

You know - from my perspective - the reality is that more and more of what
we work on here in PKIX is not "network" or distributed computing dependant
and rather is OS Context dependant, or based in how and what trust and
assurance models are, but since there is so little difference between the
OS' of today and the underlying networking or virtual system environment, it
is easy to see how the confusion occured.

Todd

---

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jul 1999 11:50:58 -0400

>>>>> "Todd" == Todd S Glassey <[email-masked]> writes:

 Todd> Can we use another term besides Datum. It confuses the issue of
 Todd> Datum Corporation being a timing services supplier here in
 Todd> PKIX.

So?  Datum is the singular of data.  The fact that a company picks a
standard English language word as its corporate name is not a good
reason to avoid using that word.  Especially since hundreds or
thousands of company names or product trademarks are ordinary words,
it is neither desirable nor even possible to attempt to avoid using
those words.

	paul

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jul 1999 17:56:49 +0200

Todd,

You have more talkative than I am. :-)

You missed the point that a policy is always included in the token. That policy
specifies among other things the meaning of the time. We only have a time
relative to UTC and already have a way to indicate its accuracy when compared to
UTC, whether it is minutes, seconds or subseconds.

The basic mechanism also allows to have the two systems co-resident  *even if
this is not needed for PKIX usage*. I will allow some comments -  from others -
before proposing the slight change I indicated at the IETF meeting: the use of 4
parameters instead of 3.

Regards,

Denis

---

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 20 Jul 1999 14:44:06 -0700

Thanks Denis -
----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Todd S. Glassey <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 20, 1999 8:56 AM
Subject: Re: When is Timestamp applied?

> You have more talkative than I am. :-)

Yes, I do tend to rant a bit -

> UTC, whether it is minutes, seconds or subseconds.

I understand, what you are saying and agree partially, at least - that what
we really need is a set of common ploicy statement OIDS and the like to
minimize the structure and size of the TST itself. Still then it is the TST
that becomes the point of Interoperability rather than the routines that
made it.

> before proposing the slight change I indicated at the IETF meeting: the
use of 4

Thats good.

Todd