[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