Re: TSP version 03

[[e-mail]]

Denis,

The TSP-over-TCP protocol defined in the new draft suffers from some of the
same problems we found in the CMP-over-TCP protocol in RFC 2510.  I would
suggest that the changes recommended in the new
draft-ietf-pkix-cmp-tcp-00.txt be applied to TSP-over-TCP as well.  These
changes include:

i)  Changing the "poll time" from an absolute time to a delta time.  This
is more robust than an absolute time in the event of a clock-skew between
requester and responder, and also doesn't suffer from the Y2038 problem.

ii) Changing the protocol to contain an explicit version number field to
allow for future changes.

iii) Specifying whether the TCP connection may remain up to carry multiple
TSP requests, and which end is responsible for closing it.

John





Denis Pinkas <[e-mail]> on 09/21/99 09:18:04 AM

To:   IETF-PXIX <[e-mail]>
cc:

Subject:  TSP version 03


A new draft of the Time Stamping Protocol (TSP) has been published
at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-03.txt

The draft attempts to accommodate the issues raised at the Oslo
meeting, comments received at the Oslo meeting and comments sent on
the PKIX mailing list.

Issues raised at the Oslo meeting:

1) Format of the TSTTime (inspired form NTP)
2) TDA (Temporal Data Authority) support.

1) A new TSTTime has been defined. It fairly simple and composed of
two fields, one field using GeneralizedTime and allowing to specify
the time below the precision of a second and another optional field
allowing to specify the accuracy in seconds or sub-seconds when that
precision is *not* plus or minus one second. It is expected that
many TSA will not use the precision field and thus will produce the
time according to RFC 2459 section 4.1.2.5.2. with plus or minus one
second for the precision.

In addition the previous draft was attempting to provide a
chronology between two time stamps issued by the same TSA within the
same second (assuming sub-seconds were not used). This can now be
provided using the serial number which is being made mandatory.

2) At the last meeting I advertised that if no one would produce a
"good" rational for supporting TDAs, TDAs would be removed. Since
such a rational has not been produced, the extension has now been
suppressed. However, it has been realized that we make making the
same original mistake that X.509 did with the version 1: omitting to
provide an extension mechanism. So an extension field has been
added. This allows anyone (including ISO) to define extensions in
the future, without impacting *this* document. TDAs could even been
re-introduced at any time in the future, but using the extension
mechanism.

Comments received at the Oslo meeting

3) Steve Kent during the meeting said that we should not confuse a
Time Stamp with a time information and thus requested the hash in
the request to be mandatory. This is now done.

4) some people complained about the fact that the TSA was making its
own judgment about the validity of the hash function used by the
requester. This requirement has been partly raised since the TSA is
now only required to know the OID of the hash function to make sure
that the length of the hash code is correct. So the OIDs need to be
known, but the TSA offers no guarantee about the strength of the
hash functions (the legal responsibility has disappeared).

Note: The filling dates for all patents have been added and a
warning about the *use* of the protocol has been added.

As a result of all of this, the document is now simpler and shorter.

Denis