Subject: New TSP draft

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Jun 1999 12:10:44 +0200

Dear PKIX group members,

Robert Zuccherato who was the lead editor of the Time Stamp
Protocol, asked me take the position of lead editor for that
draft. I have accepted despite my current workload.

I have just posted to the draft editor the new version, i.e.
<draft-ietf-pkix-time-stamp-02.txt> and I hope it will be made
available shortly.

First of all, I would like to thank Robert for its effort (this
work has been started at the Memphis meeting) and I do hope that
he made most of the (unpaved) way for going to a WG last call.
Robert will not be present at the Oslo meeting, but I will and
thus I will present the document.

Hereafter is a summary of the main changes that have been
performed after observing some heavy traffic on the mailing list.

1) The introduction has been re-written.

2) The status has now be placed outside the Time Stamping Token
(TST).

3) The items 5 and 6 under the "Security Considerations" chapter
which is chapter 6 have been deleted.

4) The precisionFactor has been changed from INTEGER to BIT
STRING (but not to REAL) and the explanations are, I hope,
better.

4) I considered the comments/complaints on the mailing list about
the TDA and so I prepared the document for an easy deletion of
that part, should it be the case. This issue will be discussed at
the Oslo meeting. To this respect, I have clarified the role of
the TDA and changed the ASN1 syntax to place any OPTIONAL
elements needed for the support of the TDA at the very end of the
ASN1 structures. I also moved the explanatory texts accordingly.

5) I believe that the "waiting" status is not/no more needed (I
saw no reason in the text for having it) and thus I have
suppressed it for the sake of simplicity.

6) The Annex B has been changed and aligned it with the white
paper I co-produced with Hans Nilsson on the Validation of
Digital signature.

7) Serial Number.  It was suggested on the list that this should
be made mandatory and not optional, in order to help solve the
"who was first" argument when two timestamps contain the same
time.  The serial number should be used just for token
identification and that solving the "who was first" argument
belongs in the tstTime field. Therefore, it doesn't need to be
mandatory, OPTIONAL is fine for applications that require it.

8) CMP Encapsulation.  It was also suggested that we use CMP
encapsulation instead of CMS.  It is just another way of doing
things.  We have decided to use CMS encapsulation.  Unless there
is a clear reason to use CMP, we should just leave it as it is.
There were a lot of choices we could have made, we chose this,
let's live with it.

9) SEQUENCE OF MessageImprint.  There was quite a discussion
about whether or not we should allow a SEQUENCE of
MessageImprint's (i.e. allow multiple hashes of a document in a
single token).  I really don't see the point of this.  If someone
breaks SHA-1, the entire PKI crumbles.

10) Criticality of extended key usage.  Complaints have been sent
to the list about the extended key usage extension indicating
time stamping to be critical.  A key certified for use in
timestamping should not also be used for establishing an SSL
connection, for example. I have left the document as it were, for
the moment.

11) TSA name in token.  Some people don't want the TSA's name
included within the token.  Since it was originally there, I kept
it, but it is only a hint about the identity of the TSA. If you
get a name different from the one expected, there is indeed an
error. If you get the right name, additional checking is
necessary. This means that the field is optional and that the
certificate identifier used for signing the token is now part of
a signed attribute

12) HTTP errors.  Peter Sylvester has been complaining that we
don't specify what to do in the HTTP protocol when errors occur.
The following sentence has been added "Upon receiving a valid
request, the server MUST respond with either a valid
response with content type application/timestamp or with an HTTP
error."

13) AIA OID. OID's for the Authority Information Access extension
are neeed for both the TSA and TDA. They should be called
id-ad-timestamping and id-ad-temporaldata.

I hope that's most of it, as far as the technical aspects are
concerned.

14) From another aspect, a new patent has been added to the
(long) list.

Now, wait for the new draft. :-)

Denis

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 24 Jun 1999 20:54:41 +1000

Good luck, Denis. Looking forward to see the new draft. Though would be
nicer not to have any patents in there at all :)

What about the [boring issue of] messageTag?
Also, recently there was a good 'pick' by James Manger about GeneralizedTime
syntax, which itself allows defining time value down to fractions of second.

Regards
MichaelZ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 25 Jun 1999 18:23:47 +0200

Michael,

You were really in the "starting blocks", even not waiting until the new draft
was made available. :-)

> What about the [boring issue of] messageTag?

As you said "boring". It is currently left out because, in this way, the TSA
*may not be* in a position to learn anything about the context of use. This is
motivated from a legal point of view.

> syntax, which itself allows defining time value down to fractions of second.

There are various ways to address the problem. GeneralizedTime using a precision
below the second is certainly one. The one currently in the document has been
imported directly from the NTP document. NTP is using 32 bits words and
basically that format has been translated into ASN1.

In particular the precisionFactor which tells the precision of the clock. This
also gives the format of fractionOfSecond.

Using Generalized time up to the second only makes it consistant with the format
used in certificates and CRLs. This was the major motivation for choosing it.
There are however two additional needs solved by a single structure :
fractionOfSecond.

a) the need to make the difference between two time stamps within the same
second.
b) the need to give a precision below the second.

Basically the left bits of fractionOfSecond are meaningful as far as the
precision is concerned when the precisionFactor is negative, while the right
bits will certainly not be.

If the precisionFactor is nul or positive, none of these bits carry a time
information and in that case the field is only used to make the difference
between two time stamps within the same second.

These are basically the explanations that motivated this structure. There are
surely alternatives to the problem, we picked one based on the above
motivations.

Regards,

Denis