Subject: TSP: (Re-sent) Response to the comments raised by Russ Housley

From: Denis Pinkas <[email-masked]>
Date: Fri, 22 Sep 2000 17:02:13 +0200

This is a re-sent because of the number of CR/LF in the previous message.
*************************************************************************

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.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 25 Sep 2000 15:58:01 -0700

Denis

> (i.e. "The client MAY ignore this field if that is acceptable for the

Actually doesn't it seem to you that there are a number of sentences that
should be looked at under the same conceptual rule, and perhaps changed to
one that says something like "Provides optional or user selectable
functionality"

Again a AD would help tremendously for anyone's end-use model or method.

> RFC 2459 is adequate.

It may not be. Depends on what the use mdels for the TSP Services are.

> First, I do not believe that a certification policy
> and a TSA policy are equivalent.

I disagree. They are almost idenitcal, but the TSA's is more complex.  How
could they not be? If the TSA does not insure what it does, then its
worthless in the commercial environment. So, as a basic operating model the
TSA needs a CPS for its internal trust services as well as its external TPS
and RPA documents.

> At a minimum, the TSA Policy and TSA
> Practice Statement will have significantly different content.

A TSA is a trust service agent that says something digitally happened with a
PKI authenticated or other identity. The Certificate Authority is a
inedemnity provider service agency that identifies individuals and entities.
The TSA is exactly this and provides insurance around what time the event
occured.

The TPS or Timing Practices Statement is actually a superset of the CPS
since it has to also address the same issues as the CA as well as the audit
trail and certification of its timebase and time management processes.  I
can testify to this 'first hand' having participated  in the creation of
CertifiedTime's SLA and its TPS (Timing Practices Statement) & RPA's
(Relying Party Agrements ).

Todd