idnits 2.17.1 draft-ietf-pkix-pr-tsa-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 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 abstract seems to contain references ([TS102023]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3126 (Obsoleted by RFC 5126) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft D. Pinkas 2 Bull 3 Target Category: INFORMATIONAL N. Pope 4 August 2003 Security & Standards 5 Expires in six months J. Ross 6 Security & Standards 8 Policy Requirements for Time-Stamping Authorities 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document defines requirements for a baseline time-stamp policy 40 for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, 41 supported by public key certificates, with an accuracy of one 42 second or better. A TSA may define its own policy which enhances 43 the policy defined in the current document. Such a policy shall 44 incorporate or further constrain the requirements identified in the 45 current document. 47 Foreword 49 The contents of this Informational RFC is technically equivalent 50 to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023]. The ETSI TS is 51 under the ETSI Copyright (C). Individual copies of this ETSI 52 deliverable can be downloaded from http://www.etsi.org 54 Policy Requirements for Time-Stamping Authorities August 2003 56 Table of Contents 58 1. Introduction 4 60 2. Overview 5 62 3. Definitions and abbreviations 5 64 3.1. Definitions 5 65 3.2. Abbreviations 7 67 4. General concepts 7 69 4.1. Time-stamping services 7 70 4.2. Time-stamping authority 7 71 4.3. Subscriber 8 72 4.4. Time-stamp policy and TSA practice statement 8 73 4.4.1. Purpose 8 74 4.4.2. Level of specificity 8 75 4.4.3. Approach 9 77 5. Time-stamp Policies 9 79 5.1. Overview 9 80 5.2. Identification 9 81 5.3. User Community and applicability 10 82 5.4. Conformance 10 84 6. Obligations and liability 10 86 6.1. TSA obligations 10 87 6.1.1. General 10 88 6.1.2. TSA obligations towards subscribers 11 89 6.2. Subscriber obligations 11 90 6.3. Relying party obligations 11 91 6.4. Liability 11 93 7. Requirements on TSA practices 11 95 7.1. Practice and Disclosure Statements 12 96 7.1.1. TSA Practice statement 12 97 7.1.2. TSA disclosure Statement 13 98 7.2. Key management life cycle 14 99 7.2.1. TSU key generation 14 100 7.2.2. TSU private key protection 15 101 7.2.3. TSU public key Distribution 15 102 7.2.4. Rekeying TSU's Key 16 103 7.2.5. End of TSU key life cycle 16 104 7.2.6. Life cycle management of the cryptographic module 105 used to sign time-stamps 17 107 Policy Requirements for Time-Stamping Authorities August 2003 109 7.3. Time-stamping 17 111 7.3.1. Time-stamp token 17 112 7.3.2. Clock Synchronization with UTC 18 114 7.4. TSA management and operation 19 116 7.4.1. Security management 19 117 7.4.2. Asset classification and management 20 118 7.4.3. Personnel security 20 119 7.4.4. Physical and environmental security 22 120 7.4.5. Operations management 23 121 7.4.6. System Access Management 24 122 7.4.7. Trustworthy Systems Deployment and Maintenance 25 123 7.4.8. Compromise of TSA Services 25 124 7.4.9. TSA termination 26 125 7.4.10. Compliance with Legal Requirements 27 126 7.4.11. Recording of Information Concerning Operation 127 of Time-stamping Services 27 128 7.5. Organizational 28 130 8. Security considerations 29 132 9. Acknowledgments 30 134 10. References 30 136 10.1. Normative References 30 137 10.2. Non-normative References 30 139 11. Authors' addresses 31 141 Annex A (informative): Coordinated Universal Time 33 143 Annex B (informative): Possible for Implementation Architectures and 144 Time-Stamping Services 35 146 Annex C (informative): Long Term Verification of time-stamp tokens 37 148 Annex D (informative): Model TSA disclosure statement 38 150 Full Copyright Statement 40 152 Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC 2119]. 158 Policy Requirements for Time-Stamping Authorities August 2003 160 1. Introduction 162 In creating reliable and manageable digital evidence it becomes 163 necessary to have an agreed upon method of associating time data to 164 transaction so that they might be compared to each other at some later 165 time. The quality of this evidence is based in the process of creating 166 and managing the data structure that represent the events and the 167 quality of the parametric data points that anchor them to the real 168 world. In this instance this being the time data and how it was 169 applied. 171 A typical transaction is a digitally signed document, where it is 172 necessary to prove that the digital signature from the signer was 173 applied when the signer's certificate was valid. 175 A timestamp or a time mark (which is an audit record kept in a secure 176 audit trail from a trusted third party) applied to a digital signature 177 value proves that the digital signature was created before the date 178 included in the time-stamp or time mark. 180 To prove the digital signature was generated while the signer's 181 certificate was valid, the digital signature must be verified and 182 the following conditions satisfied: 184 1. the time-stamp (or time mark) has been applied before the end 185 of the validity period of the signer's certificate, 187 2. the time-stamp (or time mark) has been applied either 188 while the signer's certificate was not revoked or 189 before the revocation date of the certificate. 191 Thus a time-stamp (or time mark) applied in this manner proves that the 192 digital signature was created while the signer's certificate was valid. 193 This concept can be extended to prove the validity of a digital 194 signature over the whole of any certificate chain. 196 Policy requirements to cover that case is the primary reason of the 197 present document. However, it should be observed that these policy 198 requirements can be used to address other needs. 200 The electronic time stamp is gaining an increasing interest by the 201 business sector and is becoming an important component of electronic 202 signatures, also featured by the ETSI Electronic Signature Format 203 standard [TS 101733] or Electronic Signature Formats for long term 204 electronic signatures [RFC 3126], built upon the Time-Stamp Protocol 205 [RFC 3161]. Agreed minimum security and quality requirements are 206 necessary in order to ensure trustworthy validation of long-term 207 electronic signatures. 209 The European Directive 1999/93/EC [Dir 99/93/EC] defines certification 210 service provider as "an entity or a legal or natural person who issues 211 certificates or provides other services related to electronic 212 signatures". One example of a certification-service-provider is a 213 Time-Stamping Authority. 215 Policy Requirements for Time-Stamping Authorities August 2003 217 2. Overview 219 These policy requirements are primarily aimed at time-stamping services 220 used in support of qualified electronic signatures (i.e. in line with 221 article 5.1 of the European Directive on a community framework for 222 electronic signatures) but may be applied to any application requiring 223 to prove that a datum existed before a particular time. 225 These policy requirements are based upon the use of public key 226 cryptography, public key certificates and reliable time sources. 227 The present document may be used by independent bodies as the basis for 228 confirming that a TSA may be trusted for providing time-stamping 229 services. 231 The current document addresses requirements for TSAs issuing time-stamp 232 tokens which are synchronized with Coordinated universal time (UTC) and 233 digitally signed by TSUs. 235 Subscriber and relying parties should consult the TSA's practice 236 statement to obtain further details of precisely how this time-stamp 237 policy is implemented by the particular TSA (e.g. protocols used in 238 providing this service). 240 The current document does not specify: 242 - protocols used to access the TSUs; 244 NOTE 1: A time-stamping protocol is defined in RFC 3161 [RFC 3161] and 245 profiled in TS 101 861 [TS 101861]. 247 - how the requirements identified herein may be assessed by an 248 independent body; 250 - requirements for information to be made available to such 251 independent bodies; 253 - requirements on such independent bodies. 255 NOTE 2: See CEN Workshop Agreement 14172 "EESSI Conformity Assessment 256 Guidance" [CWA 14172]. 258 3. Definitions and abbreviations 260 3.1. Definitions 262 For the purposes of the present document, the following terms and 263 definitions apply: 265 NOTE: Where a definition is copied from a referenced document this is 266 indicated by inclusion of the reference identifier number at the end of 267 the definition. 269 Policy Requirements for Time-Stamping Authorities August 2003 271 relying party: recipient of a time-stamp token who relies on that 272 time-stamp token. 274 subscriber: entity requiring the services provided by a TSA and which 275 has explicitly or implicitly agreed to its terms and conditions. 277 time-stamp token: data object that binds a representation of a datum to 278 a particular time, thus establishing evidence that the datum existed 279 before that time. 281 time-stamping authority: authority which issues time-stamp tokens. 283 TSA Disclosure statement: set of statements about the policies and 284 practices of a TSA that particularly require emphasis or disclosure to 285 subscribers and relying parties, for example to meet regulatory 286 requirements. 288 TSA practice statement: statement of the practices that a TSA employs 289 in issuing time-stamp tokens. 291 TSA system: composition of IT products and components organized to 292 support the provision of time-stamping services. 294 time-stamp policy: named set of rules that indicates the applicability 295 of a time-stamp token to a particular community and/or class of 296 application with common security requirements. 298 time-stamping unit: set of hardware and software which is managed as a 299 unit and has a single time-stamp token signing key active at a time. 301 Coordinated Universal Time (UTC): Time scale based on the second as 302 defined in ITU-R Recommendation TF.460-5 [TF.460-5]. 304 NOTE: For most practical purposes UTC is equivalent to mean solar time 305 at the prime meridian. More specifically, UTC is a compromise 306 between the highly stable atomic time (Temps Atomique International 307 - TAI) and solar time derived from the irregular Earth rotation 308 (related to the Greenwich mean sidereal time (GMST) by a conventional 309 relationship). (See annex A for more details). 311 UTC(k): Time-scale realized by the laboratory "k" and kept in close 312 agreement with UTC, with the goal to reach plus or minus 100 ns. 313 (See ITU-R Recommendation TF.536-1 [TF.536-1]). 315 NOTE: A list of UTC(k) laboratories is given in section 1 of 316 Circular T disseminated by BIPM and available from the BIPM website 317 (http://www.bipm.org/). 319 3.2. Abbreviations 321 For the purposes of the present document, the following abbreviations 322 apply: 324 Policy Requirements for Time-Stamping Authorities August 2003 326 TSA Time-Stamping Authority 327 TSU Time-Stamping Unit 328 TST Time-Stamp Token 329 UTC Coordinated Universal Time 331 4. General concepts 333 4.1 Time-stamping services 335 The provision of time-stamping services is broken down in the present 336 document into the following component services for the purposes of 337 classifying requirements: 339 - Time-stamping provision: This service component generates 340 time-stamp tokens. 342 - Time-stamping management: The service component that monitors and 343 controls the operation of the time-stamping services to ensure 344 that the service provided is as specified by the TSA. This service 345 component has responsibility for the installation and 346 de-installation of the time-stamping provision service. 347 For example, time-stamping management ensures that the clock used 348 for time-stamping is correctly synchronized with UTC. 350 This subdivision of services is only for the purposes of clarifying 351 the requirements specified in the current document and places no 352 restrictions on any subdivision of an implementation of time-stamping 353 services. 355 4.2 Time-stamping authority 357 The authority trusted by the users of the time-stamping services (i.e. 358 subscribers as well as relying parties) to issue time-stamp tokens is 359 called the Time-Stamping Authority (TSA). The TSA has overall 360 responsibility for the provision of the time-stamping services 361 identified in clause 4.1. The TSA has responsibility for the operation 362 of one or more TSU's which creates and signs on behalf of the TSA. The 363 TSA responsible for issuing a time-stamp token is identifiable (see 364 7.3.1 h). 366 The TSA may make use of other parties to provide parts of the 367 Time-Stamping Services. However, the TSA always maintains overall 368 responsibility and ensures that the policy requirements identified in 369 the present document are met. For example, a TSA may sub-contract all 370 the component services, including the services which generate 371 time-stamp tokens using the TSU's keys. However, the private key or 372 keys used to generate the time-stamp tokens are identified as 373 belonging to the TSA which maintains overall responsibility for 374 meeting the requirements defined in the current document. 376 A TSA may operate several identifiable time-stamping units. Each unit 377 has a different key. See Annex B for possible implementations. 379 Policy Requirements for Time-Stamping Authorities August 2003 381 A TSA is a certification-service-provider, as defined in the EU 382 Directive on Electronic Signatures (see article 2(11)), which issues 383 time-stamp tokens. 385 4.3 Subscriber 387 The subscriber may be an organization comprising several end-users or 388 an individual end-user. 390 When the subscriber is an organization, some of the obligations that 391 apply to that organization will have to apply as well to the end-users. 392 In any case the organization will be held responsible if the 393 obligations from the end-users are not correctly fulfilled and 394 therefore the such an organization is expected to suitably inform its 395 end users. 397 When the subscriber is an end-user, the end-user will be held directly 398 responsible if its obligations are not correctly fulfilled. 400 4.4 Time-stamp policy and TSA practice statement 402 This section explains the relative roles of Time-stamp policy and TSA 403 practice statement. It places no restriction on the form of a 404 time-stamp policy or practice statement specification. 406 4.4.1 Purpose 408 In general, the time-stamp policy states "what is to be adhered to," 409 while a TSA practice statement states "how it is adhered to", i.e., the 410 processes it will use in creating time-stamps and maintaining the 411 accuracy of its clock. The relationship between the time-stamp policy 412 and TSA practice statement is similar in nature to the relationship of 413 other business policies which state the requirements of the business, 414 while operational units define the practices and procedures of how 415 these policies are to be carried out. 417 The present document specifies a time-stamp policy to meet general 418 requirements for trusted time-stamping services. TSAs specify in TSA 419 practice statements how these requirements are met. 421 4.4.2 Level of specificity 423 A time-stamp policy is a less specific document than a TSA practice 424 statement. A TSA practice statement is a more detailed description of 425 the terms and conditions as well as business and operational practices 426 of a TSA in issuing and otherwise managing time-stamping services. The 427 TSA practice statement of a TSA enforces the rules established by a 428 time-stamp policy. A TSA practice statement defines how a specific TSA 429 meets the technical, organizational and procedural requirements 430 identified in a time-stamp policy. 432 NOTE: Even lower-level internal documentation may be appropriate for a 433 TSA detailing the specific procedures necessary to complete the 434 practices identified in the TSA practice statement. 436 Policy Requirements for Time-Stamping Authorities August 2003 438 4.4.3 Approach 440 The approach of a time-stamp policy is significantly different from a 441 TSA practice statement. A time-stamp policy is defined independently of 442 the specific details of the specific operating environment of a TSA, 443 whereas a TSA practice statement is tailored to the organizational 444 structure, operating procedures, facilities, and computing environment 445 of a TSA. A time-stamp policy may be defined by the user of times-stamp 446 services, whereas the TSA practice statement is always defined by the 447 provider. 449 5 Time-stamp Policies 451 5.1 Overview 453 A time-stamp policy is a "named set of rules that indicates the 454 applicability of a time-stamp token to a particular community and/or 455 class of application with common security requirements" (see clauses 456 3.1 and 4.4). 458 The present document defines requirements for a baseline time-stamp 459 policy for TSAs issuing time-stamp tokens, supported by public key 460 certificates, with an accuracy of 1 second or better. 462 NOTE 1: Without additional measures the relying party may not be able 463 to ensure the validity of a time-stamp token beyond the end of the 464 validity period of the supporting certificate. See annex C on 465 verification of the validity of a time-stamp token beyond the validity 466 period of the TSU's certificate. 468 A TSA may define its own policy which enhances the policy defined in 469 the current document. Such a policy shall incorporate or further 470 constrain the requirements identified in the current document. 472 If an accuracy of better than 1 second is provided by a TSA then, if 473 all the TSUs have that same characteristics, the accuracy shall be 474 indicated in the TSA's disclosure statement (see section 7.1.2) 475 otherwise in each time-stamp token issued with an accuracy of 476 better than 1 second. 478 NOTE 2: It is required that a time-stamp token includes an identifier 479 for the applicable policy (see section 7.3.1). 481 5.2 Identification 483 The object-identifier [X.208] of the baseline time-stamp policy is: 484 itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) 485 policy-identifiers(1) baseline-ts-policy (1) 487 A TSA shall also include the identifier for the time-stamp policy being 488 supported in the TSA disclosure statement made available to subscribers 489 and relying parties to indicate its claim of conformance. 491 Policy Requirements for Time-Stamping Authorities August 2003 493 5.3 User Community and applicability 495 This policy is aimed at meeting the requirements of time-stamping 496 qualified electronic signatures (see European Directive on Electronic 497 Signatures) for long term validity (e.g. as defined in TS 101 733 498 [TS 101733]) but is generally applicable to any use which has a 499 requirement for equivalent quality. 501 This policy may be used for public time-stamping services or 502 time-stamping services used within a closed community. 504 5.4 Conformance 506 The TSA shall use the identifier for the time-stamp policy in 507 time-stamp tokens as given in section 5.2, or define its own time-stamp 508 policy that incorporates or further constrains the requirements 509 identified in the present document: 511 a) if the TSA claims conformance to the identified time-stamp policy 512 and makes available to subscribers and relying parties on request the 513 evidence to support the claim of conformance; or 515 b) if the TSA has been assessed to be conformant to the identified 516 time-stamp policy by an independent party. 518 A conformant TSA must demonstrate that: 520 a) it meets its obligations as defined in section 6.1; 521 b) it has implemented controls which meet the requirements specified in 522 section 7. 524 6 Obligations and liability 526 6.1 TSA obligations 528 6.1.1 General 530 The TSA shall ensure that all requirements on TSA, as detailed in 531 section 7, are implemented as applicable to the selected trusted 532 time-stamp policy. 534 The TSA shall ensure conformance with the procedures prescribed in this 535 policy, even when the TSA functionality is undertaken by 536 sub-contractors. 538 The TSA shall also ensure adherence to any additional obligations 539 indicated in the time-stamp either directly or incorporated by 540 reference. 542 The TSA shall provide all its time-stamping services consistent with 543 its practice statement. 545 Policy Requirements for Time-Stamping Authorities August 2003 547 6.1.2 TSA obligations towards subscribers 549 The TSA shall meet its claims as given in its terms and conditions 550 including the availability and accuracy of its service. 552 6.2 Subscriber obligations 554 The current document places no specific obligations on the subscriber 555 beyond any TSA specific requirements stated in the TSA's terms and 556 condition. 558 NOTE: It is advisable that, when obtaining a time-stamp token, the 559 subscriber verifies that the time-stamp token has been correctly signed 560 and that the private key used to sign the time-stamp token has not been 561 compromised. 563 6.3 Relying party obligations 565 The terms and conditions made available to relying parties (see section 566 7.1.2) shall include an obligation on the relying party that, when 567 relying on a time-stamp token, it shall: 569 a) verify that the time-stamp token has been correctly signed and that 570 the private key used to sign the time-stamp has not been compromised 571 until the time of the verification; 573 NOTE: During the TSU's certificate validity period, the validity of the 574 signing key can be checked using current revocation status for the 575 TSU's certificate. If the time of verification exceeds the end of the 576 validity period of the corresponding certificate, see annex C for 577 guidance. 579 b) take into account any limitations on the usage of the time-stamp 580 indicated by the time-stamp policy; 582 c) take into account any other precautions prescribed in agreements or 583 elsewhere. 585 6.4 Liability 587 The present document does not specify any requirement on liability. In 588 particular, it should be noticed that a TSA may disclaim or limit any 589 liability unless otherwise stipulated by the applicable law. 591 7 Requirements on TSA practices 593 The TSA shall implement the controls that meet the following 594 requirements. 596 These policy requirements are not meant to imply any restrictions on 597 charging for TSA services. 599 Policy Requirements for Time-Stamping Authorities August 2003 601 The requirements are indicated in terms of the security objectives 602 followed by more specific requirements for controls to meet those 603 objectives where considered necessary to provide the necessary 604 confidence that those objective will be met. 606 NOTE: The details of controls required to meet an objective is a 607 balance between achieving the necessary confidence whilst minimizing 608 the restrictions on the techniques that a TSA may employ in issuing 609 time-stamp tokens. In case of section 7.4 (TSA management and 610 operation) reference is made to other more general standards which may 611 be used as a source of more detailed control requirements. Due to these 612 factors the specificity of the requirements given under a given topic 613 may vary. 615 The provision of a time-stamp token in response to a request is at the 616 discretion of the TSA depending on any service level agreements with 617 the subscriber. 619 7.1 Practice and Disclosure Statements 621 7.1.1 TSA Practice statement 623 The TSA shall ensure that it demonstrates the reliability necessary for 624 providing time-stamping services. 626 In particular: 628 a) The TSA shall have a risk assessment carried out in order to 629 evaluate business assets and threats to those assets in order to 630 determine the necessary security controls and operational procedures. 632 b) The TSA shall have a statement of the practices and procedures used 633 to address all the requirements identified in this time-stamp policy. 635 NOTE 1: This policy makes no requirement as to the structure of the TSA 636 practice statement. 638 c) The TSA's practice statement shall identify the obligations of all 639 external organizations supporting the TSA services including the 640 applicable policies and practices. 642 d) The TSA shall make available to subscribers and relying parties its 643 practice statement, and other relevant documentation, as necessary to 644 assess conformance to the time-stamp policy. 646 NOTE 2: The TSA is not generally required to make all the details of 647 its practices public. 649 e) The TSA shall disclose to all subscribers and potential relying 650 parties the terms and conditions regarding use of its time-stamping 651 services as specified in section 7.1.2. 653 f) The TSA shall have a high level management body with final authority 654 for approving the TSA practice statement. 656 Policy Requirements for Time-Stamping Authorities August 2003 658 g) The senior management of the TSA shall ensure that the practices are 659 properly implemented. 661 h) The TSA shall define a review process for the practices including 662 responsibilities for maintaining the TSA practice statement. 664 i) The TSA shall give due notice of changes it intends to make in its 665 practice statement and shall, following approval as in (f) above, make 666 the revised TSA practice statement immediately available as required 667 under (d) above. 669 7.1.2 TSA disclosure Statement 671 The TSA shall disclose to all subscribers and potential relying parties 672 the terms and conditions regarding use of its time-stamping services. 673 This statement shall at least specify for each time-stamp policy 674 supported by the TSA: 676 a) The TSA contact information. 678 b) The time-stamp policy being applied. 680 c) At least one hashing algorithm which may be used to represent the 681 datum being time-stamped. (No hash algorithm is mandated). 683 d) The expected life-time of the signature used to sign the time-stamp 684 token (depends on the hashing algorithm being used, the signature 685 algorithm being used and the private key length). 687 e) The accuracy of the time in the time-stamp tokens with respect to 688 UTC. 690 f) Any limitations on the use of the time-stamping service. 692 g) The subscriber's obligations as defined in section 6.2, if any. 694 h) The relying party's obligations as defined in section 6.3. 696 i) Information on how to verify the time-stamp token such that the 697 relying party is considered to "reasonably rely" on the time-stamp 698 token (see section 6.3) and any possible limitations on the validity 699 period. 701 j) The period of time during which TSA event logs (see section 7.4.10) 702 are retained. 704 k) The applicable legal system, including any claim to meet the 705 requirements on time-stamping services under national law. 707 l) Limitations of liability. 709 m) Procedures for complaints and dispute settlement. 711 Policy Requirements for Time-Stamping Authorities August 2003 713 n) If the TSA has been assessed to be conformant with the identified 714 time-stamp policy, and if so by which independent body. 716 NOTE 1: It is also recommended that the TSA includes in its 717 time-stamping disclosure statement availability of its service, for 718 example the expected mean time between failure of the time-stamping 719 service, the mean time to recovery following a failure and provisions 720 made for disaster recovery including back-up services; 722 This information shall be available through a durable means of 723 communication. This information shall be available in a readily 724 understandable language. It may be transmitted electronically. 726 NOTE 2: A model TSA disclosure statement which may be used as the basis 727 of such a communication is given in annex D. Alternatively this may be 728 provided as part of a subscriber / relying party agreement. These TSA 729 disclosure statement may be included in a TSA practice statement 730 provided that they are conspicuous to the reader. 732 7.2 Key management life cycle 734 7.2.1 TSA key generation 736 The TSA shall ensure that any cryptographic keys are generated in under 737 controlled circumstances. 739 In particular: 741 a) The generation of the TSU's signing key(s) shall be undertaken in a 742 physically secured environment (see section 7.4.4) by personnel in 743 trusted roles (see section 7.4.3) under, at least, dual control. The 744 personnel authorized to carry out this function shall be limited to 745 those requiring to do so under the TSA's practices. 747 b) The generation of the TSU's signing key(s) shall be carried out 748 within a cryptographic module(s) which either: 750 - meets the requirements identified in FIPS 140-1 [FIPS 140-1] 751 level 3 or higher, or 753 - meets the requirements identified in CEN Workshop Agreement 754 14167-2 [CWA 14167-2], or 756 - is a trustworthy system which is assured to EAL 4 or higher in 757 accordance to ISO 15408 [ISO 15408], or equivalent security 758 criteria. This shall be to a security target or protection 759 profile which meets the requirements of the current document, 760 based on a risk analysis and taking into account physical and 761 other non-technical security measures. 763 Policy Requirements for Time-Stamping Authorities August 2003 765 c) The TSU key generation algorithm, the resulting signing key length 766 and signature algorithm used for signing time-stamp tokens key shall be 767 recognized by any national supervisory body, or in accordance with 768 existing current state of art, as being fit for the purposes of 769 time-stamp tokens as issued by the TSA. 771 7.2.2 TSU private key protection 773 The TSA shall ensure that TSU private keys remain confidential and 774 maintain their integrity. 776 In particular: 778 a) The TSU private signing key shall be held and used within a 779 cryptographic module which: 781 - meets the requirements identified in FIPS 140-1 [FIPS 140-1] level 3 782 or higher; or 784 - meets the requirements identified in CEN Workshop Agreement 785 14167-2 [CWA 14167-2]; or 787 - is a trustworthy system which is assured to EAL 4 or higher in 788 accordance to ISO 15408 [ISO 15408], or equivalent security criteria. 789 This shall be to a security target or protection profile which meets 790 the requirements of the current document, based on a risk analysis 791 and taking into account physical and other non-technical security 792 measures. 794 NOTE: Backup of TSU private keys is deprecated in order to minimize 795 risk of key compromise. 797 b) If TSU private keys are backed up, they shall be copied, stored 798 and recovered only by personnel in trusted roles using, at least, dual 799 control in a physically secured environment. (see section 7.4.4). The 800 personnel authorized to carry out this function shall be limited to 801 those requiring to do so under the TSA's practices. 803 c) Any backup copies of the TSU private signing keys shall be protected 804 to ensure its confidentiality by the cryptographic module before being 805 stored outside that device. 807 7.2.3 TSU public key Distribution 809 The TSA shall ensure that the integrity and authenticity of the TSU 810 signature verification (public) keys and any associated parameters are 811 maintained during its distribution to relying parties. 813 In particular: 815 a) TSU signature verification (public) keys shall be made available to 816 relying parties in a public key certificate. 818 Policy Requirements for Time-Stamping Authorities August 2003 820 NOTE: For example, TSU's certificates may be issued by a certification 821 authority operated by the same organization as the TSA, or issued by 822 another authority. 824 b) The TSU's signature verification (public) key certificate shall be 825 issued by a certification authority operating under a certificate 826 policy which provides a level of security equivalent to, or higher 827 than, this time-stamping policy. 829 7.2.4 Rekeying TSU's Key 831 The life-time of TSU's certificate shall be not longer than the period 832 of time that the chosen algorithm and key length is recognized as being 833 fit for purpose (see section 7.2.1c)). 835 NOTE 1: The following additional considerations apply when limiting 836 that lifetime: 838 - Section 7.4.10 requires that records concerning time-stamping 839 services shall be held for a period of time as appropriate for at 840 least 1 year after the expiration of the validity of the TSU's 841 signing keys. The longer the validity period of the TSU certificates 842 will be, the longer the size of the records to be kept will be. 844 - Should a TSU private key be compromised, then the longer the 845 life-time, the more affected time-stamp tokens there will be. 847 NOTE 2: TSU key compromise does not only depend on the characteristics 848 of the cryptographic module being used but also on the procedures being 849 used at system initialization and key export (when that function is 850 supported). 852 7.2.5 End of TSU key life cycle 854 The TSA shall ensure that TSU private signing keys are not used beyond 855 the end of their life cycle. 857 In particular: 859 a) Operational or technical procedures shall be in place to ensure that 860 a new key is put in place when a TSU's key expires. 862 b) The TSU private signing keys, or any key part, including any copies 863 shall be destroyed such that the private keys cannot be retrieved. 865 c) The TST generation system SHALL reject any attempt to issue TSTs if 866 the signing private key has expired. 868 Policy Requirements for Time-Stamping Authorities August 2003 870 7.2.6 Life cycle management of the cryptographic module used to sign 871 time-stamps 873 The TSA shall ensure the security of cryptographic hardware throughout 874 its lifecycle. 876 In particular the TSA shall ensure that: 878 a) Time-stamp token signing cryptographic hardware is not tampered with 879 during shipment; 881 b) Time-stamp token signing cryptographic hardware is not tampered with 882 while stored; 884 c) Installation, activation and duplication of TSU's signing keys in 885 cryptographic hardware shall be done only by personnel in trusted roles 886 using, at least, dual control in a physically secured environment. 887 (see section 7.4.4); 889 d) Time-stamp token signing cryptographic hardware is functioning 890 correctly; and 892 e) TSU private signing keys stored on TSU cryptographic module are 893 erased upon device retirement. 895 7.3 Time-stamping 897 7.3.1 Time-stamp token 899 The TSA shall ensure that time-stamp tokens are issued securely and 900 include the correct time. 902 In particular: 904 a) The time-stamp token shall include an identifier for the time-stamp 905 policy; 907 b) Each time-stamp token shall have a unique identifier; 909 c) The time values the TSU uses in the time-stamp token shall be 910 traceable to at least one of the real time values distributed by a 911 UTC(k) laboratory. 913 NOTE 1: The Bureau International des Poids et Mesures (BIPM) computes 914 UTC on the basis of its local representations UTC(k) from a large 915 ensemble of atomic clocks in national metrology institutes and national 916 astronomical observatories round the world. The BIPM disseminates UTC 917 through its monthly Circular T [list 1]. This is available on the BIPM 918 website (www.bipm.org) and it officially identifies all those 919 institutes having recognized UTC(k) time scales. 921 Policy Requirements for Time-Stamping Authorities August 2003 923 d) The time included in the time-stamp token shall be synchronized with 924 UTC within the accuracy defined in this policy and, if present, within 925 the accuracy defined in the time-stamp token itself; 927 e) If the time-stamp provider's clock is detected (see section 7.3.2c)) 928 as being out of the stated accuracy (see section 7.1.2e)) then 929 time-stamp tokens shall not be issued. 931 f) The time-stamp token shall include a representation (e.g. hash 932 value) of the datum being time-stamped as provided by the requestor; 934 g) The time-stamp token shall be signed using a key generated 935 exclusively for this purpose. 937 NOTE 2: A protocol for a time-stamp token is defined in RFC 3631 and 938 profiled in TS 101 861 [TS 101861]. 940 NOTE 3: In the case of a number of requests at approximately the same 941 time, the ordering of the time within the accuracy of the TSU clock is 942 not mandated. 944 h) The time-stamp token shall include: 946 - where applicable, an identifier for the country in which the TSA 947 is established; 949 - an identifier for the TSA; 951 - an identifier for the unit which issues the time-stamps. 953 7.3.2 Clock Synchronization with UTC 955 The TSA shall ensure that its clock is synchronized with UTC within the 956 declared accuracy. 958 In particular: 960 a) The calibration of the TSU clocks shall be maintained such that the 961 clocks shall not be expected to drift outside the declared accuracy. 963 b) The TSU clocks shall be protected against threats which could result 964 in an undetected change to the clock that takes it outside its 965 calibration. 967 NOTE 1: Threats may include tampering by unauthorized personnel, radio 968 or electrical shocks. 970 c) The TSA shall ensure that, if the time that would be indicated in a 971 time-stamp token drifts or jumps out of synchronization with UTC, this 972 will be detected (see also 7.3.1e)). 974 NOTE 2: Relying parties are required to be informed of such events 975 (see section 7.4.8). 977 Policy Requirements for Time-Stamping Authorities August 2003 979 d) The TSA shall ensure that clock synchronization is maintained when a 980 leap second occurs as notified by the appropriate body. The change to 981 take account of the leap second shall occur during the last minute of 982 the day when the leap second is scheduled to occur. A record shall be 983 maintained of the exact time (within the declared accuracy) when this 984 change occurred. See annex A for more details. 986 NOTE 3: A leap second is an adjustment to UTC by skipping or adding an 987 extra second on the last second of a UTC month. First preference is 988 given to the end of December and June, and second preference is given 989 to the end of March and September. 991 7.4 TSA management and operation 993 7.4.1 Security management 995 The TSA shall ensure that administrative and management procedures are 996 applied which are adequate and correspond to recognized best practice. 998 In particular: 1000 TSA General 1002 a) The TSA shall retain responsibility for all aspects of the provision 1003 of time-stamping services within the scope of this time-stamp policy, 1004 whether or not functions are outsourced to subcontractors. 1005 Responsibilities of third parties shall be clearly defined by the TSA 1006 and appropriate arrangements made to ensure that third parties are 1007 bound to implement any controls required by the TSA. The TSA shall 1008 retain responsibility for the disclosure of relevant practices of all 1009 parties. 1011 b) The TSA management shall provide direction on information security 1012 through a suitable high level steering forum that is responsible for 1013 defining the TSA's information security policy. The TSA shall ensure 1014 publication and communication of this policy to all employees who are 1015 impacted by it. 1017 c) The information security infrastructure necessary to manage the 1018 security within the TSA shall be maintained at all times. Any changes 1019 that will impact on the level of security provided shall be approved by 1020 the TSA management forum. 1022 NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on information 1023 security management including information security infrastructure, 1024 management information security forum and information security 1025 policies. 1027 d) The security controls and operating procedures for TSA facilities, 1028 systems and information assets providing the time-stamping services 1029 shall be documented, implemented and maintained. 1031 Policy Requirements for Time-Stamping Authorities August 2003 1033 NOTE 2: The present documentation (commonly called a system security 1034 policy or manual) should identify all relevant targets, objects and 1035 potential threats related to the services provided and the safeguards 1036 required to avoid or limit the effects of those threats, consistent 1037 with the Risk Assessment required under section 7.1.1a). It should 1038 describe the rules, directives and procedures regarding how the 1039 specified services and the associated security assurance are granted in 1040 addition to stating policy on incidents and disasters. 1042 e) TSA shall ensure that the security of information is maintained when 1043 the responsibility for TSA functions has been outsourced to another 1044 organization or entity. 1046 7.4.2 Asset classification and management 1048 The TSA shall ensure that its information and other assets receive an 1049 appropriate level of protection. 1051 In particular: 1053 - The TSA shall maintain an inventory of all assets and shall assign a 1054 classification for the protection requirements to those assets 1055 consistent with the risk analysis. 1057 7.4.3 Personnel security 1059 The TSA shall ensure that personnel and hiring practices enhance and 1060 support the trustworthiness of the TSA's operations. 1062 In particular (TSA general): 1064 a) The TSA shall employ personnel which possess the expert knowledge, 1065 experience and qualifications necessary for the offered services and as 1066 appropriate to the job function. 1068 NOTE 1: TSA personnel should be able to fulfil the requirement of 1069 "expert knowledge, experience and qualifications" through formal 1070 training and credentials, actual experience, or a combination of the 1071 two. 1073 NOTE 2: Personnel employed by a TSA include individual personnel 1074 contractually engaged in performing functions in support of the TSA's 1075 time-stamping services. Personnel who may be involved in monitoring the 1076 TSA services need not be TSA personnel. 1078 b) Security roles and responsibilities, as specified in the TSA's 1079 security policy, shall be documented in job descriptions. Trusted 1080 roles, on which the security of the TSA's operation is dependent, shall 1081 be clearly identified. 1083 Policy Requirements for Time-Stamping Authorities August 2003 1085 c) TSA personnel (both temporary and permanent) shall have job 1086 descriptions defined from the view point of separation of duties and 1087 least privilege, determining position sensitivity based on the duties 1088 and access levels, background screening and employee training and 1089 awareness. Where appropriate, these shall differentiate between general 1090 functions and TSA specific functions. These should include skills and 1091 experience requirements. 1093 d) Personnel shall exercise administrative and management procedures 1094 and processes that are in line with the TSA's information security 1095 management procedures (see section 7.4.1). 1097 NOTE 3: See ISO/IEC 17799 [ISO 17799] for guidance. 1099 The following additional controls shall be applied to time-stamping 1100 management: 1102 e) Managerial personnel shall be employed who possess: 1104 - knowledge of time-stamping technology; and 1105 - knowledge of digital signature technology; and 1106 - knowledge of mechanisms for calibration or synchronization the 1107 TSU clocks with UTC; and 1108 - familiarity with security procedures for personnel with security 1109 responsibilities; and 1110 - experience with information security and risk assessment. 1112 f) All TSA personnel in trusted roles shall be free from conflict of 1113 interest that might prejudice the impartiality of the TSA operations. 1115 g) Trusted roles include roles that involve the following 1116 responsibilities: 1118 - Security Officers: Overall responsibility for administering the 1119 implementation of the security practices. 1121 - System Administrators: Authorized to install, configure and 1122 maintain the TSA trustworthy systems for time-stamping management. 1124 - System Operators: Responsible for operating the TSA trustworthy 1125 systems on a day-to-day basis. Authorized to perform system backup 1126 and recovery. 1128 - System Auditors: Authorized to view archives and audit logs of 1129 the TSA trustworthy systems. 1131 h) TSA personnel shall be formally appointed to trusted roles by senior 1132 management responsible for security. 1134 i) The TSA shall not appoint to trusted roles or management any person 1135 who is known to have a conviction for a serious crime or other offence 1136 which affects his/her suitability for the position. Personnel shall not 1137 have access to the trusted functions until any necessary checks are 1138 completed. 1140 Policy Requirements for Time-Stamping Authorities August 2003 1142 NOTE 4: In some countries it may not be possible for TSA to obtain 1143 information on past convictions without the collaboration of the 1144 candidate employee. 1146 7.4.4 Physical and environmental security 1148 The TSA shall ensure that physical access to critical services is 1149 controlled and physical risks to its assets minimized. 1151 In particular (general): 1153 a) For both the time-stamping provision and the time-stamping 1154 management: 1156 - physical access to facilities concerned with time-stamping services 1157 shall be limited to properly authorized individuals; 1158 - controls shall be implemented to avoid loss, damage or compromise of 1159 assets and interruption to business activities; and 1160 - controls shall be implemented to avoid compromise or theft of 1161 information and information processing facilities. 1163 b) Access controls shall be applied to the cryptographic module to meet 1164 the requirements of security of cryptographic modules as identified in 1165 clauses 7.2.1 and 7.2.2. 1167 c) The following additional controls shall be applied to time-stamping 1168 management: 1170 - The time-stamping management facilities shall be operated in an 1171 environment which physically protects the services from compromise 1172 through unauthorized access to systems or data. 1174 - Physical protection shall be achieved through the creation of 1175 clearly defined security perimeters (i.e. physical barriers) around 1176 the time-stamping management. Any parts of the premises shared with 1177 other organizations shall be outside this perimeter. 1179 - Physical and environmental security controls shall be implemented to 1180 protect the facility that houses system resources, the system 1181 resources themselves, and the facilities used to support their 1182 operation. The TSA's physical and environmental security policy for 1183 systems concerned with time-stamping management shall address as a 1184 minimum the physical access control, natural disaster protection, 1185 fire safety factors, failure of supporting utilities (e.g. power, 1186 telecommunications), structure collapse, plumbing leaks, protection 1187 against theft, breaking and entering, and disaster recovery. 1189 - Controls shall be implemented to protect against equipment, 1190 information, media and software relating to the time-stamping 1191 services being taken off-site without authorization. 1193 NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on physical and 1194 environmental security. 1196 Policy Requirements for Time-Stamping Authorities August 2003 1198 NOTE 2: Other functions may be supported within the same secured area 1199 provided that the access is limited to authorized personnel. 1201 7.4.5 Operations management 1203 The TSA shall ensure that the TSA system components are secure and 1204 correctly operated, with minimal risk of failure: 1206 In particular (general): 1208 a) The integrity of TSA system components and information shall be 1209 protected against viruses, malicious and unauthorized software. 1211 b) Incident reporting and response procedures shall be employed in such 1212 a way that damage from security incidents and malfunctions shall be 1213 minimized. 1215 c) Media used within the TSA trustworthy systems shall be securely 1216 handled to protect media from damage, theft, unauthorized access and 1217 obsolescence. 1219 NOTE 1: Every member of personnel with management responsibilities is 1220 responsible for planning and effectively implementing the time-stamp 1221 policy and associated practices as documented in the TSA practice 1222 statement. 1224 d) Procedures shall be established and implemented for all trusted and 1225 administrative roles that impact on the provision of time-stamping 1226 services. 1228 Media handling and security 1230 e) All media shall be handled securely in accordance with requirements 1231 of the information classification scheme (see section 7.4.2). Media 1232 containing sensitive data shall be securely disposed of when no longer 1233 required. 1235 System Planning 1237 f) Capacity demands shall be monitored and projections of future 1238 capacity requirements made to ensure that adequate processing power and 1239 storage are available. 1241 Incident reporting and response 1243 g) The TSA shall act in a timely and coordinated manner in order to 1244 respond quickly to incidents and to limit the impact of breaches of 1245 security. All incidents shall be reported as soon as possible after the 1246 incident. 1248 The following additional controls shall be applied to time-stamping 1249 management: 1251 Policy Requirements for Time-Stamping Authorities August 2003 1253 Operations procedures and responsibilities 1255 h) TSA security operations shall be separated from other operations. 1257 NOTE 2: TSA security operations' responsibilities include: 1258 - operational procedures and responsibilities; 1259 - secure systems planning and acceptance; 1260 - protection from malicious software; 1261 - housekeeping; 1262 - network management; 1263 - active monitoring of audit journals, event analysis and follow-up; 1264 - media handling and security; 1265 - data and software exchange. 1267 These operations shall be managed by TSA trusted personnel, but, may 1268 actually be performed by, non-specialist, operational personnel (under 1269 supervision), as defined within the appropriate security policy, and, 1270 roles and responsibility documents. 1272 7.4.6 System Access Management 1274 The TSA shall ensure that TSA system access is limited to properly 1275 authorized individuals. 1277 In particular (general): 1279 a) Controls (e.g., firewalls) shall be implemented to protect the TSA's 1280 internal network domains from unauthorized access including access by 1281 subscribers and third parties. 1283 NOTE 1: Firewalls should also be configured to prevent all protocols 1284 and accesses not required for the operation of the TSA. 1286 b) The TSA shall ensure effective administration of user (this includes 1287 operators, administrators and auditors) access to maintain system 1288 security, including user account management, auditing and timely 1289 modification or removal of access. 1291 c) The TSA shall ensure that access to information and application 1292 system functions is restricted in accordance with the access control 1293 policy and that the TSA system provides sufficient computer security 1294 controls for the separation of trusted roles identified in TSA's 1295 practices, including the separation of security administrator and 1296 operation functions. Particularly, use of system utility programs is 1297 restricted and tightly controlled. 1299 d) TSA personnel shall be properly identified and authenticated before 1300 using critical applications related to time-stamping. 1302 e) TSA personnel shall be accountable for their activities, for example 1303 by retaining event logs (see section 7.4.10). 1305 Policy Requirements for Time-Stamping Authorities August 2003 1307 The following additional controls shall be applied to time-stamping 1308 management: 1310 f) The TSA shall ensure that local network components (e.g. routers) 1311 are kept in a physically secure environment and that their 1312 configurations are periodically audited for compliance with the 1313 requirements specified by the TSA. 1315 g) Continuous monitoring and alarm facilities shall be provided to 1316 enable the TSA to detect, register and react in a timely manner upon 1317 any unauthorized and/or irregular attempts to access its resources. 1319 NOTE 2: This may use, for example, an intrusion detection system, 1320 access control monitoring and alarm facilities. 1322 7.4.7 Trustworthy Systems Deployment and Maintenance 1324 The TSA shall use trustworthy systems and products that are protected 1325 against modification. 1327 NOTE: The risk analysis carried out on the TSA's services (see section 1328 7.1.1) should identify its critical services requiring trustworthy 1329 systems and the levels of assurance required. 1331 In particular: 1333 a) An analysis of security requirements shall be carried out at the 1334 design and requirements specification stage of any systems development 1335 project undertaken by the TSA or on behalf of the TSA to ensure that 1336 security is built into IT systems. 1338 b) Change control procedures shall be applied for releases, 1339 modifications and emergency software fixes of any operational software. 1341 7.4.8 Compromise of TSA Services 1343 The TSA shall ensure in the case of events which affect the security of 1344 the TSA's services, including compromise of TSU's private signing keys 1345 or detected loss of calibration, that relevant information is made 1346 available to subscribers and relying parties. 1348 In particular: 1350 a) The TSA's disaster recovery plan shall address the compromise or 1351 suspected compromise of TSU's private signing keys or loss of 1352 calibration of a TSU clock, which may have affected time-stamp tokens 1353 which have been issued. 1355 b) In the case of a compromise, or suspected compromise or loss of 1356 calibration the TSA shall make available to all subscribers and relying 1357 parties a description of compromise that occurred. 1359 Policy Requirements for Time-Stamping Authorities August 2003 1361 c) In the case of compromise to a TSU's operation (e.g. TSU key 1362 compromise), suspected compromise or loss of calibration the TSU shall 1363 not issue time-stamp tokens until steps are taken to recover from the 1364 compromise 1366 d) In case of major compromise of the TSA's operation or loss of 1367 calibration, wherever possible, the TSA shall make available to all 1368 subscribers and relying parties information which may be used to 1369 identify the time-stamp tokens which may have been affected, unless 1370 this breaches the privacy of the TSAs users or the security of the TSA 1371 services. 1373 NOTE: In case the private key does become compromised, an audit trail 1374 of all tokens generated by the TSA may provide a means to discriminate 1375 between genuine and false backdated tokens. Two time-stamp tokens from 1376 two different TSAs may be another way to address this issue. 1378 7.4.9 TSA termination 1380 The TSA shall ensure that potential disruptions to subscribers and 1381 relying parties are minimized as a result of the cessation of the TSA's 1382 time-stamping services, and in particular ensure continued maintenance 1383 of information required to verify the correctness of time-stamp tokens. 1385 In particular: 1387 a) Before the TSA terminates its time-stamping services the following 1388 procedures shall be executed as a minimum: 1390 - the TSA shall make available to all subscribers and relying 1391 parties information concerning its termination; 1393 - TSA shall terminate authorization of all subcontractors to act on 1394 behalf of the TSA in carrying out any functions relating to the 1395 process of issuing time-stamp tokens; 1397 - the TSA shall transfer obligations to a reliable party for 1398 maintaining event log and audit archives (see section 7.4.10) 1399 necessary to demonstrate the correct operation of the TSA for a 1400 reasonable period; 1402 - the TSA shall maintain or transfer to a reliable party its 1403 obligations to make available its public key or its certificates to 1404 relying parties for a reasonable period; 1406 - TSU private keys, including backup copies, shall be destroyed in 1407 a manner such that the private keys cannot be retrieved. 1409 b) The TSA shall have an arrangement to cover the costs to fulfil these 1410 minimum requirements in case the TSA becomes bankrupt or for other 1411 reasons is unable to cover the costs by itself. 1413 Policy Requirements for Time-Stamping Authorities August 2003 1415 c) The TSA shall state in its practices the provisions made for 1416 termination of service. This shall include: 1418 - notification of affected entities; 1419 - transferring the TSA obligations to other parties. 1421 d) The TSA shall take steps to have the TSU's certificates revoked. 1423 7.4.10 Compliance with Legal Requirements 1425 The TSA shall ensure compliance with legal requirements. 1427 In particular: 1429 a) The TSA shall ensure that the requirements of the European data 1430 protection Directive [Dir 95/46/EC], as implemented through national 1431 legislation, are met. 1433 b) Appropriate technical and organizational measures shall be taken 1434 against unauthorized or unlawful processing of personal data and 1435 against accidental loss or destruction of, or damage to, personal data. 1437 c) The information contributed by users to the TSA shall be completely 1438 protected from disclosure unless with their agreement or by court order 1439 or other legal requirement. 1441 7.4.11 Recording of Information Concerning Operation of Time-stamping 1442 Services 1444 The TSA shall ensure that all relevant information concerning the 1445 operation of time-stamping services is recorded for a defined period of 1446 time, in particular for the purpose of providing evidence for the 1447 purposes of legal proceedings. 1449 In particular: 1451 General 1453 a) The specific events and data to be logged shall be documented by the 1454 TSA. 1456 b) The confidentiality and integrity of current and archived records 1457 concerning operation of time-stamping services shall be maintained. 1459 c) Records concerning the operation of time-stamping services shall be 1460 completely and confidentially archived in accordance with disclosed 1461 business practices. 1463 d) Records concerning the operation of time-stamping services shall be 1464 made available if required for the purposes of providing evidence of 1465 the correct operation of the time-stamping services for the purpose of 1466 legal proceedings. 1468 Policy Requirements for Time-Stamping Authorities August 2003 1470 e) The precise time of significant TSA environmental, key management 1471 and clock synchronization events shall be recorded. 1473 f) Records concerning time-stamping services shall be held for a period 1474 of time after the expiration of the validity of the TSU's signing keys 1475 as appropriate for providing necessary legal evidence and as notified 1476 in the TSA disclosure statement (see section 7.1.2). 1478 g) The events shall be logged in a way that they cannot be easily 1479 deleted or destroyed (except if reliably transferred to long-term 1480 media) within the period of time that they are required to be held. 1482 NOTE: This may be achieved, for example, through the use of write-only 1483 media, a record of each removable media used and the use of off-site 1484 backup. 1486 h) Any information recorded about subscribers shall be kept 1487 confidential except as where agreement is obtained from the subscriber 1488 for its wider publication. 1490 TSU key management 1492 i) Records concerning all events relating to the life-cycle of TSU keys 1493 shall be logged. 1495 j) Records concerning all events relating to the life-cycle of TSU 1496 certificates (if appropriate) shall be logged. 1497 Clock Synchronization 1499 k) Records concerning all events relating to synchronization of a 1500 TSU's clock to UTC shall be logged. This shall include information 1501 concerning normal re-calibration or synchronization of clocks use in 1502 time-stamping. 1504 l) Records concerning all events relating to detection of loss of 1505 synchronization shall be logged. 1507 7.5 Organizational 1509 The TSA shall ensure that its organization is reliable. 1511 In particular that: 1513 a) Policies and procedures under which the TSA operates shall be 1514 non-discriminatory. 1516 b) The TSA shall make its services accessible to all applicants whose 1517 activities fall within its declared field of operation and that agree 1518 to abide by their obligations as specified in the TSA disclosure 1519 statement. 1521 c) The TSA is a legal entity according to national law. 1523 Policy Requirements for Time-Stamping Authorities August 2003 1525 d) The TSA has a system or systems for quality and information security 1526 management appropriate for the time-stamping services it is providing. 1528 e) The TSA has adequate arrangements to cover liabilities arising from 1529 its operations and/or activities. 1531 f) It has the financial stability and resources required to operate in 1532 conformity with this policy. 1534 NOTE 1: This includes requirements for TSA termination identified in 1535 section 7.4.9. 1537 g) It employs a sufficient number of personnel having the necessary 1538 education, training, technical knowledge and experience relating to the 1539 type, range and volume of work necessary to provide time-stamping 1540 services. 1542 NOTE 2: Personnel employed by a TSA include individual personnel 1543 contractually engaged in performing functions in support of the TSA's 1544 time-stamping services. Personnel who may be involved only in 1545 monitoring the TSA services need not be TSA personnel. 1547 h) It has policies and procedures for the resolution of complaints and 1548 disputes received from customers or other parties about the 1549 provisioning of the time-stamping services or any other related 1550 matters. 1552 i) It has a properly documented agreement and contractual relationship 1553 in place where the provisioning of services involves subcontracting, 1554 outsourcing or other third party arrangements. 1556 8. Security Considerations 1558 When verifying time-stamp tokens it is necessary for the verifier to 1559 ensure that the TSU certificate is trusted and not revoked. This means 1560 that the security is dependent upon the security of the CA that has 1561 issued the TSU certificate for both issuing the certificate and 1562 providing accurate revocation status information for that certificate. 1564 When a time-stamp is verified as valid at a given point of time, this 1565 does not mean that it will necessarily remain valid later on. Every 1566 time, a time-stamp token is verified during the validity period of 1567 the TSU certificate, it must be verified again against the current 1568 revocation status information, since in case of compromise of a TSU 1569 private key, all the time-stamp tokens generated by that TSU become 1570 invalid. Annex C provides guidance about the long term verification 1571 of time-stamp tokens. 1573 In applying time-stamping to applications, consideration also needs 1574 to be given to the security of the application. In particular, when 1575 applying time-stamps it is necessary to ensure that the integrity of 1576 data is maintained before the time-stamp is applied. The requester 1577 ought to really make sure that the hash value included in the 1578 time-stamp token matches with the hash of the data. 1580 Policy Requirements for Time-Stamping Authorities August 2003 1582 9. Acknowledgments 1584 The development of this document was supported by ETSI and the 1585 European Commission. Special thanks are due to Franco Ruggieri 1586 for his valuable inputs. 1588 10. References 1590 10.1. Normative References 1592 [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate 1593 Requirement Levels", BCP 14, RFC 2119, March 1997. 1595 [TF.460-5] ITU-R Recommendation TF.460-5 (1997): 1596 Standard-frequency and time-signal emissions. 1598 [TF.536-1] ITU-R Recommendation TF.536-1 (1998): 1599 Time-scale notations. 1601 [CWA 14167-2] CEN Workshop Agreement 14167-2: Cryptographic Module 1602 for CSP Signing Operations - Protection Profile 1603 (MCSO-PP). 1605 [FIPS 140-1] FIPS PUB 140-1 (1994): Security Requirements for 1606 Cryptographic Modules. 1608 [ISO 15408] ISO/IEC 15408 (1999) (parts 1 to 3): 1609 Information technology - Security techniques and 1610 Evaluation criteria for IT security. 1612 10.2. Non-normative References 1614 [CWA 14172] CEN Workshop Agreement 14172: EESSI Conformity 1615 Assessment Guidance. 1617 [Dir 95/46/EC] Directive 95/46/EC of the European Parliament and 1618 of the Council of 24 October 1995 on the protection 1619 of individuals with regard to the processing of 1620 personal data and on the free movement of such data. 1622 [Dir 99/93/EC] Directive 1999/93/EC of the European Parliament and 1623 of the Council of 13 December 1999 on a Community 1624 framework for electronic signatures. 1626 [ISO 17799] ISO/IEC 17799: Information technology 1627 Code of practice for information security management 1629 [RFC 3126] D. Pinkas, J. Ross, N. Pope. "Electronic Signature 1630 Formats for long term electronic signatures". 1631 RFC 3126. September 2001. 1633 [RFC 3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, 1634 "Internet X.509 Public Key Infrastructure Time-Stamp 1635 Protocol (TSP)", RFC 3161, August 2001. 1637 Policy Requirements for Time-Stamping Authorities August 2003 1639 [TS 101733] ETSI Technical Standard TS 101 733 V.1.2.2 (2000-12) 1640 Electronic Signature Formats. Note: copies of ETSI 1641 TS 101 733 can be freely downloaded from the ETSI web 1642 site www.etsi.org. 1644 [TS 101861] ETSI Technical Standard TS 101 861 V1.2.1. (2001-11). 1645 Time stamping profile. Note: copies of ETSI TS 101 861 1646 can be freely downloaded from the ETSI web site 1647 www.etsi.org. 1649 [TS 102023] ETSI Technical Standard TS 102 023. 1650 Policy requirements for Time-Stamping Authorities. 1651 Note: copies of ETSI TS 102 023 can be freely 1652 downloaded from the ETSI web site www.etsi.org. 1654 [X.208] CCITT Recommendation X.208: Specification of Abstract 1655 Syntax Notation One (ASN.1), 1988. 1657 11. Authors' addresses 1659 Denis Pinkas 1660 Bull 1661 Rue Jean Jaures, 1662 78340 Les Clayes CEDEX 1663 FRANCE 1665 EMail: Denis.Pinkas@bull.net 1667 Nick Pope 1668 Security & Standards 1669 192 Moulsham Street 1670 Chelmsford, Essex 1671 CM2 0LG 1672 United Kingdom 1674 EMail: pope@secstan.com 1676 John Ross 1677 Security & Standards 1678 192 Moulsham Street 1679 Chelmsford, Essex 1680 CM2 0LG 1681 United Kingdom 1683 EMail: ross@secstan.com 1685 Policy Requirements for Time-Stamping Authorities August 2003 1687 This Informational RFC has been produced in ETSI ESI. 1689 ETSI 1690 F-06921 Sophia Antipolis, Cedex - FRANCE 1691 650 Route des Lucioles - Sophia Antipolis 1692 Valbonne - France 1693 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 1694 secretariat@etsi.fr 1695 http://www.etsi.org 1697 Contact Point 1699 Gerry Mc Auley 1700 ETSI 1701 650 Route des Lucioles 1702 F-06921 Sophia Antipolis, Cedex 1703 FRANCE 1705 EMail: Gerry.McAuley@etsi.fr 1707 Policy Requirements for Time-Stamping Authorities August 2003 1709 Annex A (informative): Coordinated Universal Time 1711 Coordinated Universal Time (UTC) is the international time standard 1712 that became effective on January 1, 1972. UTC has superseded Greenwich 1713 Mean Time (GMT), but in practice they are never more than 1 second 1714 different. Hence many people continue to refer to GMT when in fact they 1715 operate to UTC. 1717 Zero (0) hours UTC is midnight in Greenwich, England, which lies on the 1718 zero longitudinal meridian. Universal time is based on a 24 hour clock, 1719 therefore, afternoon hours such as 4 pm UTC are expressed as 16:00 UTC 1720 (sixteen hours, zero minutes). 1722 International Atomic Time (TAI) is calculated by the Bureau 1723 International des Poids et Mesures (BIPM) from the readings of more 1724 than 200 atomic clocks located in metrology institutes and 1725 observatories in more than 30 countries around the world. Information 1726 on TAI is made available every month in the BIPM Circular T 1727 (ftp://62.161.69.5/pub/tai/publication). It is that TAI does not lose 1728 or gain with respect to an imaginary perfect clock by more than about 1729 one tenth of a microsecond (0.0000001 second) per year. 1731 Coordinated Universal Time (UTC): Time scale, based on the second, as 1732 defined and recommended by the International Telecommunications Radio 1733 Committee (ITU-R), and maintained by the Bureau International des Poids 1734 et Mesures (BIPM). The maintenance by BIPM includes cooperation among 1735 various national laboratories around the world. The full definition of 1736 UTC is contained in ITU-R Recommendation TF.460-4. 1738 Atomic Time, with the unit of duration the Systeme International (SI) 1739 second defined as the duration of 9 192 631 770 cycles of radiation, 1740 corresponds to the transition between two hyperfine levels of the 1741 ground state of caesium 133. TAI is the International Atomic Time 1742 scale, a statistical timescale based on a large number of atomic 1743 clocks. 1745 Universal Time (UT) is counted from 0 hours at midnight, with unit of 1746 duration the mean solar day, defined to be as uniform as possible 1747 despite variations in the rotation of the Earth. 1749 - UT0 is the rotational time of a particular place of observation. 1750 It is observed as the diurnal motion of stars or extraterrestrial 1751 radio sources. 1753 - UT1 is computed by correcting UT0 for the effect of polar motion 1754 on the longitude of the observing site. It varies from uniformity 1755 because of the irregularities in the Earth's rotation. 1756 UT1, is based on the somewhat irregular rotation of the Earth. 1757 Rotational irregularities usually result in a net decrease in the 1758 Earth's average rotational velocity, and ensuing lags of UT1 with 1759 respect to UTC. 1761 Policy Requirements for Time-Stamping Authorities August 2003 1763 Coordinated Universal Time (UTC) is the basis for international 1764 time-keeping and follows TAI exactly except for an integral number of 1765 seconds, 32 in year 2001. These leap seconds are inserted on the advice 1766 of the International Earth Rotation Service (IERS) 1767 (http://hpiers.obspm.fr/) to ensure that, having taken into account 1768 irregularities, the Sun is overhead within 0,9 seconds of 12:00:00 UTC 1769 on the meridian of Greenwich. UTC is thus the modern successor of 1770 Greenwich Mean Time, GMT, which was used when the unit of time was the 1771 mean solar day. 1773 Adjustments to the atomic, i.e., UTC, time scale consist of an 1774 occasional addition or deletion of one full second, which is called a 1775 leap second. Twice yearly, during the last minute of the day of June 30 1776 and December 31, Universal Time, adjustments may be made to ensure that 1777 the accumulated difference between UTC and UT1 will not exceed 0,9 s 1778 before the next scheduled adjustment. Historically, adjustments, when 1779 necessary, have usually consisted of adding an extra second to the UTC 1780 time scale in order to allow the rotation of the Earth to "catch up." 1781 Therefore, the last minute of the UTC time scale, on the day when an 1782 adjustment is made, will have 61 seconds. Adjustments dates are 1783 typically announced several months in advance in IERS Bulletin C: 1784 ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat. 1786 Coordinated Universal Time (UTC) differs thus from TAI by an integral 1787 number of seconds. UTC is kept within 0,9 s of UT1 by the introduction 1788 of one-second steps to UTC, the "leap second." To date these steps have 1789 always been positive. 1791 Policy Requirements for Time-Stamping Authorities August 2003 1793 Annex B (informative): Possible for Implementation Architectures and 1794 Time-stamping Services 1796 B.1 Managed Time-stamping Service 1798 Some organizations may be willing to host one or more Time-Stamping 1799 Units in order to take advantage of both the proximity and the quality 1800 of the Time-Stamping Service, without being responsible for the 1801 installation, operation and management of these Time-Stamping 1802 Units. 1804 This can be achieved by using units that are installed in the premises 1805 from the hosting organization and then remotely managed by a 1806 Time-Stamping Authority that takes the overall responsibility of the 1807 quality of the service delivered to the hosting organization. 1809 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1810 + + 1811 + Time-Stamping Authority + 1812 + + 1813 + + 1814 +_____________ _____________ _____________+ 1815 |+ __________ | | | | __________ +| 1816 |+| | | | Time - | | | |+| 1817 |+| Time - |<-------------| Stamping |------------->| Time - |+| 1818 |+| Stamping | | Install. | Management | Install. | | Stamping |+| 1819 |+| Unit | | Management | | Management | | Unit |+| 1820 |+|__________| | |_____________| | |__________|+| 1821 |+ | | +| 1822 |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 1823 | Hosting | | Hosting | 1824 | Organization | | Organization | 1825 |______________| |______________| 1827 Figure B.1: Managed Time-stamping Service 1829 The requirements for time-stamping services described in the current 1830 document includes requirements on both the time-stamping management and 1831 for the operation of the unit which issues the time-stamp tokens. The 1832 TSA, as identified in the time-stamp token, has the responsibility to 1833 ensure that these requirements are met (for example through contractual 1834 obligations). 1836 It should be clear that the hosting organization will generally want to 1837 be able to monitor the use of the service and, at a minimum, know 1838 whether the service is working or not and even be able to measure the 1839 performances of the service, e.g. the number of time-stamps generated 1840 during some period of time. Such monitoring can be considered to be 1841 outside of TSA's time-stamping authority. 1843 Policy Requirements for Time-Stamping Authorities August 2003 1845 Therefore the description of the management operation described in the 1846 main body of the document is not limitative. Monitoring operations, if 1847 performed directly on the unit, may be permitted by the Time-Stamping 1848 service provider. 1850 B.2 Selective Alternative Quality 1852 Some relying parties may be willing to take advantage of particular 1853 characteristics from a time-stamp token such as a specific signature 1854 algorithm and/or key length or a specific accuracy for the time 1855 contained in the time stamp token. These parameters can be considered 1856 as specifying a "quality" for the time stamp token. 1858 Time stamp tokens with various qualities may be issued by different 1859 time-stamping units operated by the same or different TSAs. 1861 A particular time-stamping unit will only provide one combination of 1862 algorithm and key length (since a time-stamping unit is a set of 1863 hardware and software which is managed as a unit and has a single 1864 time-stamp token signing key). In order to obtain different 1865 combinations of algorithm and key length, different time-stamping 1866 units shall be used. 1868 A particular time-stamping unit may provide a fixed accuracy for the 1869 time contained in the time stamp token or different accuracy if 1870 instructed to do so either by using a specific mode of access (e.g. 1871 e-mail or http) or by using specific parameters in the request. 1873 Policy Requirements for Time-Stamping Authorities August 2003 1875 Annex C (informative): Long Term Verification of time-stamp tokens 1877 Usually, a time-stamp token becomes unverifiable beyond the end of the 1878 validity period of the certificate from the TSU, because the CA that 1879 has issued the certificate does not warrant any more that it will 1880 publish revocation data, including data about revocations due to key 1881 compromises. However, verification of a time-stamp token might still be 1882 performed beyond the end of the validity period of the certificate from 1883 the TSU, if, at the time of verification, it can be known that: 1885 - the TSU private key has not been compromised at any time up to the 1886 time that a relying part verifies a time-stamp token; 1888 - the hash algorithms used in the time-stamp token exhibits no 1889 collisions at the time of verification; 1891 - the signature algorithm and signature key size under which the 1892 time-stamp token has been signed is still beyond the reach of 1893 cryptographic attacks at the time of verification. 1895 If these conditions cannot be met, then the validity may be maintained 1896 by applying an additional time-stamp to protect the integrity of the 1897 previous one. 1899 The present document does not specify the details of how such 1900 protection may be obtained. For the time being, and until some 1901 enhancements are defined to support these features, the information may 1902 be obtained using-out-of bands means or alternatively in the context of 1903 closed environments. As an example, should a CA guaranty to maintain 1904 the revocation status of TSU certificates after the end of its validity 1905 period, this would fulfil the first requirement. 1907 NOTE 1: An alternative to Time-Stamping is for a Trusted Service 1908 Provider to record a representation of a datum bound to a particular 1909 time in an audit trail, thus establishing evidence that the datum 1910 existed before that time. This technique, which is called Time-Marking, 1911 can be a valuable alternative for checking the long term validity of 1912 signatures. 1914 NOTE 2: The TSA or other trusted third party service provider may 1915 support the verification of time-stamp tokens. 1917 Policy Requirements for Time-Stamping Authorities August 2003 1919 Annex D (informative): Model TSA disclosure statement structure. 1921 The TSA disclosure statement contains a section for each defined 1922 statement type. Each section of a TSA disclosure statement contains a 1923 descriptive statement, which MAY include hyperlinks to the relevant 1924 certificate policy/certification practice statement sections. 1926 D.1. STATEMENT TYPE: Entire agreement 1928 STATEMENT DESCRIPTION: A statement indicating that the disclosure 1929 statement is not the entire agreement, but only a part of it. 1931 D.2. STATEMENT TYPE: TSA contact info 1933 STATEMENT DESCRIPTION: The name, location and relevant contact 1934 information for the TSA. 1936 D.3. STATEMENT TYPE: time-stamp token types and usage 1938 STATEMENT DESCRIPTION: A description of each class/type of 1939 time-stamp tokens issued by the TSA (in accordance with each 1940 time-stamp policy) and any restrictions on time-stamp usage. 1942 SPECIFIC REQUIREMENT: Indication of the policy being applied, 1943 including the contexts for which the time-stamp token can be used 1944 (e.g. only for use with electronic signatures), the hashing 1945 algorithms, the expected life time of the time-stamp token 1946 signature, any limitations on the use of the time-stamp token and 1947 information on how to verify the time-stamp token. 1949 D.4. STATEMENT TYPE: Reliance limits. 1951 STATEMENT DESCRIPTION: reliance limits, if any. 1953 SPECIFIC REQUIREMENT: Indication of the accuracy of the time in 1954 the time-stamp token, and the period of time for which TSA event 1955 logs (see section 7.4.10) are maintained (and hence are available 1956 to provide supporting evidence). 1958 D.5. STATEMENT TYPE: Obligations of subscribers. 1960 STATEMENT DESCRIPTION: The description of, or reference to, the 1961 critical subscriber obligations. 1963 SPECIFIC REQUIREMENT: No specific requirements identified in the 1964 current document. Where applicable the TSA may specify additional 1965 obligations. 1967 D.6. STATEMENT TYPE: TSU public key status checking obligations of 1968 relying parties. 1970 STATEMENT DESCRIPTION: The extent to which relying parties are 1971 obligated to check the TSU public key status, and references to 1972 further explanation. 1974 Policy Requirements for Time-Stamping Authorities August 2003 1976 SPECIFIC REQUIREMENT: Information on how to validate the TSU 1977 public key status, including requirements to check the revocation 1978 status of TSU public key, such that the relying party is 1979 considered to "reasonably rely" on the time-stamp token (see 1980 section 6.3). 1982 D.7. STATEMENT TYPE: Limited warranty and disclaimer/Limitation of 1983 liability. 1985 STATEMENT DESCRIPTION: Summary of the warranty, disclaimers, 1986 limitations of liability and any applicable warranty or insurance 1987 programs 1989 SPECIFIC REQUIREMENT: Limitations of liability (see section 6.4). 1991 D.8. STATEMENT TYPE: Applicable agreements and practice statement. 1993 STATEMENT DESCRIPTION: Identification and references to applicable 1994 agreements, practice statement, time-stamp policy and other 1995 relevant documents. 1997 D.9. STATEMENT TYPE: Privacy policy. 1999 STATEMENT DESCRIPTION: A description of and reference to the 2000 applicable privacy policy. 2002 SPECIFIC REQUIREMENT: Note: TSA's under this policy are required 2003 to comply with the requirements of Data Protection Legislation. 2005 D.10. STATEMENT TYPE: Refund policy 2007 STATEMENT DESCRIPTION: A description of and reference to the 2008 applicable refund policy. 2010 D.11. STATEMENT TYPE: Applicable law, complaints and dispute resolution 2011 mechanisms. 2013 STATEMENT DESCRIPTION: Statement of the choice of law, complaints 2014 procedure and dispute resolution mechanisms. 2016 SPECIFIC REQUIREMENT: The procedures for complaints and dispute 2017 settlements. The applicable legal system. 2019 D.12. STATEMENT TYPE: TSA and repository licenses, trust marks, and 2020 audit. 2022 STATEMENT DESCRIPTION: Summary of any governmental licenses, seal 2023 programs; and a description of the audit process and if 2024 applicable the audit firm. 2026 SPECIFIC REQUIREMENT: If the TSA has been assessed to be 2027 conformant with the identified time-stamp policy, and if so 2028 through which independent party. 2030 Policy Requirements for Time-Stamping Authorities August 2003 2032 Full Copyright Statement 2034 Copyright (C) The Internet Society (2001). All Rights Reserved. 2036 This document and translations of it may be copied and furnished to 2037 others, and derivative works that comment on or otherwise explain it 2038 or assist in its implementation may be prepared, copied, published 2039 and distributed, in whole or in part, without restriction of any 2040 kind, provided that the above copyright notice and this paragraph 2041 are included on all such copies and derivative works. However, this 2042 document itself may not be modified in any way, such as by removing 2043 the copyright notice or references to the Internet Society or other 2044 Internet organizations, except as needed for the purpose of 2045 developing Internet standards in which case the procedures for 2046 copyrights defined in the Internet Standards process must be 2047 followed, or as required to translate it into languages other than 2048 English. 2050 The limited permissions granted above are perpetual and will not be 2051 revoked by the Internet Society or its successors or assigns. 2053 This document and the information contained herein is provided on an 2054 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2055 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2056 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2057 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2058 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2060 Acknowledgement 2062 Funding for the RFC Editor function is currently provided by the 2063 Internet Society.