idnits 2.17.1 draft-adams-time-stamp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([ISONR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '... PolicyInformation OPTIONAL,...' RFC 2119 keyword, line 141: '... SEQUENCE OF GeneralName OPTIONAL,...' RFC 2119 keyword, line 195: '... OPTIONAL,...' RFC 2119 keyword, line 202: '... OCTET STRING OPTIONAL...' RFC 2119 keyword, line 358: '... of this protocol SHOULD perform their...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 1998) is 9457 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PKCS9' is mentioned on line 467, but not defined -- No information found for draft-ietf-pkix-ipki3cmp-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CMP' -- No information found for draft-adams-notary-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NOTARY' -- No information found for draft-ietf-pkix-ipki-part1-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISONR' == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-02 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 C. Adams(Entrust Technologies) 2 Internet Draft P. Cain (BBN) 3 expires in six months D. Pinkas (Bull) 4 R. Zuccherato(Entrust Technologies) 5 June 4, 1998 7 Time Stamp Protocols 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This document describes the format of the data returned by a Time 33 Stamp Authority and the protocols to be used when communicating with it. 34 The time stamping service can be used as a Trusted Third Party (TTP) as 35 one component in building reliable non-repudiation services (see 36 [ISONR]). In order to reduce the amount of trust required of a TSA we 37 introduce (in Appendix C) the optional Temporal Data Authority (TDA) 38 whose function is to provide further corroborating evidence of the time 39 contained in the token. We also give an example of how to place a 40 signature at a particular point in time, from which the appropriate 41 certificate status information (e.g. CRLs) may be checked. 43 1. Introduction 45 In order to associate a message with a particular point in time, a 46 Time Stamp Authority (TSA) may need to be used. This Trusted Third 47 Party provides a "proof-of-existence" for this particular message at an 48 instant in time. A TSA may also be used when a trusted time reference 49 is required and when the local clock available cannot be trusted by all 50 parties. The TSA's role is to time stamp a message to establish 51 evidence indicating the time before which the message was generated. 52 This can then be used, for example, to verify that a digital signature 53 was applied before the certificate was revoked thus allowing a revoked 54 public key certificate to be used for verifying signatures created prior 55 to the time of revocation. This is an important public key 57 infrastructure operation. The TSA can also be used to indicate the time 58 of submission when a deadline is critical, or to indicate the time of 59 transaction for entries in a log. An exhaustive list of possible uses 60 of a TSA is beyond the scope of this document. 62 2. The TSA 64 The TSA is a TTP that creates time stamp tokens in order to indicate 65 that a message existed at a particular point in time. 67 For the remainder of this document a `valid request' shall mean one that 68 can be decoded correctly, is of the form specified in Section 2.4, 69 contains the correct TSA name, and is from a supported TSA subscriber. 71 2.1. Requirements of the TSA 73 The TSA is required: 74 1. to provide a trusted source of time. 75 2. not to examine or verify the requesting entities in any way. 76 3. not to examine the imprint being time stamped in any way. 77 4. to include a monotonically incrementing value of the time of day 78 into its time stamp token. 79 5. to produce a time stamp token upon receiving a valid request 80 from the requester. 81 6. to include within each time stamp token an identifier to 82 uniquely indicate the trust and validation policy under which 83 the token was created. 84 7. to only time stamp a hash representation of the message, i.e. a 85 data imprint associated with a one-way collision resistant hash- 86 function OID. 87 8. to examine the OID of the one-way collision resistant hash- 88 function and to verify that this function is "sufficient" (see 89 Section 2.4). 90 9. to sign each time stamp token using a key generated exclusively 91 for this purpose and have this property of the key indicated on 92 the corresponding certificate. 93 10. to include supplementary temporal information in the time stamp 94 token (from TDA's) if asked by the requester. If this is not 95 possible, the TSA shall respond with an error message. 96 11. to provide a signed receipt (i.e. in the form of an 97 appropriately defined time stamp token) to the requester, where 98 appropriate, as defined by policy. 100 2.2. TSA Transactions 102 As the first message of this mechanism, the requesting entity requests a 103 time stamp token by sending a request (which is or includes a 104 TimeStampReq, as defined below) to the Time Stamping Authority. As the 105 second message, the Time Stamping Authority responds by sending a 106 response (which is or includes a TimeStampToken, as defined below) to 107 the requesting entity. 109 Upon receiving the token, the requesting entity verifies its validity 110 by verifying the digital signature in the TimeStampToken and by 111 verifying that what was time stamped corresponds to what was requested 112 to be time stamped. The requester should verify that the TimeStampToken 114 contains the correct TSA name, the correct data imprint and the correct 115 hash algorithm OID. It should then verify the timeliness of the 116 response by verifying either the time included in the response against a 117 local trusted time reference, if one is available, and/or the value of 118 the nonce included in the response against the value included in the 119 request. Since the TSA's certificate may have been revoked, the status 120 of the certificate should be checked (e.g. by checking the appropriate 121 CRL) to verify that the certificate is still valid. If 122 TemporalDataToken's are included in the TimeStampToken, then these 123 should also be verified as was the TimeStampToken (see Appendix C). The 124 token can now be used to establish a trusted time reference. 126 2.3. Identification of the TSA 128 The TSA must sign all time stamp messages with a key reserved 129 specifically for that purpose. The corresponding certificate must 130 contain the extended key usage field extension as defined in [CCP] 131 Section 4.2.1.14 with KeyPurposeID having value id-kp-timeStamping. 132 This extension must be critical. 134 2.4. Request and Token Formats 136 A time stamping request is as follows. 138 TimeStampReq ::= SEQUENCE { 139 version Integer { v1(0) }, 140 reqPolicy PolicyInformation OPTIONAL, 141 tdas SEQUENCE OF GeneralName OPTIONAL, 142 nonce Integer, 143 messageImprint MessageImprint 144 --a hash algorithm OID and the hash value of the data to be 145 --time stamped 146 } 148 The reqPolicy field, if included, indicates the policy under which the 149 TimeStampToken should be provided. PolicyInformation is defined in 150 Section 4.2.1.5 of [CCP]. 152 The tdas field identifies those TDAs which are requested to provide 153 supplementary temporal evidence in the time stamp token. (See Appendix 154 C.) 156 MessageImprint ::= SEQUENCE { 157 hashAlgorithm AlgorithmIdentifier, 158 hashedMessage OCTET STRING } 160 The hash algorithm indicated in the hashAlgorithm field must be a strong 161 hash algorithm. That means that it must be one-way and collision 162 resistant. It is up to the Time Stamp Authority to decide whether or 163 not the given hash algorithm is "sufficient" (based on the current state 164 of knowledge in cryptanalysis and the current state of the art in 165 computational resources, for example). 167 The hashedMessage field should contain the hash of the message to be 168 time stamped. The hash is represented as an OCTET STRING. 170 The time stamp request does not identify the requester, as this 171 information is not validated by the TSA (See Section 2.1). In 172 situations where the TSA requires the identity of the requesting entity, 173 it is suggested that alternate identification means be used (e.g. CMS 174 encapsulation or SSL authentication). 176 A TimeStampToken is as follows. It is encapsulated as a SignedData 177 construct [CMS]. The content is of type TSTInfo, which is indicated by 178 the OID: 180 TSTInfo OBJECT IDENTIFIER ::= { ?????? } 182 The time stamp token must contain only the signature of the TSA. In 183 some environments, the CA might not perform a proof-of-possession of 184 the private key when issuing certificates. In these instances, either 185 the certificate of the TSA, or the certificate issuer and serial number 186 shall be included as an authenticated attribute. 188 TSTInfo ::= SEQUENCE { 189 version Integer { v1(0) }, 190 policy PolicyInformation, 191 status PKIStatusInfo, 192 tsa GeneralName, 193 genTime GeneralizedTime, 194 tdaTokens SEQUENCE OF TemporalDataToken 195 OPTIONAL, 196 nonce Integer, 197 --this field must have the same value as the similar field 198 --in TimeStampReq 199 messageImprint MessageImprint, 200 --this field must have the same value as the similar field 201 --in TimeStampReq 202 tsaFreeData OCTET STRING OPTIONAL 203 --contains supplementary information from the TSA 204 } 206 PKIStatusInfo is defined in Section 3.2.3 of [CMP]. If the PKIStatus 207 field has value `waiting' (3), then this token is a receipt, as defined 208 in Section 2.1. Otherwise, the status field is present to indicate 209 whether or not the time stamping request was fulfilled and, if not, the 210 reason it was rejected. A valid time stamp token will always have value 211 0 (granted) in the PKIStatus field of PKIStatusInfo. Since not all 212 environments will require the use of receipts, support for the value 213 `waiting' is optional. 215 PKIFailureInfo ::= BITSTRING { 216 badAlg (0), 217 -- unrecognized or unsupported Algorithm Identifier 218 badRequest (2), 219 -- transaction not permitted or supported 220 badDataFormat (5), 221 -- the data submitted has the wrong format 222 timeNotAvailable {14}, 223 -- the TSAs time source is not available 224 tdaNotAvailable {15}, 225 -- at least one of the TDAs that were requested isn't available 226 } 228 The statusString field of PKIStatusInfo can be used to include reason 229 text such as "messageImprint field is missing". 231 The purpose of the tsa field is to identify the name of the TSA. It 232 must correspond to one of the subject names included in the certificate 233 that is to be used to verify the token. 234 TemporalDataToken is defined in Appendix C of this document. The 235 tdaTokens field contains the supplementary evidence requested in the 236 TimeStampReq. 238 There may be situations where the TSA may wish to include supplementary 239 non-time stamp related information in the time stamp token (e.g. billing 240 information, usage statistics, etc.). The format of this information is 241 TSA dependant and the value can be placed in the tsafreedata field as an 242 OCTET STRING. Conformant clients are not required to process this 243 field, if present. 245 3. Transports 247 There is no mandatory transport mechanism in this document. All 248 mechanisms are optional. 250 3.1. File Based Protocol 252 A file containing a time stamp message must contain only the DER 253 encoding of one PKI message, i.e. there must be no extraneous header or 254 trailer information in the file. 256 Such files can be used to transport time stamp messages using for 257 example, FTP. 259 3.2. Socket Based Protocol 261 The socket based protocol for time stamp messages is identical to that 262 used in [CMP] Section 5.2 except that port 309 must be used. 264 3.3. Time Stamp Protocol Using E-mail 266 This section specifies a means for conveying ASN.1-encoded messages 267 for the protocol exchanges described in Section 2 and Appendix C via 268 Internet mail. 270 A simple MIME object is specified as follows. 272 Content-Type: application/timestamp 273 Content-Transfer-Encoding: base64 275 <> 277 This MIME object can be sent and received using common MIME processing 278 engines and provides a simple Internet mail transport for Time Stamp 279 messages. 281 3.4. Time Stamp Protocol via HTTP 283 This subsection specifies a means for conveying ASN.1-encoded messages 284 for the protocol exchanges described in Section 2 and Appendix C via the 285 HyperText Transfer Protocol. 287 A simple MIME object is specified as follows. 289 Content-Type: application/timestamp 291 <> 293 This MIME object can be sent and received using common HTTP processing 294 engines over WWW links and provides a simple browser-server transport 295 for Time Stamp messages. 297 4. Security Considerations 299 This entire document concerns security considerations. 301 When designing a TSA/TDA service, the following considerations have been 302 identified that have an impact upon the validity or "trust" in the time 303 stamp token. 305 1. When there is a reason to believe that the TSA can no longer 306 be trusted, the authority's certificate must be revoked and 307 placed on the appropriate CRL. Thus, at any future time the 308 tokens signed with the corresponding key will not be valid. 309 2. The TSA private key is compromised and the corresponding 310 certificate is revoked. In this case, any token signed by the 311 TSA using that private key cannot be trusted. For this 312 reason, it is imperative that the TSA's private key be 313 guarded with proper security and controls in order to minimize 314 the possibility of compromise. In case the private key does 315 become compromised, an audit trail of all tokens generated by 316 the TSA may provide a means to discriminate between genuine 317 and false tokens. 318 3. The TSA signing key must be of a sufficient length to allow 319 for a sufficiently long lifetime. Even if this is done, the key 320 will have a finite lifetime. Thus, any token signed by the 321 TSA should be time stamped again (if authentic copies of old 322 CRLs are available) or notarized (if they aren't) at a later 323 date to renew the trust that exists in the TSA's signature. 324 Time stamp tokens could also be kept with an Evidence Recording 325 Authority to maintain this trust. 326 4. Since the TSA does not verify message data or the identity of 327 the entities, the requester field in TimeStampReq and 328 TimeStampToken should be considered untrusted. If 329 authentication of this field is needed, it is recommended that 330 the Notary Authority be used, as described in [NOTARY]. 331 5. An application using the TSA service should be concerned about 332 the amount of time it is willing to wait for a response. A 333 `man-in-the-middle' attack can introduce delays. Thus, any 334 TimeStampToken that takes more than an acceptable period of time 335 should be considered suspect. 337 6. In certain circumstances, a TSA may not be able to 338 produce a valid response to a request (for example, if it is 339 unable to compute signatures for a period of time). In these 340 situations the TSA must wait until it is again able to produce a 341 valid response before responding, if this is possible. If this 342 is not possible, it must ignore the requests and not respond. 343 Under no circumstances shall a TSA produce an unsigned response 344 to a request. 345 7. This protocol assumes that the CA has conducted a test for proof 346 of possession for each user's signing private key (including 347 the TSA signing private key). If this is not the case, or when 348 additional assurances are required, the certificate or 349 certificate serial number and issuer of the TSA shall be 350 included in the encapsulation of the time stamp token as an 351 authenticated attribute. 353 5. Patent Information 355 The following United States Patents related to time stamping, listed in 356 chronological order, are known by the authors to exist at this time. 357 This may not be an exhaustive list. Other patents may exist or be 358 issued at any time. Implementers of this protocol SHOULD perform their 359 own patent search and determine whether or not any encumberences exist 360 on their implementation. 362 # 4,309,569 Method of Providing Digital Signatures 363 (issued) January 5, 1982 364 (inventor) Ralph C. Merkle 365 (assignee) The Board of Trustees of the Leland Stanford Junior 366 University 368 # 5,001,752 Public/Key Date-Time Notary Facility 369 (issued) March 19, 1991 370 (inventor) Addison M. Fischer 372 # 5,022,080 Electronic Notary 373 (issued) June 4, 1991 374 (inventors) Robert T. Durst, Kevin D. Hunter 376 # 5,136,643 Public/Key Date-Time Notary Facility 377 (issued) August 4, 1992 378 (inventor) Addison M. Fischer 379 Note: This is a continuation of patent # 5,001,752.) 381 # 5,136,646 Digital Document Time-Stamping with Catenate Certificate 382 (issued) August 4, 1992 383 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 384 (assignee) Bell Communications Research, Inc., 386 # 5,136,647 Method for Secure Time-Stamping of Digital Documents 387 (issued) August 4, 1992 388 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 389 (assignee) Bell Communications Research, Inc., 391 # 5,373,561 Method of Extending the Validity of a Cryptographic 392 Certificate 393 (issued) December 13, 1994 394 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 395 (assignee) Bell Communications Research, Inc., 397 # 5,422,95 Personal Date/Time Notary Device 398 (issued) June 6, 1995 399 (inventor) Addison M. Fischer 401 6. References 403 [CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure, 404 Certificate Management Protocols," draft-ietf-pkix-ipki3cmp- 405 0X.txt, 1997 (work in progress). 407 [NOTARY] C. Adams, R. Zuccherato, "Notary Protocols," draft-adams- 408 notary-0X.txt, 1998 (work in progress). 410 [CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key 411 Infrastructure, X.509 Certificate and CRL Profile," draft- 412 ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress). 414 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 415 Non-Repudiation Framework. 417 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms- 418 02.txt, 1998 (work in progress). 420 7. Authors' Addresses 422 Carlisle Adams Pat Cain 423 Entrust Technologies BBN 424 750 Heron Road 70 Fawcett Street 425 Ottawa, Ontario Cambridge, MA 02138 426 K1V 1A7 U.S.A. 427 CANADA pcain@bbn.com 428 cadams@entrust.com 430 Denis Pinkas Robert Zuccherato 431 Bull S.A. Entrust Technologies 432 Rue Jean Jaures 750 Heron Road 433 B.P. 68 Ottawa, Ontario 434 78340 Les Clayes sous Bois K1V 1A7 435 FRANCE CANADA 436 Denis.Pinkas@bull.net robert.zuccherato@entrust.com 438 APPENDIX A - Storage of Data and Token 440 A time stamp token is meaningless without its associated data. Thus, a 441 method is required to allow users to store the data and token together 442 securely. They may be stored as a PKCS #7 SignedData object as 443 described in [CMS]. That is, the contentType is signedData and 444 contentInfo is Data, which contains the message associated with the time 445 stamp token. The SignedData object is signed by the person storing the 446 data and token. This signature is to be used only for storage and for 447 verifying the integrity of the token and data. Anyone using the token 448 and data at some future time must verify the data and token at that 449 time. This is just a method for keeping the two pieces of information 450 together, with some integrity. 452 For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 453 type. This attribute type specifies the time stamp token, which must be 454 included as an authenticated attribute of the SignedData object. The 455 time stamp token attribute type has ASN.1 type TimeStampToken (as 456 defined in Section 2.4 of this document). A time stamp token attribute 457 must have a single attribute value. 459 The object identifier timeStampToken identifies the time stamp token 460 attribute type. 462 timeStampToken ::= { pkcs-9 n <> } 464 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms- 465 02.txt, 1998 (work in progress). 467 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 468 (PKCS)", RSA Data Security Inc., Redwood City, California, November 469 1993 Release. 471 APPENDIX B - Placing a Signature At a Particular Point in Time 473 We present an example of a possible use of this general time stamping 474 service. It places a signature at a particular point in time, from 475 which the appropriate certificate status information (e.g. CRLs) must be 476 checked. This application is intended to be used in conjunction with 477 evidence generated using a digital signature mechanism. 479 Signatures can only be verified according to a non-repudiation policy. 480 This policy may be implicit or explicit (i.e., indicated in the 481 evidence provided by the signer). The non-repudiation policy can 482 specify, among other things, the time period allowed by a signer to 483 declare the compromise of a signature key used for the generation of 484 digital signatures. Thus a signature may not be guaranteed to be valid 485 until the termination of this time period. 487 To verify a signature that incorporates an untrusted time, the following 488 basic technique may be used: 490 A) Time stamping information needs to be obtained by the signer or 491 a verifier. 493 1) The signature is presented to the Time Stamping Authority (TSA). 494 The TSA then returns a TimeStampToken (TST) upon that signature. 495 2) The invoker of the service must then verify that the 496 TimeStampToken is correct. 498 B) The validity of the evidence must be verified : 500 1) The date/time indicated by the signer in the signature shall be 501 compared with the date/time in the TST. If they are not close 502 enough (e.g., less than a few hours) the evidence is considered 503 to be invalid. 504 2) The certificate included in the signed message should be 505 verified to be valid at the time of the signature. It must 506 first be verified and then the appropriate CRL must be 507 checked. 509 The signature has now been placed at a particular point in time. The 510 appropriate CRLs or other certificate status information mechanism may 511 be examined to determine the validity of the signature at that time. 513 Appendix C - The TDA 515 The Temporal Data Authority is a TTP that creates a temporal data 516 token. This temporal data token associates a message with a particular 517 event and provides supplementary evidence for the time included in the 518 time stamp token. For example, a TDA could associate the message with 519 the most recent closing value of the Dow Jones Average. The temporal 520 data with which the message is associated should be unpredictable in 521 order to prevent forward dating of tokens. Authentic values of this 522 data should also be available from a large number of trustworthy sources 523 in order to make collusion or corruption of data more difficult. For a 524 list of possible types of temporal data, see Appendix D. 526 C.1. Requirements of the TDA 528 The TDA is required: 529 1. to only provide a trusted source of temporal data. 530 2. not to examine the imprint being time stamped. 531 3. to include the current data associated with a specific 532 unpredictable event in each temporal data token. 533 4. to produce a temporal data token upon receiving a valid request 534 from the TSA. 535 5. to only produce a temporal data token on a hash representation 536 of the message. 537 6. to sign each temporal data token using a key generated 538 exclusively for this purpose and have this property of the key 539 indicated on the corresponding certificate. 541 C.2. TDA Transactions 543 As the first message of this mechanism, the TSA requests a temporal data 544 token by sending a request (which is or includes a TemporalDataReq, as 545 defined below) to the TDA. As the second message, the TDA responds by 546 sending a response (which is or includes a TemporalDataToken, as defined 547 below) to the TSA. 549 C.3. Verifying a TemporalDataToken 551 The TSA is required to verify the structure of the TemporalDataToken. 552 It must verify the digital signature in the TemporalDataToken and also 553 verify that what was signed corresponds to what was requested to be 554 signed. The requester should verify that the TemporalDataToken contains 555 the correct TDA name, the correct data imprint and the correct hash 556 algorithm OID. It should also verify the timeliness of the response by 557 verifying the value of the nonce included in the response against the 558 value included in the request (exact match needed). Since the TDA's 559 certificate may have been revoked, the status of the certificate should 560 be checked (e.g. by checking the appropriate CRL) to verify that the 561 certificate is still valid. 563 In order to verify the TemporalData inside a TemporalDataToken, it is 564 necessary to know the form of the temporal data that the TDA has 565 included in the token. 567 The TSA is not required to verify the TemporalData. However, either the 568 entity requesting a Time Stamping Token or an entity verifying a Time 569 Stamping Token containing temporal information may be interested in such 570 a verification. 572 In the first case, it is unlikely that the temporal information will be 573 available ahead of time and thus the entity requesting a Time Stamping 574 Token may need to enter into an online protocol with the TDA, or some 575 other entity, to obtain it. A secure link with that trusted source will 576 be necessary, i.e. the communication channel or the information itself 577 must be authenticated and integrity protected. Such a protocol is TDA 578 dependent and is outside the scope of this document. 580 In the second case, if the verification occurs some time after the Time 581 Stamping Token has been produced, then it is possible to rely on an 582 authentic source (e.g. a newspaper or a CD-ROM) to verify it against. 583 The exact method of verification is TDA dependent and is thus outside 584 the scope of this document. 586 C.4. Identification of the TDA 588 The TDA must sign all temporal data tokens with a key reserved 589 specifically for that purpose. The corresponding certificate must 590 contain the extended key usage field extension as defined in [CCP] 591 Section 4.2.1.14 with KeyPurposeID having value id-kp-temporalData. 592 This extension must be critical. 594 id-kp-temporalData OBJECT IDENTIFIER ::= {id-kp ??} 595 -- Providing temporal data in support of time stamping services. Key 596 -- usage bits that may be consistent: digitalSignature, 597 -- nonRepudiation 599 C.5. Request and Token Formats 601 A temporal data request from a TSA is as follows. 603 TemporalDataReq ::= SEQUENCE { 604 version Integer { v1(0) }, 606 nonce Integer, 607 --must be the same value as the corresponding field in 608 --TimeStampReq 609 messageImprint MessageImprint 610 --a hash of the data to be time stamped, must be the same 611 --value as the corresponding field in TimeStampReq 612 } 614 A TemporalDataToken is as follows. It is encapsulated as a SignedData 615 construct [CMS]. The content is of type TDTInfo, which is indicated by 616 the OID: 618 TDTInfo OBJECT IDENTIFIER ::= { ?????? } 620 The temporal data token must contain only the signature of the TDA. In 621 some environments, the CA might not perform a proof-of-possession of 622 the private key when issuing certificates. In these instances, either 623 the certificate of the TDA, or the certificate issuer and serial number 624 shall be included as an authenticated attribute. 626 TDTInfo ::= SEQUENCE { 627 version Integer { v1(0) }, 628 tda GeneralName, 629 nonce Integer, 630 --must have the same value as the corresponding field in 631 --TimeStampReq 632 temporalData TemporalData, 633 messageImprint MessageImprint 634 --must have the same value as the corresponding field in 635 --TimeStampReq 636 } 638 The temporalData field contains the actual temporal data that will 639 be used as substantiating evidence in the time stamp token. 641 TemporalData ::= SEQUENCE { 642 format TEMPORALDATACLASS.&id, --objid 643 rawdata TEMPORALDATACLASS.&Type --open type 644 } 646 TEMPORALDATACLASS ::= CLASS { 647 &id OBJECT IDENTIFIER UNIQUE, 648 &Type } 649 WITH SYNTAX { &Type IDENTIFIED BY &id } 651 C.6. Security Considerations 653 When designing a TDA service, the following considerations have been 654 identified that have an impact upon the validity or "trust" in the 655 temporal data token. 657 1. When there is a reason to believe that the TDA can no longer 658 be trusted, the authority's certificate must be revoked and 659 placed on the appropriate CRL. Thus, at any future time the 661 tokens signed with the corresponding key will not be valid. 662 2. The TDA private key is compromised and the corresponding 663 certificate is revoked. In this case, any token signed by the 664 TDA using that private key cannot be trusted. For this 665 reason, it is imperative that the TDA's private key be 666 guarded with proper security and controls in order to minimize 667 the possibility of compromise. In case the private key does 668 become compromised, an audit trail of all tokens generated by 669 the TDA may provide a means to discriminate between genuine 670 and false tokens. 671 3. The TDA signing key must be of a sufficient length to allow 672 for a sufficiently long lifetime. Even if this is done, the key 673 will have a finite lifetime. Thus, any time stamp token 674 containing the TDA's signature should be time stamped again (if 675 authentic copies of old CRLs are available) or notarized (if 676 they aren't) at a later date to renew the trust that exists in 677 the TDA's signature. Time stamp tokens could also be kept with 678 an Evidence Recording Authority to maintain this trust. 679 4. In certain circumstances, a TDA may not be able to produce a 680 valid response to a request (for example, if it is unable to 681 compute signatures for a period of time). In these situations 682 the TDA must wait until it is again able to produce a valid 683 response before responding, if this is possible. If this is not 684 possible, it must ignore the requests and not respond. Under no 685 circumstances shall a TDA produce an unsigned response to a 686 request. 687 5. This protocol assumes that the CA has conducted a test for proof 688 of possession for each user's signing private key (including 689 the TDA signing private key).. If this is not the case, or when 690 additional assurances are required, the certificate or 691 certificate serial number and issuer of the TDA shall be 692 included in the encapsulation of the temporal data token as an 693 authenticated attribute. 695 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms- 696 02.txt, 1998 (work in progress). 698 APPENDIX D - Possible Types of Temporal Data 700 1) Stock market information 701 2) Sports results 702 3) Official weather data for a specific location 703 4) Lottery results 704 5) Birth or death announcements in specific newspapers 705 6) Headlines in specific newspapers 706 7) Information linking the request with previous and subsequent requests 707 (e.g. hash values) that can be verified against information that is 708 made public by the TDA. 709 8) A signed packet from a secure time source.