RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001

Note: This RFC has been updated by RFC 5816

Errata ID: 4042
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kyle Hamilton
Date Reported: 2014-07-05
Rejected by: Stephen Farrell
Date Rejected: 2015-05-12

Section 2.1 says:

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

   9.    not to include any identification of the requesting entity in
         the time-stamp tokens.

   10.   to sign each time-stamp token using a key generated exclusively
         for this purpose and have this property of the key indicated on
         the corresponding certificate.

   11.   to include additional information in the time-stamp token, if
         asked by the requester using the extensions field, only for the
         extensions that are supported by the TSA.  If this is not
         possible, the TSA SHALL respond with an error message.

It should say:

   8.    not to examine the imprint being time-stamped in any way (other
         than to check its length, as specified in the previous bullet).

   9.    to sign each time-stamp token using a key generated exclusively
         for this purpose and have this property of the key indicated on
         the corresponding certificate.

   10.   to include additional information in the time-stamp token, if
         asked by the requester using the extensions field, only for the
         extensions that are supported by the TSA.  If this is not
         possible, the TSA SHALL respond with an error message.

Notes:

There exists at least one legal mandate in at least one jurisdiction that contravenes strict compliance with RFC3161. It is easier to work to change IETF non-binding standards than it is to change legal mandates.

The State of Nevada regulates Time Stamps, under Nevada Administrative Code chapter 720 section 160. It requires that Time Stamps, to be recognized by its courts, must contain the identification of the requesting entity (the "identity of the person appending or attaching the notation") in the time-stamp tokens.

The Administrative Code may be found at this URL: http://www.leg.state.nv.us/NAC/NAC-720.html#NAC720Sec160 I have also quoted the relevant section below. (The parenthetical reference to NRS 720.150 is a reference to Nevada Revised Statutes, the statutory authority for the administrative code section.)

NAC 720.160 "Time stamp" defined. (NRS 720.150) "Time stamp" means:
1. A notation that:
(a) Is digitally signed by a certification authority;
(b) Is appended or attached to a message, digital signature or certificate; and
(c) Indicates at least:
(1) The date and time the notation was appended or attached; and
(2) The identity of the person appending or attaching the notation; or
2. To append or attach such a notation to a message, digital signature or certificate.
(Added to NAC by Sec'y of State by R155-98, eff. 12-2-99)

Please note that the requirement of NAC 720.160.1(c)(2) went into effect in December 1999, more than 18 months before RFC3161 was published in August 2001. The attempt by a non-legislative body (IETF pkix-wg) to contravene the will of a legislative body was either abject ignorance or utter hubris.

A TimeStampToken extension would be able to contain the mandatory data. However, such an extension would necessarily violate current RFC3161 section 2.1.9.

The reason for this change is actually technical (from a legal sense), though it may appear to be editorial in nature. As digests grow older, they necessarily have a much longer time that they have subject to the Birthday Attack. As of the date of this errata submission, SHA-1 is disallowed by the Computer Security Resource Center of US National Institute of Science and Technology (NIST) for new digital signature generation, due to potential weakening due to increased temporal attack surface.

This means that sooner or later, an older timestamp is going to be found that matches the digest of a newer document. The goal is to ensure that the document in question was actually in the possession of the particularly-named person identified as having attached the timestamp, by making that person available for testimony in the event of a dispute. If there are multiple timestamps available using different digest algorithms that all have the same time (within a few seconds of each other), that raises the probability that the document did in fact exist at that time. However, because new digest algorithms are introduced over time, it is not feasible to expect that all provided timestamps for a given document will necessarily be at the same time -- as long as all the digests that existed at the time the timestamps were generated have their times match, and the timestamps with new digests were not created before the new digests were implemented, it's the best evidence available that the timestamped data existed at the latest of the times of the timestamps from digests that existed simultaneously. (Be VERY careful about accepting timestamps that are more than thirty seconds apart from algorithms that existed simultaneously, and only in the murkiest situations should any set of timestamps using algorithms that existed simultaneously ever be accepted that are stamped as being more than two minutes apart.)

RFC3161 Section 2.4.1 defines a TimeStampReq format which does not provide the actual datum to be timestamped. Any attempt at a protocol which does make the Certification Authority be the one attaching the timestamp to the datum would have to provide the datum to the custody of the Certification Authority, which would exceed the scope of the protocol defined by RFC3161. Thus, a true RFC3161-compliant implementation would have to use nonstandard extensions to either the submission protocol (leaving the datum in the care of the Time Stamp Server) or the TimeStampReq and TimeStampToken contents (containing the datum in, presumably, an extension containing an ASN.1 OCTET STRING), in order to comply with this legal mandate in such a way that the identity of the person requesting the imprint (and thus presumed to hold the datum in the first place) does not need to be included within the TimeStampToken. Unfortunately, this would also necessitate a violation of RFC3161 section 2.1.8, to prevent false statements from being signed in a jurisdiction where digital signatures have the force of acknowledgments before notaries public.

The erratum submitter respectfully requests that a Time Stamp working group be reconvened for an update to the protocol to address this and other errata which are currently held for update.
--VERIFIER NOTES--

This is not an erratum but a change request. Please send to the pkix list if
it's still useful.

Report New Errata