As per Relevance of the word extension, we have this rfc below:
Network Working Group C.
Request for Comments: 3161
Category: Standards Track P.
D.
R.
August 2001
Internet X.509 Public Key
Time-Stamp Protocol (TSP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes the format of a request sent to a
Stamping Authority (TSA) and of the response that is returned.
also establishes several security-relevant requirements for
operation, with regards to processing requests to generate responses
1.
A time-stamping service supports assertions of proof that a
existed before a particular time. A TSA may be operated as a
Third Party (TTP) service, though other operational models may
appropriate, e.g., an organization might require a TSA for
time-stamping purposes
Non-repudiation services [ISONR] require the ability to establish
existence of data before specified times. This protocol may be
as a building block to support such services. An example of how
prove that a digital signature was generated during the
period of a public key certificate is given in an annex
Adams, et al. Standards Track [Page 1]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (
uppercase, as shown) are to be interpreted as described in [RFC2119].
In order to associate a datum with a particular point in time, a
Stamp Authority (TSA) may need to be used. This Trusted Third
provides a "proof-of-existence" for this particular datum at
instant in time
The TSA's role is to time-stamp a datum to establish
indicating that a datum existed before a particular time. This
then be used, for example, to verify that a digital signature
applied to a message before the corresponding certificate was
thus allowing a revoked public key certificate to be used
verifying signatures created prior to the time of revocation.
is an important public key infrastructure operation. The TSA
also be used to indicate the time of submission when a deadline
critical, or to indicate the time of transaction for entries in
log. An exhaustive list of possible uses of a TSA is beyond
scope of this document
This standard does not establish overall security requirements
TSA operation, just like other PKIX standards do not establish
requirements for CA operation. Rather, it is anticipated that a
will make known to prospective clients the policies it implements
ensure accurate time-stamp generation, and clients will make use
the services of a TSA only if they are satisfied that these
meet their needs
2. The
The TSA is a TTP that creates time-stamp tokens in order to
that a datum existed at a particular point in time
For the remainder of this document a "valid request" shall mean
that can be decoded correctly, is of the form specified in
2.4, and is from a supported TSA subscriber
2.1. Requirements of the
The TSA is REQUIRED
1. to use a trustworthy source of time
2. to include a trustworthy time value for each time-stamp token
3. to include a unique integer for each newly generated time-
token
Adams, et al. Standards Track [Page 2]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
4. to produce a time-stamp token upon receiving a valid
from the requester, when it is possible
5. to include within each time-stamp token an identifier
uniquely indicate the security policy under which the token
created
6. to only time-stamp a hash representation of the datum, i.e.,
data imprint associated with a one-way collision
hash-function uniquely identified by an OID
7. to examine the OID of the one-way collision resistant hash
function and to verify that the hash value length is
with the hash algorithm
8. not to examine the imprint being time-stamped in any way (
than to check its length, as specified in the previous bullet).
9. not to include any identification of the requesting entity
the time-stamp tokens
10. to sign each time-stamp token using a key generated
for this purpose and have this property of the key indicated
the corresponding certificate
11. to include additional information in the time-stamp token,
asked by the requester using the extensions field, only for
extensions that are supported by the TSA. If this is
possible, the TSA SHALL respond with an error message
2.2. TSA
As the first message of this mechanism, the requesting
requests a time-stamp token by sending a request (which is
includes a TimeStampReq, as defined below) to the Time
Authority. As the second message, the Time Stamping
responds by sending a response (which is or includes a TimeStampResp
as defined below) to the requesting entity
Upon receiving the response (which is or includes a
that normally contains a TimeStampToken (TST), as defined below),
requesting entity SHALL verify the status error returned in
response and if no error is present it SHALL verify the
fields contained in the TimeStampToken and the validity of
digital signature of the TimeStampToken. In particular, it
verify that what was time-stamped corresponds to what was
to be time-stamped. The requester SHALL verify that
TimeStampToken contains the correct certificate identifier of
Adams, et al. Standards Track [Page 3]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
TSA, the correct data imprint and the correct hash algorithm OID.
SHALL then verify the timeliness of the response by verifying
the time included in the response against a local trusted
reference, if one is available, or the value of the nonce (
random number with a high probability that it is generated by
client only once) included in the response against the value
in the request. For more details about replay attack detection,
the security considerations section (item 6). If any of
verifications above fails, the TimeStampToken SHALL be rejected
Then, since the TSA's certificate may have been revoked, the
of the certificate SHOULD be checked (e.g., by checking
appropriate CRL) to verify that the certificate is still valid
Then, the client application SHOULD check the policy field
determine whether or not the policy under which the token was
is acceptable for the application
2.3. Identification of the
The TSA MUST sign each time-stamp message with a key
specifically for that purpose. A TSA MAY have distinct private keys
e.g., to accommodate different policies, different algorithms
different private key sizes or to increase the performance.
corresponding certificate MUST contain only one instance of
extended key usage field extension as defined in [RFC2459]
4.2.1.13 with KeyPurposeID having value
id-kp-timeStamping. This extension MUST be critical
The following object identifier identifies the KeyPurposeID
value id-kp-timeStamping
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}
2.4. Request and Response
2.4.1. Request
A time-stamping request is as follows
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint
--a hash algorithm OID and the hash value of the data to
Adams, et al. Standards Track [Page 4]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
--time-
reqPolicy TSAPolicyId OPTIONAL
nonce INTEGER OPTIONAL
certReq BOOLEAN DEFAULT FALSE
extensions [0] IMPLICIT Extensions OPTIONAL }
The version field (currently v1) describes the version of the Time
Stamp request
The messageImprint field SHOULD contain the hash of the datum to
time-stamped. The hash is represented as an OCTET STRING.
length MUST match the length of the hash value for that
(e.g., 20 bytes for SHA-1 or 16 bytes for MD5).
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
hashedMessage OCTET STRING }
The hash algorithm indicated in the hashAlgorithm field SHOULD be
known hash algorithm (one-way and collision resistant). That
that it SHOULD be one-way and collision resistant. The Time
Authority SHOULD check whether or not the given hash algorithm
known to be "sufficient" (based on the current state of knowledge
cryptanalysis and the current state of the art in
resources, for example). If the TSA does not recognize the
algorithm or knows that the hash algorithm is weak (a decision
to the discretion of each individual TSA), then the TSA SHOULD
to provide the time-stamp token by returning a pkiStatusInfo
'bad_alg'.
The reqPolicy field, if included, indicates the TSA policy
which the TimeStampToken SHOULD be provided. TSAPolicyId is
as follows
TSAPolicyId ::= OBJECT
The nonce, if included, allows the client to verify the timeliness
the response when no local clock is available. The nonce is a
random number with a high probability that the client generates
only once (e.g., a 64 bit integer). In such a case the same
value MUST be included in the response, otherwise the response
be rejected
If the certReq field is present and set to true, the TSA's public
certificate that is referenced by the ESSCertID identifier inside
SigningCertificate attribute in the response MUST be provided by
TSA in the certificates field from the SignedData structure in
response. That field may also contain other certificates
Adams, et al. Standards Track [Page 5]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
If the certReq field is missing or if the certReq field is
and set to false then the certificates field from the
structure MUST not be present in the response
The extensions field is a generic way to add additional
to the request in the future. Extensions is defined in [RFC 2459].
If an extension, whether it is marked critical or not critical,
used by a requester but is not recognized by a time-stamping server
the server SHALL not issue a token and SHALL return a
(unacceptedExtension).
The time-stamp request does not identify the requester, as
information is not validated by the TSA (See Section 2.1).
situations where the TSA requires the identity of the
entity, alternate identification /authentication means have to
used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC2246]).
2.4.2. Response
A time-stamping response is as follows
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo
timeStampToken TimeStampToken OPTIONAL }
The status is based on the definition of status in section 3.2.3
of [RFC2510] as follows
PKIStatusInfo ::= SEQUENCE {
status PKIStatus
statusString PKIFreeText OPTIONAL
failInfo PKIFailureInfo OPTIONAL }
When the status contains the value zero or one, a TimeStampToken
be present. When status contains a value other than zero or one,
TimeStampToken MUST NOT be present. One of the following values
be contained in status
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken,
requested, is present
grantedWithMods (1),
-- when the PKIStatus contains the value one a TimeStampToken
with modifications, is present
rejection (2),
waiting (3),
revocationWarning (4),
Adams, et al. Standards Track [Page 6]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
-- this message contains a warning that a revocation
--
revocationNotification (5)
-- notification that a revocation has occurred }
Compliant servers SHOULD NOT produce any other values.
clients MUST generate an error if values it does not understand
present
When the TimeStampToken is not present, the failInfo indicates
reason why the time-stamp request was rejected and may be one of
following values
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm
badRequest (2),
-- transaction not permitted or
badDataFormat (5),
-- the data submitted has the wrong
timeNotAvailable (14),
-- the TSA's time source is not
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the
unacceptedExtension (16),
-- the requested extension is not supported by the
addInfoNotAvailable (17)
-- the additional information requested could not be
-- or is not
systemFailure (25)
-- the request cannot be handled due to system failure }
These are the only values of PKIFailureInfo that SHALL be supported
Compliant servers SHOULD NOT produce any other values.
clients MUST generate an error if values it does not understand
present
The statusString field of PKIStatusInfo MAY be used to include
text such as "messageImprint field is not correctly formatted".
A TimeStampToken is as follows. It is defined as a
([CMS]) and SHALL encapsulate a signed data content type
TimeStampToken ::=
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])
Adams, et al. Standards Track [Page 7]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
The fields of type EncapsulatedContentInfo of the
construct have the following meanings
eContentType is an object identifier that uniquely specifies
content type. For a time-stamp token it is defined as
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
eContent is the content itself, carried as an octet string
The eContent SHALL be the DER-encoded value of TSTInfo
The time-stamp token MUST NOT contain any signatures other than
signature of the TSA. The certificate identifier (ESSCertID) of
TSA certificate MUST be included as a signerInfo attribute inside
SigningCertificate attribute
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId
messageImprint MessageImprint
-- MUST have the same value as the similar field
--
serialNumber INTEGER
-- Time-Stamping users MUST be ready to accommodate
-- up to 160 bits
genTime GeneralizedTime
accuracy Accuracy OPTIONAL
ordering BOOLEAN DEFAULT FALSE
nonce INTEGER OPTIONAL
-- MUST be present if the similar field was
-- in TimeStampReq. In that case it MUST have the same value
tsa [0] GeneralName OPTIONAL
extensions [1] IMPLICIT Extensions OPTIONAL }
The version field (currently v1) describes the version of the time
stamp token
Conforming time-stamping servers MUST be able to provide version 1
time-stamp tokens
Among the optional fields, only the nonce field MUST be supported
Conforming time-stamping requesters MUST be able to recognize
1 time-stamp tokens with all the optional fields present, but are
mandated to understand the semantics of any extension, if present
Adams, et al. Standards Track [Page 8]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
The policy field MUST indicate the TSA's policy under which
response was produced. If a similar field was present in
TimeStampReq, then it MUST have the same value, otherwise an
(unacceptedPolicy) MUST be returned. This policy MAY include
following types of information (although this list is certainly
exhaustive):
* The conditions under which the time-stamp token may be used
* The availability of a time-stamp token log, to allow
verification that a time-stamp token is authentic
The messageImprint MUST have the same value as the similar field
TimeStampReq, provided that the size of the hash value matches
expected size of the hash algorithm identified in hashAlgorithm
The serialNumber field is an integer assigned by the TSA to
TimeStampToken. It MUST be unique for each TimeStampToken issued
a given TSA (i.e., the TSA name and serial number identify a
TimeStampToken). It should be noticed that the property MUST
preserved even after a possible interruption (e.g., crash) of
service
genTime is the time at which the time-stamp token has been created
the TSA. It is expressed as UTC time (Coordinated Universal Time)
reduce confusion with the local time zone use. UTC is a time scale
based on the second (SI), as defined and recommended by the CCIR,
maintained by the Bureau International des Poids et Mesures (BIPM).
synonym is "Zulu" time which is used by the civil aviation
represented by the letter "Z" (phonetically "Zulu").
The ASN.1 GeneralizedTime syntax can include fraction-of-
details. Such syntax, without the restrictions from [RFC 2459]
Section 4.1.2.5.2, where GeneralizedTime is limited to represent
time with a granularity of one second, may be used here
GeneralizedTime values MUST include seconds. However, when there
no need to have a precision better than the second,
GeneralizedTime with a precision limited to one second SHOULD be
(as in [RFC 2459]).
The syntax is: YYYYMMDDhhmmss[.s...]
Example: 19990609001326.34352
X.690 | ISO/IEC 8825-1 provides the following restrictions for
DER-encoding
Adams, et al. Standards Track [Page 9]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
The encoding MUST terminate with a "Z" (which means "Zulu" time).
decimal point element, if present, MUST be the point option ".".
fractional-seconds elements, if present, MUST omit all trailing 0's
if the elements correspond to 0, they MUST be wholly omitted, and
decimal point element also MUST be omitted
Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z
where "YYYYMMDD" represents the day following the midnight
question
Here are a few examples of valid representations
"19920521000000Z
"19920622123421Z
"19920722132100.3Z
accuracy represents the time deviation around the UTC time
in GeneralizedTime
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL
millis [0] INTEGER (1..999) OPTIONAL
micros [1] INTEGER (1..999) OPTIONAL }
If either seconds, millis or micros is missing, then a value of
MUST be taken for the missing field
By adding the accuracy value to the GeneralizedTime, an upper
of the time at which the time-stamp token has been created by the
can be obtained. In the same way, by subtracting the accuracy to
GeneralizedTime, a lower limit of the time at which the time-
token has been created by the TSA can be obtained
accuracy can be decomposed in seconds, milliseconds (between 1-999)
and microseconds (1-999), all expressed as integer
When the accuracy optional field is not present, then the
may be available through other means, e.g., the TSAPolicyId
If the ordering field is missing, or if the ordering field is
and set to false, then the genTime field only indicates the time
which the time-stamp token has been created by the TSA. In such
case, the ordering of time-stamp tokens issued by the same TSA
different TSAs is only possible when the difference between
genTime of the first time-stamp token and the genTime of the
time-stamp token is greater than the sum of the accuracies of
genTime for each time-stamp token
Adams, et al. Standards Track [Page 10]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
If the ordering field is present and set to true, every time-
token from the same TSA can always be ordered based on the
field, regardless of the genTime accuracy
The nonce field MUST be present if it was present in
TimeStampReq. In such a case it MUST equal the value provided in
TimeStampReq structure
The purpose of the tsa field is to give a hint in identifying
name of the TSA. If present, it MUST correspond to one of
subject names included in the certificate that is to be used
verify the token. However, the actual identification of the
that signed the response will always occur through the use of
certificate identifier (ESSCertID Attribute) inside
SigningCertificate attribute which is part of the signerInfo (
Section 5 of [ESS]).
extensions is a generic way to add additional information in
future. Extensions is defined in [RFC 2459].
Particular extension field types may be specified in standards or
be defined and registered by any organization or community
3.
There is no mandatory transport mechanism for TSA messages in
document. The mechanisms described below are optional;
optional mechanisms may be defined in the future
3.1. Time-Stamp Protocol Using E-
This section specifies a means for conveying ASN.1-encoded
for the protocol exchanges described in Section 2 and Appendix D
Internet mail
Two MIME objects are specified as follows
Content-Type: application/timestamp-
Content-Transfer-Encoding: base64
<>
Content-Type: application/timestamp-
Content-Transfer-Encoding: base64
<>
These MIME objects can be respectively sent and received using
MIME processing engines and provides a simple Internet mail
for Time-Stamp messages
Adams, et al. Standards Track [Page 11]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
For the application/timestamp-query and application/timestamp-
MIME types, implementations SHOULD include the optional "name"
"filename" parameters. Including a file name helps preserve
information when time-stamp queries and replies are saved as files
When these parameters are included, a file name with the
extension SHOULD be selected
MIME Type File
application/timestamp-query .
application/timestamp-reply .
In addition, the file name SHOULD be limited to eight
followed by a three letter extension. The eight character
base can be any distinct name
3.2. File Based
A file containing a time-stamp message MUST contain only the
encoding of one TSA message, i.e., there MUST be no extraneous
or trailer information in the file. Such files can be used
transport time stamp messages using for example, FTP
A Time-Stamp Request SHOULD be contained in a file with
extension .tsq (like Time-Stamp Query). A Time-Stamp
SHOULD be contained in a file with file extension .tsr (
Time-Stamp Reply).
3.3. Socket Based
The following simple TCP-based protocol is to be used for
of TSA messages. This protocol is suitable for cases where an
initiates a transaction and can poll to pick up the results
The protocol basically assumes a listener process on a TSA that
accept TSA messages on a well-defined port (IP port number 318).
Typically an initiator binds to this port and submits the initial
message. The responder replies with a TSA message and/or with
reference number to be used later when polling for the actual
message response
If a number of TSA response messages are to be produced for a
request (say if a receipt must be sent before the actual token can
produced) then a new polling reference is also returned
When the final TSA response message has been picked up by
initiator then no new polling reference is supplied
Adams, et al. Standards Track [Page 12]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
The initiator of a transaction sends a "direct TCP-based TSA message
to the recipient. The recipient responds with a similar message
A "direct TCP-based TSA message" consists of
length (32-bits), flag (8-bits), value (defined below
The length field contains the number of octets of the remainder
the message (i.e., number of octets of "value" plus one). All 32-
values in this protocol are specified to be in network byte order
Message name flag
tsaMsg '00'H DER-encoded TSA
-- TSA
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits
-- poll response where no TSA message response ready; use
-- reference value (and estimated time value) for later
pollReq '02'H polling reference (32 bits
-- request for a TSA message response to initial
negPollRep '03'H '00'
-- no further polling responses (i.e., transaction complete
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded TSA
-- partial response (receipt) to initial message plus new
-- reference (and estimated time value) to use to get next part
--
finalMsgRep '05'H DER-encoded TSA
-- final (and possibly sole) response to initial
errorMsgRep '06'H human readable error
-- produced when an error is detected (e.g., a polling
-- is received which doesn't exist or is finished with
The sequence of messages that can occur is
a) entity sends tsaMsg and receives one of pollRep, negPollRep
partialMsgRep, or finalMsgRep in response
b) end entity sends pollReq message and receives one
negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep
response
The "time-to-check-back" parameter is an unsigned 32-bit integer.
is the time in seconds indicating the minimum interval after
the client SHOULD check the status again
It provides an estimate of the time that the end entity should
its next pollReq
Adams, et al. Standards Track [Page 13]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
3.4. Time-Stamp Protocol via
This subsection specifies a means for conveying ASN.1-
messages for the protocol exchanges described in Section 2
Appendix D via the HyperText Transfer Protocol
Two MIME objects are specified as follows
Content-Type: application/timestamp-
<>
Content-Type: application/timestamp-
<Response message>>
These MIME objects can be sent and received using common
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
valid response with content type application/timestamp-response
with an HTTP error
4. Security
This entire document concerns security considerations.
designing a TSA service, the following considerations have
identified that have an impact upon the validity or "trust" in
time-stamp token
1. When a TSA shall not be used anymore, but the TSA private key
not been compromised, the authority's certificate SHALL
revoked. When the reasonCode extension relative to the
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
future time, the tokens signed with the corresponding key will
considered as invalid, but tokens generated before the
time will remain valid. When the reasonCode extension relative
the revoked certificate from the TSA is not present in the
entry extensions, then all the tokens that have been signed
the corresponding key SHALL be considered as invalid. For
reason, it is recommended to use the reasonCode extension
Adams, et al. Standards Track [Page 14]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
2. When the TSA private key has been compromised, then
corresponding certificate SHALL be revoked. In that case,
reasonCode extension relative to the revoked certificate from
TSA may or may not be present in the CRL entry extensions.
it is present then it SHALL be set to keyCompromise (1).
token signed by the TSA using that private key cannot be
anymore. For this reason, it is imperative that the TSA's
key be guarded with proper security and controls in order
minimize the possibility of compromise. In case the private
does become compromised, an audit trail of all tokens generated
the TSA MAY provide a means to discriminate between genuine
false backdated tokens. Two time-stamp tokens from two
TSAs is another way to address this issue
3. The TSA signing key MUST be of a sufficient length to allow for
sufficiently long lifetime. Even if this is done, the key
have a finite lifetime. Thus, any token signed by the TSA
be time-stamped again (if authentic copies of old CRLs
available) or notarized (if they aren't) at a later date to
the trust that exists in the TSA's signature. time-stamp
could also be kept with an Evidence Recording Authority
maintain this trust
4. A client application using only a nonce and no local clock
be concerned about the amount of time it is willing to wait for
response. A `man-in-the-middle' attack can introduce delays
Thus, any TimeStampResp that takes more than an acceptable
of time SHOULD be considered suspect. Since each transport
specified in this document has different delay characteristics
the period of time that is considered acceptable will depend
the particular transport method used, as well as other
factors
5. If different entities obtain time-stamp tokens on the same
object using the same hash algorithm, or a single entity
multiple time-stamp tokens on the same object, the
time-stamp tokens will include identical message imprints; as
result, an observer with access to those time-stamp tokens
infer that the time-stamps may refer to the same underlying data
Adams, et al. Standards Track [Page 15]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
6. Inadvertent or deliberate replays for requests incorporating
same hash algorithm and value may happen. Inadvertent
occur when more than one copy of the same request message
sent to the TSA because of problems in the intervening
elements. Deliberate replays occur when a middleman is
legitimate TS responses. In order to detect these situations
several techniques may be used. Using a nonce always allows
detect replays, and hence its use is RECOMMENDED.
possibility is to use both a local clock and a moving time
during which the requester remembers all the hashes sent
that time window. When receiving a response, the
ensures both that the time of the response is within the
window and that there is only one occurrence of the hash value
that time window. If the same hash value is present more
once within a time window, the requester may either use a nonce
or wait until the time window has moved to come back to the
where the same hash value appears only once during that
window
5. Intellectual Property
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed to per
tain to the implementation or use of the technology described in
document or the extent to which any license under such rights
or might not be available; neither does it represent that it has
any effort to identify any such rights. Information on the IETF'
procedures with respect to rights in standards-track and standards
related documentation can be found in BCP-11. Copies of claims
rights made available for publication and any assurances of
to be made available, or the result of an attempt made to obtain
general license or permission for the use of such proprietary
by implementors or users of this specification can be obtained
the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
The following eight (8) United States Patents related to
stamping, listed in chronological order, are known by the authors
exist at this time. This may not be an exhaustive list.
patents MAY exist or be issued at any time. This list is
for informational purposes; to date, the IETF has not been
of intellectual property rights claimed in regard to any of
Adams, et al. Standards Track [Page 16]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
specification contained in this document. Should this
change, the current status may be found at the online list of
rights (IETF Page of Intellectual Property Rights Notices).
Implementers of this protocol SHOULD perform their own patent
and determine whether or not any encumbrances exist on
implementation
Users of this protocol SHOULD perform their own patent search
determine whether or not any encumbrances exist on the use of
standard
# 5,001,752 Public/Key Date-Time Notary
Filing date: October 13, 1989
Issued: March 19, 1991
Inventor: Addison M.
# 5,022,080 Electronic
Filing date: April 16, 1989
Issued: June 4, 1991
Inventors: Robert T. Durst, Kevin D.
# 5,136,643 Public/Key Date-Time Notary
Filing date: December 20, 1990
Issued: August 4, 1992
Inventor: Addison M.
Note: This is a continuation of patent # 5,001,752.)
# 5,136,646 Digital Document Time-Stamping with Catenate
Filing date: August 2, 1990
Issued: August 4, 1992
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr
(assignee) Bell Communications Research, Inc.,
# 5,136,647 Method for Secure Time-Stamping of Digital
Filing date: August 2, 1990
Issued: August 4, 1992
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr
(assignee) Bell Communications Research, Inc.,
# 5,373,561 Method of Extending the Validity of a
Filing date: December 21, 1992
Issued: December 13, 1994
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr
(assignee) Bell Communications Research, Inc.,
Adams, et al. Standards Track [Page 17]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
# 5,422,953 Personal Date/Time Notary
Filing date: May 5, 1993
Issued: June 6, 1995
Inventor: Addison M.
# 5,781,629 Digital Document Authentication
Filing date: February 21, 1997
Issued: July 14, 1998
Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr
(assignee) Surety Technologies, Inc.,
6.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
RFC 2246, January 1999.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public
Infrastructure, Certificate Management Protocols",
2510, March 1999.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "
X.509 Public Key Infrastructure, Certificate and
Profile", RFC 2459, January 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[DSS] Digital Signature Standard. FIPS Pub 186.
Institute of Standards and Technology. 19 May 1994.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
2634, June 1999.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems
Non-Repudiation Framework. April 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National
of Standards and Technology. 17 April 1995.
Adams, et al. Standards Track [Page 18]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
7. Authors'
Carlisle
Entrust, Inc
1000 Innovation
Ottawa,
K2K 3E
EMail: cadams@entrust.
Pat
70 Fawcett
Cambridge, MA 02138
U.S.A
EMail: pcain@bbn.
Denis
68 route de
B.P. 434
78430
EMail: Denis.Pinkas@bull.
Robert
Entrust, Inc
1000 Innovation
Ottawa,
K2K 3E
EMail: robert.zuccherato@entrust.
Adams, et al. Standards Track [Page 19]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
APPENDIX A - Signature Time-stamp attribute using
One of the major uses of time-stamping is to time-stamp a
signature to prove that the digital signature was created before
given time. Should the corresponding public key certificate
revoked this allows a verifier to know whether the signature
created before or after the revocation date
A sensible place to store a time-stamp is in a [CMS] structure as
unsigned attribute
This appendix defines a Signature Time-stamp attribute that may
used to time-stamp a digital signature
The following object identifier identifies the Signature Time-
attribute
id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
The Signature time-stamp attribute value has ASN.1
SignatureTimeStampToken
SignatureTimeStampToken ::=
The value of messageImprint field within TimeStampToken shall be
hash of the value of signature field within SignerInfo for
signedData being time-stamped
APPENDIX B - Placing a Signature At a Particular Point in
We present an example of a possible use of this general time-
service. It places a signature at a particular point in time,
which the appropriate certificate status information (e.g., CRLs
MUST be checked. This application is intended to be used
conjunction with evidence generated using a digital
mechanism
Signatures can only be verified according to a non-
policy. This policy MAY be implicit or explicit (i.e., indicated
the evidence provided by the signer). The non-repudiation policy
specify, among other things, the time period allowed by a signer
declare the compromise of a signature key used for the generation
digital signatures. Thus a signature may not be guaranteed to
valid until the termination of this time period
To verify a digital signature, the following basic technique may
used
Adams, et al. Standards Track [Page 20]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
A) Time-stamping information needs to be obtained soon after
signature has been produced (e.g., within a few minutes or hours).
1) The signature is presented to the Time Stamping
(TSA). The TSA then returns a TimeStampToken (TST)
that signature
2) The invoker of the service MUST then verify that
TimeStampToken is correct
B) The validity of the digital signature may then be verified in
following way
1) The time-stamp token itself MUST be verified and it MUST
verified that it applies to the signature of the signer
2) The date/time indicated by the TSA in the
MUST be retrieved
3) The certificate used by the signer MUST be identified
retrieved
4) The date/time indicated by the TSA MUST be within
validity period of the signer's certificate
5) The revocation information about that certificate, at
date/time of the Time-Stamping operation, MUST be retrieved
6) Should the certificate be revoked, then the date/time
revocation shall be later than the date/time indicated
the TSA
If all these conditions are successful, then the digital
shall be declared as valid
APPENDIX C: ASN.1 Module using 1988
PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
DEFINITIONS IMPLICIT TAGS ::=
-- EXPORTS ALL --
Adams, et al. Standards Track [Page 21]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
Extensions,
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
GeneralName FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
ContentInfo FROM CryptographicMessageSyntax {iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1)}
PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmp(9)} ;
-- Locally defined OIDs --
-- eContentType for a time-stamp
id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
-- 2.4.1
TimeStampReq ::= SEQUENCE {
version INTEGER { v1(1) },
messageImprint MessageImprint
--a hash algorithm OID and the hash value of the data to
--time-
reqPolicy TSAPolicyId OPTIONAL
nonce INTEGER OPTIONAL
certReq BOOLEAN DEFAULT FALSE
extensions [0] IMPLICIT Extensions OPTIONAL }
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
hashedMessage OCTET STRING }
TSAPolicyId ::= OBJECT
-- 2.4.2
TimeStampResp ::= SEQUENCE {
status PKIStatusInfo
timeStampToken TimeStampToken OPTIONAL }
Adams, et al. Standards Track [Page 22]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
-- The status is based on the definition of
-- in section 3.2.3 of [RFC2510]
PKIStatusInfo ::= SEQUENCE {
status PKIStatus
statusString PKIFreeText OPTIONAL
failInfo PKIFailureInfo OPTIONAL }
PKIStatus ::= INTEGER {
granted (0),
-- when the PKIStatus contains the value zero a TimeStampToken,
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
--
revocationNotification (5)
-- notification that a revocation has occurred }
-- When the TimeStampToken is not
-- failInfo indicates the reason why
-- time-stamp request was rejected
-- may be one of the following values
PKIFailureInfo ::= BIT STRING {
badAlg (0),
-- unrecognized or unsupported Algorithm
badRequest (2),
-- transaction not permitted or
badDataFormat (5),
-- the data submitted has the wrong
timeNotAvailable (14),
-- the TSA's time source is not
unacceptedPolicy (15),
-- the requested TSA policy is not supported by the TSA
unacceptedExtension (16),
-- the requested extension is not supported by the TSA
addInfoNotAvailable (17)
-- the additional information requested could not be
-- or is not
systemFailure (25)
-- the request cannot be handled due to system failure }
TimeStampToken ::=
Adams, et al. Standards Track [Page 23]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
-- contentType is id-signedData as defined in [CMS
-- content is SignedData as defined in([CMS])
-- eContentType within SignedData is id-ct-
-- eContent within SignedData is
TSTInfo ::= SEQUENCE {
version INTEGER { v1(1) },
policy TSAPolicyId
messageImprint MessageImprint
-- MUST have the same value as the similar field
--
serialNumber INTEGER
-- Time-Stamping users MUST be ready to accommodate
-- up to 160 bits
genTime GeneralizedTime
accuracy Accuracy OPTIONAL
ordering BOOLEAN DEFAULT FALSE
nonce INTEGER OPTIONAL
-- MUST be present if the similar field was
-- in TimeStampReq. In that case it MUST have the same value
tsa [0] GeneralName OPTIONAL
extensions [1] IMPLICIT Extensions OPTIONAL }
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL
millis [0] INTEGER (1..999) OPTIONAL
micros [1] INTEGER (1..999) OPTIONAL }
APPENDIX D: Access descriptors for Time-Stamping
[This annex describes an extension based on the SIA extension
will be defined in the "son-of-RFC2459". Since at the time
publication of this document, "son-of-RFC2459" is not yet available
its description is placed in an informative annex. The contents
this annex will eventually become incorporated into the son-of
RFC2459 document, at which time this annex will no longer be needed
A future version of this document will likely omit this annex
refer to son-of-RFC2459 directly.]
A TSA's certificate MAY contain a Subject Information Access (SIA
extension (son of RFC2459) in order to convey the method
contacting the TSA. The accessMethod field in this extension
contain the OID id-ad-timestamping
The following object identifier identifies the access descriptors
time-Stamping
Adams, et al. Standards Track [Page 24]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
ad (48) timestamping (3)}
The value of the accessLocation field defines the transport (e.g.,
HTTP) used to access the TSA and may contain other
dependent information (e.g., a URL).
Adams, et al. Standards Track [Page 25]
RFC 3161 Time-Stamp Protocol (TSP) August 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Adams, et al. Standards Track [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
