Subject: Re: New TSP draft

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jun 1999 16:19:56 +0200

Here some comments:

> 
> 1) The introduction has been re-written.
> 
> 2) The status has now be placed outside the Time Stamping Token
> (TST).

You have no longer any means to create a signed response from
the TSA indicating that you cannot create a time stamp. 

I try to resume the discussions: 

- There were requests to create an unsigned error message; 
  That's what you have created (although I don't understand
  why you have a SEQUENCE and not a CHOICE, since success
  is the only case where you can have a token, thus the value
  of success itself is redundant. 
  
- The same argument apply for a signed error message, thus the
  TSTinfo could be a 

  TSTInfoOrError = 
     CHOICE {   pkistatus [0] PKIStatusinfo ,
                              tstinfo   [1] TSTInfo 
            }

  which in fact is equivalent with the syntax of the previous draft
  but somewhat nicer. 

Of course, if the lower layer protocol is hhtp over SSL,
or direct socket over ssl, then a signed error is not necessary. 
  
> 
> 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.

Why that: It is an unsigned integer, so why an encoding
as a bit string. 

In fact, why is this an integer at all. 

The fraction of a second could be encoded with a generalizedtime.
Why not making it optional?

I think that the precision should be an optional element,
a TSA may be not be able or willing to give such a detail, or
specify it in a policy. 

The whole TSTTime may be optional then, and the signingtime
attribute MAY be used instead??
  
> 
> 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."
This sentence seems useless, since it is redundant. The
question is not that you create an error message, any http server
does that from time to time, BUT rather how a client should
interprete it. 

"It is up to the client to decide how to react on an http
 error message."

"Unless when the http layer is encapsulated inside an ssl layer, 
 an http error message or un unsigned error message cannot be
 trusted as a definitive indication of the servers status."

There are a few spelling errors in the text:

     1. to provide a trustworty source of time.
                     trustworthy

    3. to include a monotonically incrementing value of the time of day 
                                  increasing
        for each newly generated time stamp token.

> The time stamp token MUST NOT contain any signatures other than the 
> signature of the TSA. The certificate identifier of the TSA 
> certificate shall be included as a signed attribute.
              ?????

And why that phrase, why couldn't you have more than one entity
sign the time stamp? 

Remove the Content-Transfer-Encoding: in 3.3:

A simple MIME object is specified as follows:

The Content-Type is application/timestamp, and the content is a
DER encoded time stamp message, encapsulated with an appropropriate
content-transfer encoding.

The comment about identification of the requestor at the beginning
of page 5 should probably be included in 3.3 and 3.4, and it
should not only mention authentication, but also confidentiality.