RFC Errata
Found 5 records.
Status: Verified (3)
RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001
Note: This RFC has been updated by RFC 5816
Source of RFC: pkix (sec)
Errata ID: 1879
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Pope
Date Reported: 2009-09-15
Verifier Name: Tim Polk
Date Verified: 2010-04-19
Section 3.6 says:
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.
It should say:
Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-reply or with an HTTP error.
Notes:
"application/timestamp-reply" are used in the rest parts of RFC 3161 (4 occurencies). Furthermore, known existing implementations are using
"application/timestamp-reply".
Errata ID: 2931
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12
Section 2.4.2 says:
PKIStatus ::= INTEGER { granted (0), -- when the PKIStatus contains the value zero a TimeStampToken, as requested, is present. grantedWithMods (1), -- when the PKIStatus contains the value one a TimeStampToken, with modifications, is present. rejection (2), waiting (3), revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred }
It should say:
PKIStatus ::= INTEGER { granted (0), -- when the PKIStatus contains the value zero a TimeStampToken, as -- requested, is present. grantedWithMods (1), -- when the PKIStatus contains the value one a TimeStampToken, -- with modifications, is present. rejection (2), waiting (3), revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred -- }
Notes:
In ASN.1 syntax 1988, all comment lines must be prefixed with double-hyphen, and comment lines followed by some content must be terminated with a double-hyphen.
Errata ID: 2932
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benjamin Dauvergne
Date Reported: 2011-08-12
Verifier Name: Sean Turner
Date Verified: 2011-11-12
Section 2.4.2 says:
systemFailure (25) -- the request cannot be handled due to system failure }
It should say:
systemFailure (25) -- the request cannot be handled due to system failure -- }
Notes:
In ASN.1 syntax 1988, comment lines followed by content must be terminated by a double-hyphen.
Status: Held for Document Update (1)
RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001
Note: This RFC has been updated by RFC 5816
Source of RFC: pkix (sec)
Errata ID: 844
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stefan Doerpinghaus
Date Reported: 2007-01-31
Held for Document Update by: Tim Polk
Section 2.4.2 says:
unacceptedExtension (16), -- the requested extension is not supported by the TSA addInfoNotAvailable (17) -- the additional information requested could not be understood -- or is not available systemFailure (25) -- the request cannot be handled due to system failure }
It should say:
unacceptedExtension (16), -- the requested extension is not supported by the TSA addInfoNotAvailable (17), -- the additional information requested could not be understood -- or is not available systemFailure (25) -- the request cannot be handled due to system failure }
Notes:
Missing comma after the descriptor of the OID of PKIFailureInfo,
at the end of line "addInfoNotAvailable (17).
from pending
Status: Rejected (1)
RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", August 2001
Note: This RFC has been updated by RFC 5816
Source of RFC: pkix (sec)
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.