view Side-By-Side changes
Time Stamp Protocols
<draft-adams-time-stamp-00.txt>
<draft-adams-time-stamp-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token. We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.
1. Introduction
In order to associate a message with a particular point in time, a
Time Stamp Authority (TSA) may need to be used. This Trusted Third
Party provides a "proof-of-existence" for this particular message at an
instant in time. A TSA may also be used when a trusted time reference
is required and when the local clock available cannot be trusted by all
parties. The TSA's role is to time stamp a message to establish
evidence indicating the time before which the message was generated.
This can then be used, for example, to verify that a digital signature
was applied before the certificate was revoked thus allowing a revoked
public key certificate to be used for verifying signatures created prior
to the time of revocation. This is an important public key
Document Expiration: May 7, September 12, 1998 Page 1
infrastructure operation. The TSA can also be used to indicate the time
of submission when a deadline is critical, or to indicate the time of
transaction for entries in a log. An exhaustive list of possible uses
of a TSA is beyond the scope of this document.
2. The TSA
The TSA is a TTP that creates time stamp tokens in order to indicate
that a message existed at a particular point in time.
For the remainder of this document a 'valid request' shall mean one that
can be decoded correctly, is of the form specified in Section 2.4 and
contains the correct TSA name.
2.1. Requirements of the TSA
The TSA is required to: required:
1. verify to only the provide a trusted source of time. The TSA does
2. not to examine or verify the
data requesting entities in any way.
3. not to examine the imprint being time stamped or the requesting entities in any way.
2.
4. to include a monotonically incrementing value of the time of day
into its time stamp token.
3.
5. to produce a time stamp token upon receiving a valid request
from the requester.
4.
6. to include within each time stamp token an identifier to
uniquely determine indicate the trust and validation policy used for this
signature.
5. under which
the token was created.
7. to only time stamp a hash representation of the message.
6. message, i.e. a
data imprint associated with a one-way collision resistant hash-
function OID.
8. to examine the OID of the one-way collision resistant hash-
function and to verify that this function is "sufficient" (see
Section 2.4).
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.
7.
10. to include supplementary temporal information in the time stamp
token (from TDA's) if asked by the requester.
8. If this is not
possible, the TSA shall respond with an error message.
11. to provide a signed receipt (i.e. in the form of an
appropriately defined time stamp token) to the requester, where
appropriate, as defined by policy.
2.2. TSA Transactions
As the first message of this mechanism, the requesting entity requests a
time stamping service stamp token by sending a request (which is or includes a
TimeStampReq, as defined below) to the Time Stamping Authority. As the
second message, the Time Stamping Authority responds by sending a
response (which is or includes a TimeStampToken, as defined below) to
the requesting entity.
Upon receiving the token, the requesting entity verifies its validity
by verifying the digital signature in the TimeStampToken and by
verifying that what was time stamped corresponds to what was requested
to be time stamped. The requester should verify that the TimeStampToken
Document Expiration: September 12, 1998 Page 2
contains the correct time, the correct TSA name, the correct data imprint and the correct
hash algorithm OID. It should then verify the timeliness of the
response by verifying either the time included in the response against a
local trusted time reference, if one is available, and/or the value of
the nonce included in the response against the value included in the
request. Since the TSA's certificate may have been revoked, the status
of the certificate should be checked (e.g. by checking the appropriate
ARL) to verify that the certificate is still valid. If
TemporalDataToken's are included in the TimeStampToken, then these
should also be verified as was the TimeStampToken. TimeStampToken (see Appendix C). The
token can now be used to establish a trusted time reference.
Document Expiration: May 7, 1998 Page 2
2.3. Identification of the TSA
The TSA must sign all time stamp messages with a key reserved
specifically for that purpose. The corresponding certificate must
contain the extended key usage field extension as defined in [PKIX1] [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-timeStamping.
This extension must be critical.
2.4. Request and Token Formats
A time stamping request is as follows.
TimeStampReq ::= SEQUENCE {
version Integer { v1(0) },
requester [0] GeneralName OPTIONAL,
reqPolicy [1] PolicyInformation OPTIONAL,
tsa [2] GeneralName,
tdas SEQUENCE OF GeneralName, GeneralName OPTIONAL,
nonce Integer,
messageImprint MessageImprint
--a hash algorithm OID and the hash value of the data to be time
--time stamped
}
The requester field, if included indicates the name of the requester.
This value is not verified by the TSA, but blindly copied in the
response and may be also copied in the audit trail.
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 [PKIX1]. [CCP].
The tsa field identifies the name of the TSA. GeneralName is defined
in Section 4.2.1.7 of [PKIX1]. [CCP].
The tdas field identifies those TDAs which are requested to provide
supplementary temporal evidence in the time stamp token. (See Appendix
C.)
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }
Document Expiration: September 12, 1998 Page 3
The hash algorithm indicated in the hashAlgorithm field must be a strong
hash algorithm. That means that it must be one-way and collision
resistant. It is up to the Time Stamp Authority to decide whether or
not the given hash algorithm is "sufficient" (based on the current state
of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).
The hashedMessage field should contain the hash of the message to be
time stamped. The hash is represented as an OCTET STRING.
A time stamp token TimeStampToken is as follows. It is encapsulated as a SignedData
construct [CMS]. The signature content is computed over
tstInfo (encoded using of type TSTInfo, which is indicated by
the ASN.1 distinguished encoding rules (DER)).
TimeStampToken OID:
TSTInfo OBJECT IDENTIFIER ::= SEQUENCE {
tstInfo TSTInfo, ?????? }
The time stamp token must contain only the signature BIT STRING,
--over of the ASN.1 DER encoding TSA. In
some environments, the CA might not perform a proof-of-possession of tstInfo
}
Document Expiration: May 7, 1998 Page 3
the private key when issuing certificates. In these instances, either
the certificate of the TSA, or the certificate issuer and serial number
shall be included as an authenticated attribute.
TSTInfo ::= SEQUENCE {
version Integer { v1(0) },
policy PolicyInformation OPTIONAL, PolicyInformation,
status PKIStatusInfo,
requester [0] GeneralName OPTIONAL,
--must be present if the requester field is present in
--TimeStampReq, and must be identical to that field
tsa [1] GeneralName,
signatureAlgorithm AlgorithmIdentifier,
certId CertId,
--must refer to the TSA's public verification certificate
certs SEQUENCE OF Certificate OPTIONAL,
--additional certificates that may be needed by end entities
--to verify the TimeStampToken
genTime GeneralizedTime,
tdaTokens SEQUENCE OF TemporalDataToken, TemporalDataToken
OPTIONAL,
nonce Integer,
--this field must have the same value as the similar field
--in TimeStampReq
messageImprint MessageImprint
--this field must have the same value as the similar field
--in TimeStampReq
}
PKIStatusInfo is defined in Section 3.2.3 of [PKIX3]. [CMP]. If the PKIStatus
field has value 'waiting' (3), then this token is a receipt, as defined
in Section 2.1. Otherwise, the status field is present to indicate
whether or not the time stamping request was fulfilled and, if not, the
reason it was rejected. A valid time stamp token will always have value
0 (granted) in the PKIStatus field of PKIStatusInfo. Since not all
environments will require the use of receipts, support for the value
'waiting' is optional.
The purpose of the tsa field is to identify the name of the TSA. It
must correspond to one of the subject names included in the certificate
that is to be used to verify the token.
Document Expiration: September 12, 1998 Page 4
TemporalDataToken is defined in Section 3 Appendix C of this document. The
tdaTokens field contains the supplementary evidence requested in the
TimeStampReq.
CertId is defined in Section 3.2.4 of [PKIX3]. [CMP].
3. The TDA
The Temporal Data Authority Transports
There is a TTP that creates a temporal data
token. This temporal data token associates a message with a particular
event and provides supplementary evidence for the time included no mandatory transport mechanism in the this document. All
mechanisms are optional.
3.1. File Based Protocol
A file containing a time stamp token. For example, a TDA could associate the message with must contain only the most recent closing value DER
encoding of the Dow Jones Average. The temporal
data with which the message is associated should one PKI message, i.e. there must be unpredictable no extraneous header or
trailer information in
order the file.
Such files can be used to prevent forward dating of tokens. Authentic values of transport time stamp messages using for
example, FTP.
3.2. Socket Based Protocol
The socket based protocol for time stamp messages is identical to that
used in [CMP] Section 5.2 except that port 309 must be used.
3.3. Time Stamp Protocol Using E-mail
This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via
Internet mail.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
This MIME object can be sent and received using common MIME processing
engines and provides a simple Internet mail transport for Time Stamp
messages.
3.4. Time Stamp Protocol via HTTP
This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via the
HyperText Transfer Protocol.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
<<the ASN.1 DER-encoded Time Stamp message>>
Document Expiration: September 12, 1998 Page 5
This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Time Stamp messages.
4. Security Considerations
This entire document concerns security considerations.
When designing a TSA/TDA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the time
stamp token.
1. When there is a reason to believe that the TSA can no longer
be trusted, the authority's certificate must be revoked and
placed on the appropriate ARL. Thus, at any future time the
tokens signed with the corresponding key will not be valid.
2. The TSA private key is compromised and the corresponding
certificate is revoked. In this case, any token signed by the
TSA using that private key cannot be trusted. 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 tokens.
3. The TSA signing key must be of a sufficient length to allow
for a sufficiently long lifetime. Even if this
data is done, the key
will have a finite lifetime. Thus, any token signed by the
TSA should be time stamped again (if authentic copies of old
CRLs are available) or notarized (if they aren't) at a later
date to renew the trust that exists in the TSA's signature.
Time stamp tokens could also be available from kept with an Evidence Recording
Authority to maintain this trust.
4. Since the TSA does not verify message data or the identity of
the entities, the requester field in TimeStampReq and
TimeStampToken should be considered untrusted. If
authentication of this field is needed, it is recommended that
the Notary Authority be used, as described in [NOTARY].
5. An application using the TSA service should be concerned about
the amount of time it is willing to wait for a response. A
`man-in-the-middle' attack can introduce delays. Thus, any
TimeStampToken that takes more than an acceptable period of time
should be considered suspect.
6. In certain circumstances, a TSA may not be able to
produce a valid response to a request (for example, if it is
unable to compute signatures for a period of time). In these
situations the TSA must wait until it is again able to produce a
valid response before responding, if this is possible. If this
is not possible, it must ignore the requests and not respond.
Under no circumstances shall a large number of trustworthy sources
in order TSA produce an unsigned response
to make collusion or corruption of data impossible. For a list request.
7. This protocol assumes that the CA has conducted a test for proof
of possible types possession for each user's signing private key (including
the TSA signing private key). If this is not the case, or when
additional assurances are required, the certificate or
certificate serial number and issuer of temporal data, see Appendix the TSA shall be
Document Expiration: September 12, 1998 Page 6
included in the encapsulation of the time stamp token as an
authenticated attribute.
5. References
[CMP] C.
3.1. Requirements Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).
[NOTARY] C. Adams, R. Zuccherato, "Notary Protocols," draft-adams-
notary-0X.txt, 1998 (work in progress).
[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework.
[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).
6. Authors' Addresses
Carlisle Adams Pat Cain
Entrust Technologies BBN
750 Heron Road 70 Fawcett Street
Ottawa, Ontario Cambridge, MA 02138
K1V 1A7 U.S.A.
CANADA pcain@bbn.com
cadams@entrust.com
Denis Pinkas Robert Zuccherato
Bull S.A. Entrust Technologies
Rue Jean Jaures 750 Heron Road
B.P. 68 Ottawa, Ontario
78340 Les Clayes sous Bois K1V 1A7
FRANCE CANADA
D.Pinkas@frcl.bull.fr robert.zuccherato@entrust.com
Document Expiration: September 12, 1998 Page 7
APPENDIX A - Storage of Data and Token
A time stamp token is meaningless without its associated data. Thus, a
method is required to allow users to store the data and token together
securely. They may be stored as a PKCS #7 SignedData object as
described in [CMS]. That is, the TDA contentType is signedData and
contentInfo is Data, which contains the message associated with the time
stamp token. The TDA SignedData object is required to:
1. verify signed by the person storing the
data and token. This signature is to be used only for storage and for
verifying the temporal integrity of the token and data. The TDA does not examine or
verify Anyone using the token
and data being at some future time stamped or requesting entities in any
way.
2. include must verify the current data associated with a specific
unpredictable event in each temporal data token.
Document Expiration: May 7, 1998 Page 4
3. produce a temporal data and token upon receiving at that
time. This is just a valid request
from method for keeping the TSA.
4. include within each temporal data two pieces of information
together, with some integrity.
For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
type. This attribute type specifies the time stamp token, which must be
included as an identifier to
uniquely determine authenticated attribute of the trust and validation policy used for SignedData object. The
time stamp token attribute type has ASN.1 type TimeStampToken (as
defined in Section 2.4 of this
signature.
5. only produce a temporal data document). A time stamp token on attribute
must have a hash representation of single attribute value.
The object identifier timeStampToken identifies the message.
6. sign each temporal data time stamp token using
attribute type.
timeStampToken ::= { pkcs-9 n <<To be supplied>> }
[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.
APPENDIX B - Placing a key generated exclusively
for this purpose and have this property Signature At a Particular Point in Time
We present an example of the key indicated on
the corresponding certificate.
3.2. TDA Transactions
As the first message a possible use of this mechanism, the TSA requests general time stamping
service. It places a
temporal data token by sending signature at a request (which particular point in time, from
which the appropriate certificate status information (e.g. CRLs) must be
checked. This application is or includes intended to be used in conjunction with
evidence generated using a
TemporalDataReq, as defined below) digital signature mechanism.
Signatures can only be verified according to a non-repudiation policy.
This policy may be implicit or explicit (i.e., indicated in the TDA. As
evidence provided by the
second message, signer). The non-repudiation policy can
specify, among other things, the TDA responds time period allowed by sending a
response (which is or includes a TemporalDataToken, as defined below) signer to
declare the TSA.
3.3. Identification compromise of the TDA
The TDA must sign all temporal data tokens with a signature key reserved
specifically used for the generation of
digital signatures. Thus a signature may not be guaranteed to be valid
until the termination of this time period.
To verify a signature that purpose. The corresponding certificate must
contain incorporates an untrusted time, the extended key usage field extension as defined in [PKIX1]
Section 4.2.1.14 with KeyPurposeID having value id-kp-temporalData.
This extension must following
basic technique may be critical.
id-kp-temporalData OBJECT IDENTIFIER ::= {id-kp ??}
-- Notarizing used:
A) Time stamping information needs to be obtained by the signer or
a verifier.
Document Expiration: September 12, 1998 Page 8
1) The signature is presented to the validity Time Stamping Authority (TSA).
The TSA then returns a TimeStampToken (TST) upon that signature.
2) The invoker of certain information. Key usage bits
-- the service must then verify that may be consistent: digitalSignature, nonRepudiation
3.4. Request and Token Formats
A temporal data request the
TimeStampToken is as follows.
TemporalDataReq ::= SEQUENCE {
tda GeneralName,
messageImprint MessageImprint
--a hash correct.
B) The validity of the data to be time stamped, evidence must be verified :
1) The date/time indicated by the same
--value as signer in the corresponding field signature shall be
compared with the date/time in TimeStampReq
}
A temporal data token the TST. If they are not close
enough (e.g., less than a few hours) the evidence is as follows. considered
to be invalid.
2) The signature is computed over
tdtInfo (encoded using certificate included in the ASN.1 distinguished encoding rules (DER)).
TemporalDataToken ::= SEQUENCE {
tdtInfo TDTInfo,
signature BIT STRING,
--over signed message should be
verified to be valid at the ASN.1 DER encoding time of tstInfo
}
Document Expiration: May 7, 1998 Page 5
TDTInfo ::= SEQUENCE {
tda GeneralName,
signatureAlgorithm AlgorithmIdentifier,
certId CertId,
--must refer to the TDA's public verification certificate
temporalData TemporalData,
messageImprint MessageImprint
--this field signature. It must have the same value as
first be verified and then the similar field
--in TimeStampReq
} appropriate CRL must be
checked.
The temporalData field contains signature has now been placed at a particular point in time. The
appropriate CRLs or other certificate status information mechanism may
be examined to determine the actual validity of the signature at that time.
Appendix C - The TDA
The Temporal Data Authority is a TTP that creates a temporal data that will
be used as substantiating
token. This temporal data token associates a message with a particular
event and provides supplementary evidence for the time included in the
time stamp token.
TemporalData ::= SEQUENCE {
format TEMPORALDATACLASS.&id, --objid
rawdata TEMPORALDATACLASS.&Type --open type
}
TEMPORALDATACLASS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type }
WITH SYNTAX { &Type IDENTIFIED BY &id }
4. Transports
4.1. File Based Protocol
A file containing For example, a time stamp TDA could associate the message must contain only with
the DER
encoding most recent closing value of one PKI message, i.e. there must be no extraneous header or
trailer information in the file.
Such files can be used to transport time stamp messages using for
example, FTP.
4.2. Socket Based Protocol Dow Jones Average. The socket based protocol for time stamp messages temporal
data with which the message is identical to that
used associated should be unpredictable in [PKIX3] Section 5.2 except that port 309 must
order to prevent forward dating of tokens. Authentic values of this
data should also be used.
4.3. Time Stamp Protocol Using E-mail
This section specifies available from a means for conveying ASN.1-encoded messages
for the protocol exchanges described large number of trustworthy sources
in Sections 2 and 3 via Internet
mail.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
This MIME object can be sent and received using common MIME processing
Document Expiration: May 7, 1998 Page 6
engines and provides order to make collusion or corruption of data more difficult. For a simple Internet mail transport for Time Stamp
messages.
4.4. Time Stamp Protocol via HTTP
This subsection specifies
list of possible types of temporal data, see Appendix D.
C.1. Requirements of the TDA
The TDA is required:
1. to only provide a means for conveying ASN.1-encoded messages
for trusted source of temporal data.
2. not to examine the protocol exchanges described in Sections 2 and 3 via imprint being time stamped.
3. to include the
HyperText Transfer Protocol.
A simple MIME object is specified as follows.
Content-Type: application/timestamp
<<the ASN.1 DER-encoded Time Stamp message>>
This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides current data associated with a simple browser-server transport
for Time Stamp messages.
5. Security Considerations
When designing specific
unpredictable event in each temporal data token.
4. to produce a TSA/TDA service, the following considerations have been
identified that have an impact temporal data token upon receiving a valid request
from the validity or "trust" in TSA.
5. to only produce a temporal data token on a hash representation
of the time
stamp token.
1. The TSA/TDA private message.
6. to sign each temporal data token using a key is compromised generated
exclusively for this purpose and have this property of the key
indicated on the corresponding
certificate is revoked. In certificate.
C.2. TDA Transactions
As the first message of this case, any mechanism, the TSA requests a temporal data
token signed by sending a request (which is or includes a TemporalDataReq, as
defined below) to the TDA. As the second message, the TDA responds by
sending a response (which is or includes a TemporalDataToken, as defined
below) to the TSA.
Document Expiration: September 12, 1998 Page 9
C.3. Verifying a TemporalDataToken
The TSA is required to verify the structure of the TemporalDataToken.
It must verify the digital signature in the
TSA/TDA using TemporalDataToken and also
verify that private key cannot what was signed corresponds to what was requested to be trusted. For this
reason, it is imperative
signed. The requester should verify that the TSA's private key be guarded
with proper security TemporalDataToken contains
the correct TDA name, the correct data imprint and controls in order to minimize the
possibility of compromise. In case correct hash
algorithm OID. It should also verify the private key does become
compromised, an audit trail timeliness of all tokens generated the response by
verifying the
TSA/TDA may provide a means to discriminate between genuine and
false tokens.
2. The TSA/TDA signing key must be value of a sufficient length to allow
for a sufficiently long lifetime. Even if this is done, the key
will nonce included in the response against the
value included in the request (exact match needed). Since the TDA's
certificate may have a finite lifetime. Thus, any token signed by been revoked, the
TSA/TDA status of the certificate should
be time stamped again (if authentic copies of old
CRLs are available) or notarized (if they aren't) at checked (e.g. by checking the appropriate ARL) to verify that the
certificate is still valid.
In order to verify the TemporalData inside a later
date TemporalDataToken, it is
necessary to renew know the trust form of the temporal data that exists the TDA has
included in the TSA/TDA's signature.
Time stamp tokens could also be kept with an Evidence Recording
Authority to maintain this trust.
3. When there token.
The TSA is a reason not required to believe that verify the TSA/TDA can no longer TemporalData. However, either the
entity requesting a Time Stamping Token or an entity verifying a Time
Stamping Token containing temporal information may be trusted, interested in such
a verification.
In the authority's certificate must be revoked and
placed on first case, it is unlikely that the appropriate ARL. Thus, at any future temporal information will be
available ahead of time and thus the
tokens signed entity requesting a Time Stamping
Token may need to enter into an online protocol with the corresponding key TDA, or some
other entity, to obtain it. A secure link with that trusted source will not
be valid.
4. Since necessary, i.e. the TSA does not verify message data communication channel or the identity of
the entities, the requester field in TimeStampReq and
TimeStampToken should information itself
must be considered untrusted. If
authentication of this field authenticated and integrity protected. Such a protocol is needed, it TDA
dependent and is recommended that outside the Notary Authority be used, as described in [NOTARY].
Document Expiration: May 7, 1998 Page 7
8. References
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework.
[PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).
[PKIX3] C. Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).
[NOTARY] C. Adams, R. Zuccherato, "Notary Protocols," draft-adams-
notary-0X.txt, 1997
(work in progress).
9. Authors' Addresses
Carlisle Adams Pat Cain
Entrust Technologies BBN
750 Heron Road, Suite 800 70 Fawcett Street
Ottawa, Ontario Cambridge, MA 02138
K1V 1A7 U.S.A.
CANADA pcain@bbn.com
cadams@entrust.com
Denis Pinkas Robert Zuccherato
Bull S.A. Entrust Technologies
Rue Jean Jaures 750 Heron Road, Suite 800
B.P. 68 Ottawa, Ontario
78340 Les Clayes sous Bois K1V 1A7
FRANCE CANADA
D.Pinkas@frcl.bull.fr robert.zuccherato@entrust.com
Document Expiration: May 7, 1998 Page 8
APPENDIX A - Storage scope of Data and this document.
In the second case, if the verification occurs some time after the Time
Stamping Token
A time stamp token has been produced, then it is meaningless without its associated data. Thus, possible to rely on an
authentic source (e.g. a newspaper or a CD-ROM) to verify it against.
The exact method of verification is required to allow users to store TDA dependent and is thus outside
the scope of this document.
C.4. Identification of the TDA
The TDA must sign all temporal data and token together
securely. They may be stored as tokens with a PKCS #7 SignedData object key reserved
specifically for that purpose. The corresponding certificate must
contain the extended key usage field extension as
described defined in [PKCS7]. That is, the contentType is signedData [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-temporalData.
This extension must be critical.
id-kp-temporalData OBJECT IDENTIFIER ::= {id-kp ??}
-- Providing temporal data in support of time stamping services. Key
-- usage bits that may be consistent: digitalSignature,
-- nonRepudiation
C.5. Request and
contentInfo Token Formats
A temporal data request from a TSA is Data, which contains as follows.
TemporalDataReq ::= SEQUENCE {
version Integer { v1(0) },
Document Expiration: September 12, 1998 Page 10
tda GeneralName,
nonce Integer,
--must be the message associated with same value as the corresponding field in
--TimeStampReq
messageImprint MessageImprint
--a hash of the data to be time
stamp token. The stamped, must be the same
--value as the corresponding field in TimeStampReq
}
A TemporalDataToken is as follows. It is encapsulated as a SignedData object
construct [CMS]. The content is signed of type TDTInfo, which is indicated by
the person storing the OID:
TDTInfo OBJECT IDENTIFIER ::= { ?????? }
The temporal data and token.
For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
type. This attribute type specifies must contain only the signature of the TDA. In
some environments, the CA might not perform a proof-of-possession of
the private key when issuing certificates. In these instances, either
the time stamp token, which must certificate of the TDA, or the certificate issuer and serial number
shall be included as an authenticated attribute of attribute.
TDTInfo ::= SEQUENCE {
version Integer { v1(0) },
tda GeneralName,
nonce Integer,
--must have the SignedData object. The
time stamp token attribute type has ASN.1 type TimeStampToken (as
defined same value as the corresponding field in Section 2.4 of this document). A time stamp token attribute
must
--TimeStampReq
temporalData TemporalData,
messageImprint MessageImprint
--must have a single attribute value. the same value as the corresponding field in
--TimeStampReq
}
The object identifier timeStampToken identifies temporalData field contains the actual temporal data that will
be used as substantiating evidence in the time stamp token
attribute type.
timeStampToken token.
TemporalData ::= SEQUENCE { pkcs-9 n <<To be supplied>>
format TEMPORALDATACLASS.&id, --objid
rawdata TEMPORALDATACLASS.&Type --open type
}
[PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data
TEMPORALDATACLASS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type }
WITH SYNTAX { &Type IDENTIFIED BY &id }
C.6. Security Inc., Redwood City, California, November
1993 Release.
APPENDIX B - Placing a Signature At Considerations
When designing a Particular Point in Time
We present TDA service, the following considerations have been
identified that have an example of a possible use of this general time stamping
service. It places a signature at a particular point impact upon the validity or "trust" in time, from
which the appropriate certificate status information (e.g. CRLs) must be
checked. This application
temporal data token.
1. When there is intended to be used in conjunction with
evidence generated using a digital signature mechanism.
Signatures reason to believe that the TDA can only no longer
be verified according to a non-repudiation policy.
This policy may trusted, the authority's certificate must be implicit or explicit (i.e., indicated in revoked and
placed on the
evidence provided by appropriate ARL. Thus, at any future time the signer).
Document Expiration: September 12, 1998 Page 11
tokens signed with the corresponding key will not be valid.
2. The non-repudiation policy can
specify, among other things, TDA private key is compromised and the time period allowed corresponding
certificate is revoked. In this case, any token signed by a signer to
declare the compromise of a signature
TDA using that private key used for cannot be trusted. For this
reason, it is imperative that the generation of
digital signatures. Thus a signature may not TDA's private key be guaranteed
guarded with proper security and controls in order to be valid
until minimize
the termination possibility of this time period.
To verify a signature that incorporates compromise. In case the private key does
become compromised, an untrusted time, audit trail of all tokens generated by
the following
basic technique TDA may be used:
A) Time stamping information needs provide a means to discriminate between genuine
and false tokens.
3. The TDA signing key must be obtained by the signer or of a verifier.
1) The signature is presented sufficient length to the Time Stamping Authority (TSA).
The TSA then returns allow
for a TimeStampToken (TST) upon that signature.
Document Expiration: May 7, 1998 Page 9
2) The invoker of the service must then verify that the
TimeStampToken sufficiently long lifetime. Even if this is correct.
B) The validity of the evidence must be verified :
1) The date/time indicated by done, the signer in key
will have a finite lifetime. Thus, any time stamp token
containing the TDA's signature shall should be
compared with the date/time in the TST. If they time stamped again (if
authentic copies of old CRLs are not close
enough (e.g., less than available) or notarized (if
they aren't) at a few hours) the evidence is considered later date to be invalid.
2) The certificate included renew the trust that exists in
the signed message should TDA's signature. Time stamp tokens could also be
verified kept with
an Evidence Recording Authority to maintain this trust.
4. In certain circumstances, a TDA may not be able to produce a
valid at the time response to a request (for example, if it is unable to
compute signatures for a period of time). In these situations
the signature. It TDA must
first be verified wait until it is again able to produce a valid
response before responding, if this is possible. If this is not
possible, it must ignore the requests and then not respond. Under no
circumstances shall a TDA produce an unsigned response to a
request.
5. This protocol assumes that the appropriate CRL must be
checked.
The signature CA has now been placed at conducted a particular point in time. The
appropriate CRLs test for proof
of possession for each user's signing private key (including
the TDA signing private key).. If this is not the case, or other when
additional assurances are required, the certificate status information mechanism may or
certificate serial number and issuer of the TDA shall be examined to determine
included in the validity encapsulation of the signature at that time. temporal data token as an
authenticated attribute.
[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).
APPENDIX C D - Possible Types of Temporal Data
1) Stock market information
2) Sports results
3) Official weather data for a specific location
4) Lottery results
5) Birth or death announcements in specific newspapers
6) Headlines in specific newspapers
7) Information linking the request with previous and subsequent requests
(e.g. hash values) that can be verified against information that is
made public by the TDA.
8) A signed packet from a secure time source.
Document Expiration: May 7, September 12, 1998 Page 10 12
----