Subject: TSP: Response to the comments raised by Russ Housley

From: Denis Pinkas <[email-masked]>
Date: Fri, 22 Sep 2000 16:46:29 +0200

Russ,

Here are proposed resolutions for the 24 comments you sent during
the IESG last call period for the document:
<draft-ietf-pkix-time-stamp-09.txt>

Would you tell us if you are satisfied with these resolutions ?

Denis 

======================================================================

Note the comments have been numbered so that it is easier to refer
to them.

TECHNICAL

1. Section 2.1, 6th requirement.  I do not understand "hash-function 
OID."  OIDs, when managed correctly, are collision free.  I think we
need 
to be discussing the one-way hash function, not its OID.  The
selected 
one-way hash function must be uniquely identified by an OID.

RESOLUTION: Changed the text into: 

   to only time stamp a hash representation of the datum, i.e.
   a data imprint associated with a one-way collision resistant 
   hash-function uniquely identified by an OID.

2. Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The
text says 
that the client SHOULD make the check, but that the client MAY elect
to 
skip the check.  The checking requirement is either a SHOULD or a
MAY, it 
cannot be both.

RESOLUTION: The second sentence which contains the MAY has been
deleted (i.e. "The client MAY ignore this field if that is
acceptable for the intended application".)

3. Section 2.4.1, reqPolicy Discussion.  I do not think that a
reference to 
RFC 2459 is adequate.  First, I do not believe that a certification
policy 
and a TSA policy are equivalent.  At a minimum, the TSA Policy and
TSA 
Practice Statement will have significantly different content.  These 
differences need to be discussed.  Second, I would prefer syntax
without 
qualifiers.  What value do they add in the TSA context?

RESOLUTION: The current wording is as follows: " The reqPolicy
field, if included, indicates the policy under which the
TimeStampToken SHOULD be provided. PolicyInformation is defined in
Section 4.2.1.5 of [RFC2459]."
The second sentence only means that the ASN1 syntax of
PolicyInformation is defined in this document. It is true that a
certification policy and a TSA policy are fairly different but it is
not intended here to go into more details. A separate document on
TSA policy would certainly be useful. Such a work item is being
initiated by ETSI. The results will be presented to the IETF when
available, so that, if the WG agrees, an RFC can be issued. Unless a
proposal is made to clarify the wording, it is believed that no
change is necessary.

4. Section 2.4.1, nonce Discussion.  Please replace "shall" with
"MUST."

RESOLUTION: Done.

5. Section 2.4.2, 3rd paragraph.  The text does not match the
comments in the 
ASN.1 structure.  I assume that the comments are correct.  Please 
rewrite.  I suggest:
  When status contains the value zero or one, a Time Stamp Token
  MUST be present.  When status contains a value other than zero or
  one, a Time Stamp Token MUST NOT be present.  One of the following
  values MUST be contained in status:"

RESOLUTION: It is a good catch for the missing "or one". The rest is
a clarification which has been incorporated

6. Section 2.4.2, 11th paragraph (counting paragraphs is difficult
since the 
ASN.1 fragments are not indented).   Please replace "shall" with
"MUST."

RESOLUTION: Done.

7. Section 2.4.2, serialNumber Discussion.  Please reword the last
sentence to 
include a MUST.  I suggest: "This property MUST be preserved even
after an 
interruption in service (e.g. crash)."

RESOLUTION: Done.

8. Section 2.4.2, genTime Discussion.  Please replace "shall" with 
"MUST."  There are at least five occurrences.

RESOLUTION: Done.

9. Section 3.1.  How does the MIME type distinguish a time stamp
request from 
a time stamp token?  The recipient must either decode a TimeStampReq
or a 
ContentInfo, and this does not provide enough information to
determine 
which operation to perform.

RESOLUTION: While the direction of flow should indicate which
content type to expect, it would probably make things easier if
there were two content types.  Thus, Section 3.1 has been changed to
read:

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 2 and Appendix D via 
Internet mail.

Two MIME objects are specified as follows:

   Content-Type: application/timestamp-request
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp request message,
base64-encoded>>

   Content-Type: application/timestamp-response
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp response message,
base64-encoded>>

These MIME objects can be sent and received using common MIME
processing 
engines and provides a simple Internet mail transport for Time Stamp 
messages.

10. Section 3.2.  It would be helpful to specify file extensions for
a time 
stamp request and a time stamp token.  Such extensions would permit
the 
recipient to determine which decode to perform.

RESOLUTION: This is similar to the previous comment.  It was thought
that the direction of flow should indicate which decode to perform. 
However, in order to be more helpful, the following paragraph has
been added to Section 3.2:

A Time Stamp Request MUST be contained in a file with file extension
".tsr".  A Time Stamp Response MUST be contained in a file with file
extension ".tst".

11. Section 3.3.  It would be useful to implementors to include the
state 
machine for the TCP-based protocol.

RESOLUTION: It's not clear that this is required.  I would note that
the TCP-based protocol is based on the TCP-based protocol from CMP
and that none is included there.  If a state machine is required, it
should be included in the draft for CMP transport protocols.

12. Section 3.4.  How does the MIME type distinguish a time stamp
request from 
a time stamp token?  The recipient must either decode a TimeStampReq
or a 
ContentInfo, and this does not provide enough information to
determine 
which operation to perform.

RESOLUTION: This is similar to previous comments.  In order to help
determine which operation to perform, Section 3.4 has been
re-written as:

This subsection specifies a means for conveying ASN.1-encoded
messages
for the protocol exchanges described in Section 2 and Appendix D via
the
HyperText Transfer Protocol.

Two MIME objects are specified as follows.

Content-Type: application/timestamp-request

   <<the ASN.1 DER-encoded Time Stamp Request message>>

Content-Type: application/timestamp-response

   <<the ASN.1 DER-encoded Time Stamp Response message>>

These MIME objects can be sent and received using common HTTP
processing
engines over WWW links and provides a simple browser-server
transport
for Time Stamp messages.

Upon receiving a valid request, the server MUST respond with either
a
valid response with content type application/timestamp-response or
with an HTTP
error.

13. Section 4, item 4.  Each of the transports specified has
different delay 
characteristics.  This should be pointed out.

RESOLUTION: The following sentence has been added to the end of
Section 4, 
Item 4:

Since each transport method specified in this document has different
delay characteristics, the period of time that is considered
acceptable will depend upon the particular transport method used, as
well as other environment factors.  

EDITORIAL

14. Whole document.  Either add "SHALL" to the list of words that
you say are 
defined in RFC 2119, or change "SHALL" to "MUST."

RESOLUTION: "SHALL" has been added.

15. Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the
second to 
last sentence.  It should say: "For more details about replay attack 
detection, see the security considerations section (item 6)."

RESOLUTION: Done. 

16. Section 2.4.1, MessageImprint Definition.  I suggest the
replacement of 
"hashedMessage" with "MessageHash."  To me, the current name implies
the 
full message text rather than a hash of the message text.

RESOLUTION: This would make an ASN1 change. hashedMessage cannot be
the full message, since this is a hashed Message. MessageHash would
be a little bit more descriptive, but I think we can live with
hashedMessage. Not done.

17. Section 2.4.1, certReq Disscussion.  Typo.  Please move the
comma.  The 
sentence should read: "If the certReq field is missing or if the
certReq 
field is present and set to false, then ..."

RESOLUTION: Done.

18. Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the
registry calls 
this OID id-ct-TSTInfo. Second, I think that it would be more
readable to 
define it as follows:
	id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840)
		 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

RESOLUTION: Done.

19. Section 2.4.2, genTime Discussion.  Some require course
granularity, others 
require fine granularity.  I suggest that a TSA MUST offer at least
1 
second granularity.  Filling in the genTime structure with "00" as
the 
seconds does not meet this requirement.

RESOLUTION: The sentence "GeneralizedTime values MUST include
seconds" has been added. Filling in the genTime structure with "00"
" as the seconds is allowed and does meet this requirement.

20. Section 2.4.2, accuracy Discussion.  I think that a bit more
discussion is 
needed.  the syntax permits the seconds and micros fields to be
present and 
the millis to be absent.  I am not sure how to add and subtract such
a 
structure.

RESOLUTION: The following sentence has been added: "If either
seconds, millis or micros is missing, then a value of zero MUST be
taken for the missing field."

21. Section 2.4.2, ordering Discussion.  Please replace the last
sentence with: 
"... TSA can always be ordered based on the genTime field,
regardless of 
the genTime accuracy.

RESOLUTION: Done.

22. Section 2.4.2, tsa Discussion.  Please change "an hint" to "a
hint."

RESOLUTION: Done.

23. Section 4, item 6.  Please change "(algorithm and)" to
"algorithm and."

RESOLUTION: Done.

24. Appendix A.  First, the registry calls this OID
id-aa-timeStampToken. 
Second, I think that it would be more readable to define it as
follows:
	id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

RESOLUTION: Done.