Re: [IETF-PKIX] Comments on IPKI Part V: Time Stamp Protocols

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Deepak;

Thanks for your comments on our time stamp document.  My responses are
below.

>----------
>From:  Deepak Nadig[SMTP:deepak@vfi.com]
>Sent:  Saturday, December 06, 1997 6:52 PM
>To:    ietf-pkix@tandem.com
>Subject:       Comments on IPKI Part V: Time Stamp Protocols
>
>Hi,
>
>The following are my comments on the specification.
>
>1. [Page 2, Section 2.2]
>
>    The semantics of a 'valid request' should be described. I can only
>derive that a valid request is one that can be decoded properly. Is
>there more ?

A valid request is one that can be decoded properly, has the correct
form, has the correct TSA name.  This will be made more clear.
>
>2. [Page 2, Section 2.4]
>
>    It looks like the TMP is restricted to timestamp messages. Shouldn't
>the TMP timestamp any data, and leave the contents of the data to be
>defined by the application ? If the concern is the size of the data,
>then TMP should recommend that the sizes be made small by sending the
>Digest of the data (I would recommend the use of PKCS DetachedDigest
>type here), instead of the data itself.

I believe that is what the document currently says.  I will review it to
see if we can make this clearer.
>
>3. [Page 2, Section 4]
>
>    I recommend that the request message should carry a Nonce that is
>reflected in the response. This is to prevent replay attacks.

Agreed.
>
>4. [Page 2, Section 4]
>
>   I would recommend that the messages also carry a version field in
>them. In general, this applies to other PKI protocol messages (like
>OCSP, etc.) as well.

Fair enough.
>
>5. [Page 2, Section 4]
>
>   Following (2), messageImprint should be an open type.
>
>6. [Page 3, Section 4]
>
>   Please consider using PKCS SignedData for defining the response
>message. Is there a reason why it is not used ?

Is there a reason why we should use PKCS SignedData instead of what we
have defined?
>
>7. [Page 3, Section 7]
>
>   Applications using TMP should also be concerned about the the amount
>of time it is willing to wait for a response. A 'man in the middle' can
>introduce delays in the request message, to determine the time that the
>application sees in the response.

This could be included under "Security Considerations".

        Robert.
>
>