Subject: TSP version 03

From: Denis Pinkas <[email-masked]>
Date: Tue, 21 Sep 1999 15:18:04 +0200

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

---

From: [email-masked]
Date: Thu, 23 Sep 1999 07:14:59 -0400

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 <[email-masked]> on 09/21/99 09:18:04 AM

To:   IETF-PXIX <[email-masked]>
cc:

Subject:  TSP version 03

Denis

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Sep 1999 10:12:50 -0400

>In short, saying "add an explicit version number field" to allow for
>future changes is both easy and ineffective.

I disagree.  It makes it easy to "bail out" quickly and generate a
useful diagnostic.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Sep 1999 12:35:35 -0400

>You can generate an *additional* diagnostic ("unrecognized version
>number field"), but how useful is it?

It's been very useful to be able to report "Received v3 packet from joe"
rather than "Received bad packet from joe."

>how much quicker is it to parse and handle an explicit
>version field than to omit the field and allow version mismatches to
>be treated as any other malformed-ness error?

It can be significant, especially if I can avoid having to read in the
entire packet and start parsing.

>The recent discussion of v1/v2 CRLs is illustrative of the problem with
>version numbers. ... [elided]

I don't know the issue well enough to understand, other than to say that it
sure looks like ISO did a poor job of specifying the how/when extensions are
to appear.  If extensions are an optionally array of key/value pairs, then
I don't see why "v2 w/o extensions" is an issue.  (I'm not asking to open
that discussion, here, I'm just claiming that your example doesn't prove
that
version numbers are wrong, but rather that some mistake was made somewhere.)

>I don't want to have to think about what to do if I receive a cert with
>a SubjectUID field present and a version number absent (defaulting to v1).

You shouldn't have to think.  If they weren't defined in v1 then you
shouldn't
be looking for them. :)  Less flippantly, I think I understand a difference
in
where we're coming from. You're thinking of new code being able to handle
old
and new data structures.  I'm thinking of an existing deployed base being
able
to quickly and easily tell new code why they're not able to work together,
and giving the new code the option of going to "old fogey" mode.

---

From: "Life is hard, and then you die." <[email-masked]>
Date: Fri, 24 Sep 1999 02:00:58 -0700 (PDT)

> First off: I don't care whether you use the new CMP-over-TCP protocol 
> for TSP or not. [snip]

Actually, that's not quite true. It would be nice if the same protocol
were used to send CMP and TSP messages over TCP (and HTTP, for that
matter), as it means the same protocol library can be used. But I'm
obviously biased...

OTOH, I'm not quite sure why the "direct TCP based TSA message"
protocol is introduced at all. In CMP its raison d'être is to 
introduce a polling mechanism which is needed because of possible
manual intervention at the RA and other potential delays there.
I don't see this need with TSP. But I'm probably just missing
something.

  Cheers,

  Ronald