[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

                                          C. Adams(Entrust Technologies)
Internet Draft                                             P. Cain (BBN)
expires in six months                                   D. Pinkas (Bull)
                                     R. Zuccherato(Entrust Technologies)
                                                        November 7, 1997


                          Time Stamp Protocols

                    <draft-adams-time-stamp-00.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 (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 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, 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.

2.1. Requirements of the TSA

The TSA is required to:
     1. verify only the time.  The TSA does not examine or verify the
        data being time stamped or the requesting entities in any way.
     2. include a monotonically incrementing value of the time of day
        into its time stamp token.
     3. produce a time stamp token upon receiving a valid request from
        the requester.
     4. include within each time stamp token an identifier to
        uniquely determine the trust and validation policy used for this
        signature.
     5. only time stamp a hash representation of the message.
     6. 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. include supplementary temporal information in the time stamp
        token (from TDA's) if asked by the requester.
     8. 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 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 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 contains
the correct time, the correct TSA name, the correct data imprint and
the correct hash algorithm OID.  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.  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]
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  {
     requester                [0] GeneralName OPTIONAL,
     reqPolicy                [1] PolicyInformation OPTIONAL,
     tsa                          GeneralName,
     tdas                         SEQUENCE OF GeneralName,
     messageImprint               MessageImprint
       --a hash of the data to be time stamped
}

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].

The tsa field identifies the name of the TSA.  GeneralName is defined
in Section 4.2.1.7 of [PKIX1].

The tdas field identifies those TDAs which are requested to provide
supplementary temporal evidence in the time stamp token.

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

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 is as follows.  The signature is computed over
tstInfo (encoded using the ASN.1 distinguished encoding rules (DER)).

TimeStampToken ::= SEQUENCE  {
     tstInfo                      TSTInfo,
     signature                    BIT STRING,
       --over the ASN.1 DER encoding of tstInfo
}




Document Expiration:  May 7, 1998                                Page 3

TSTInfo ::= SEQUENCE  {
     policy                       PolicyInformation OPTIONAL,
     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                          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,
     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].  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.

TemporalDataToken is defined in Section 3 of this document.  The
tdaTokens field contains the supplementary evidence requested in the
TimeStampReq.

CertId is defined in Section 3.2.4 of [PKIX3].

3. The TDA

The Temporal Data Authority 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 in the
time stamp token.  For example,  a TDA could associate the message with
the most recent closing value of the Dow Jones Average.  The temporal
data with which the message is associated should be unpredictable in
order to prevent forward dating of tokens.  Authentic values of this
data should also be available from a large number of trustworthy sources
in order to make collusion or corruption of data impossible.  For a list
of possible types of temporal data, see Appendix C.

3.1. Requirements of the TDA

The TDA is required to:
     1. verify only the temporal data.  The TDA does not examine or
        verify the data being time stamped or requesting entities in any
        way.
     2. include 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 token upon receiving a valid request
        from the TSA.
     4. include within each temporal data token an identifier to
        uniquely determine the trust and validation policy used for this
        signature.
     5. only produce a temporal data token on a hash representation of
        the message.
     6. sign each temporal data token using a key generated exclusively
        for this purpose and have this property of the key indicated on
        the corresponding certificate.

3.2. TDA Transactions

As the first message of this mechanism, the TSA requests a
temporal data token 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.


3.3. Identification of the TDA

The TDA must sign all temporal data tokens with a key reserved
specifically for that purpose.  The corresponding certificate must
contain 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 be critical.

id-kp-temporalData    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Notarizing the validity of certain information.  Key usage bits
  -- that may be consistent:  digitalSignature, nonRepudiation


3.4. Request and Token Formats

A temporal data request is as follows.

TemporalDataReq ::= SEQUENCE  {
     tda                          GeneralName,
     messageImprint               MessageImprint
       --a hash of the data to be time stamped, must be the same
       --value as the corresponding field in TimeStampReq
}

A temporal data token is as follows.  The signature is computed over
tdtInfo (encoded using the ASN.1 distinguished encoding rules (DER)).

TemporalDataToken ::= SEQUENCE  {
     tdtInfo                      TDTInfo,
     signature                    BIT STRING,
       --over the ASN.1 DER encoding 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 must have the same value as the similar field
       --in TimeStampReq
}

The temporalData field contains the actual temporal data that will
be used as substantiating evidence 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 a time stamp message must contain only the DER
encoding 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

The socket based protocol for time stamp messages is identical to that
used in [PKIX3] Section 5.2 except that port 309 must be used.

4.3. Time Stamp Protocol Using E-mail

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described 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 a simple Internet mail transport for Time Stamp
messages.

4.4. Time Stamp Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Sections 2 and 3 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>>

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.

5. 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. The TSA/TDA private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        TSA/TDA 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/TDA may provide a means to discriminate between genuine and
        false tokens.

     2. The TSA/TDA signing key must be of a sufficient length to allow
        for a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any token signed by the
        TSA/TDA 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/TDA's signature.
        Time stamp tokens could also be kept with an Evidence Recording
        Authority to maintain this trust.

     3. When there is a reason to believe that the TSA/TDA 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.

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].



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 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 [PKCS7].  That is, the contentType is signedData and
contentInfo is Data, which contains the message associated with the time
stamp token.  The SignedData object is signed by the person storing the
data and token.

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 authenticated attribute of the SignedData object.  The
time stamp token attribute type has ASN.1 type TimeStampToken (as
defined in Section 2.4 of this document).  A time stamp token attribute
must have a single attribute value.

The object identifier timeStampToken identifies the time stamp token
attribute type.

timeStampToken ::= { pkcs-9 n <<To be supplied>> }

[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 Security Inc., Redwood City, California, November
1993 Release.



APPENDIX B - Placing a Signature At a Particular Point in Time

We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from
which the appropriate certificate status information (e.g. CRLs) must be
checked.  This application is intended to be used in conjunction with
evidence generated using a 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
evidence provided by the signer). The non-repudiation policy can
specify, among other things, the time period allowed by a signer to
declare the compromise of a signature key 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 incorporates an untrusted time, the following
basic technique may be used:

A) Time stamping information needs to be obtained by the signer or
a verifier.

     1) The signature is presented to the Time Stamping Authority (TSA).
        The TSA then returns 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 is correct.

B) The validity of the evidence must be verified :

     1) The date/time indicated by the signer in the signature shall be
        compared with the date/time in the TST. If they are not close
        enough (e.g., less than a few hours) the evidence is considered
        to be invalid.

     2) The certificate included in the signed message should be
        verified to be valid at the time of the signature. It must
        first be verified and then the appropriate CRL must be
        checked.

The 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 validity of the signature at that time.

APPENDIX C - 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






























Document Expiration:  May 7, 1998                                Page 10


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/