[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Comments on IPKI Part V: Time Stamp Protocols
Robert,
I have answered your questions below.
At 09:16 AM 12/15/97 -0500, Robert Zuccherato wrote:
>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?
The PKCS SignedData is already used in many protocols to carry Signed Data.
I recommended this to allow existing implementations to reuse that component.
Please note that you may need to define a profile (specific PKCS #9
attributes) for SignedData that carries Time Stamp Protocols data.
What you have defined is fine; I was trying to reduce the number of
representations of data structures that carry signed data.
>>
>>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".
Yes. That would be the best place for it.
Regards
Deepak
----------------------------------------------------------------------------
Deepak Nadig email: deepak@vfi.com
Payment Protocols Group Phone: 415-463-1217
Internet Commerce Division, VeriFone Fax: 415-462-6369