Changes to the TSP protocol

[Denis Pinkas <[e-mail]>]

Summary of the changes to TSP to produce <draft-ietf-pkix-time-stamp-13.txt>

The following changes have been provided in order to respond to several
comments raised by Jeff Schiller, our Security Area Director, who has
reviewed the document before its presentation to the IESG. Jeff has
indicated that these changes were correctly addressing his concerns.

1. What does it mean to be a "known" algorithm ? 

The current text states the following, which was not precise enough:

" The hash algorithm indicated in the hashAlgorithm field MUST be a known
hash algorithm (one-way and collision resistant)."

The new text is the following (changing a MUST into a SHOULD):

  The hash algorithm indicated in the hashAlgorithm field SHOULD be
  a strong hash algorithm.  That means that it SHOULD be one-way and
  collision resistant.  The Time Stamp Authority SHOULD check whether 
  or not the given hash algorithm is known to be "sufficient" (based 
  on the current state of knowledge in cryptanalysis and the current 
  state of the art in computational resources, for example). If the 
  TSA does not recognize the hash algorithm or knows that the hash 
  algorithm is weak (a decision left to the discretion of each 
  individual TSA), then the TSA SHOULD refuse to provide the 
  Time Stamp Token.

2. PKIStatus values

The current text states the following:

" Compliant servers MUST NOT produce any other values. Compliant clients
MAY ignore any other values."

This would create a problem if other values were added. The new text is the
following (changing a MUST into a SHOULD):

" Compliant servers SHOULD NOT produce any other values. 
Compliant clients MUST generate an error if values it does not understand
are present."

3. PKIFailureInfo

The current text states the following:

" These are the only values of PKIFailureInfo that are supported.
Compliant servers MUST NOT produce any other values. Compliant clients MAY
ignore any other values."

As above, this would create a problem if other values were added. The new
text is the following (changing a MUST into a SHOULD):

" These are the only values of PKIFailureInfo that SHALL be supported.
Compliant servers SHOULD NOT produce any other values. 
Compliant clients MUST generate an error if values it does not understand
are present."

Note: In order to align the document with RFC1510bis (CMP) an additional
error has been added (initial request from Francois Rousseau):

systemFailure       (25)
      -- the request cannot be handled due to system failure

4. Big Typo left.

The following temporary explanatory text was left and has been deleted.

" should read: 'Such syntax, .... to represent time *within* one
second, may be used here' (omit 'to')."

5. Removal of Annex C.

This annex C which contains the MIME Registrations forms to IANA for
timestamp-query and timestamp-reply will be removed as soon as an RFC number
is obtained and will be sent to IANA.

6. Unsigned integer

The text states: 

The "time-to-check-back" parameter is a 32-bit integer, defined to be
the number of seconds that have elapsed since midnight, January 1,
1970, coordinated universal time.

The word "unsigned" has been added before integer.

7. Security consideration section cases 1 and 2. 

In the security consideration section the difference between case 1 and case
2 was not clear enough, in particular because the first sentence was
misleading, stating :" the TSA can no longer be trusted". 

In order to distinguish better between the two cases, the text replacement
is:

     1. When a TSA shall not be used anymore, but the TSA private key 
        has not been compromised, the authority's certificate SHALL 
        be revoked. When the reasonCode extension relative to the 
        revoked certificate from the TSA is present in the CRL entry 
        extensions, it SHALL be set either to unspecified (0), 
        affiliationChanged (3), superseded (4) or cessationOfOperation 
        (5). In that case, at any future time, the tokens signed with 
        the corresponding key will be considered as invalid, but 
        tokens generated before the revocation time will remain valid.
        When the reasonCode extension relative to the revoked 
        certificate from the TSA is not present in the CRL entry 
        extensions, then all the tokens that have been signed with 
        the corresponding key SHALL be considered as invalid. For 
        that reason, it is recommended to use the reasonCode 
        extension.

2.      When the TSA private key has been compromised, then the 
        corresponding certificate SHALL be revoked. In that case, 
        the reasonCode extension relative to the revoked certificate 
        from the TSA may or may not be present in the CRL entry 
        extensions. When it is present then it SHALL be set to 
        keyCompromise (1). Any token signed by the TSA using that 
        private key cannot be trusted anymore.  For this reason, it 
        is imperative that the TSA's private key be guarded with 
        proper security and controls in order to minimize the 
        possibility of compromise. In case the private key does 
        become compromised, an audit trail of all tokens generated 
        by the TSA MAY provide a means to discriminate between genuine 
        and false backdated tokens.  A double time stamping from two 
        different TSAs is another way to address this issue.

8. Security consideration section case 4. 

In the security consideration section, case 4, it was not clear enough in
which case the attack was applicable. The new text explains that the case
applies in case a nonce and no local clock is being used.

The original first sentence was: 

     4. An application using the TSA service SHOULD be concerned 
        about the amount of time it is willing to wait for a response.

The new sentence is:

     4. A client application using only a nonce and no local clock 
        SHOULD be concerned about the amount of time it is willing 
        to wait for a response. 

Denis