idnits 2.17.00 (12 Aug 2021) /tmp/idnits6803/draft-ietf-pkix-pr-tsa-00.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity. == There are 8 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 1) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The abstract seems to contain references ([RFC2119], [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.) -- The document date (March 2002) is 7371 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3126 (Obsoleted by RFC 5126) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Pinkas 3 Bull 4 Target Category: INFORMATIONAL J. Ross 5 Security & Standards 6 March 2002 8 Policy Requirements for Time-Stamping Authorities 9 11 Status of this Memo 13 This memo provides information for the Internet community. It does 14 not specify an Internet standard of any kind. Distribution of this 15 memo is unlimited. 17 The list of current Internet-Drafts can be accessed at 18 http://www.ietf.org/1id-abstracts.html 20 The list of Internet-Draft Shadow Directories can be accessed at 21 http://www.ietf.org/shadow.html 23 Copyright Notice 25 Copyright (C) The Internet Society (2001). All Rights Reserved. 27 Abstract 29 This document specifies policy requirements relating to the 30 operation of Time-stamping Authorities (TSAs). It defines policy 31 requirements on the operation and management practices of TSAs such 32 that subscribers and relying parties may have confidence in the 33 operation of the time-stamping services. 35 The contents of this Informational RFC is technically equivalent to 36 ETSI TS 102 023 V1.1.1 (2002-01) [TS 102023]. The ETSI TS is under 37 the ETSI Copyright (C). Individual copies of this ETSI deliverable 38 can be downloaded from http://www.etsi.org 40 This document is an Internet-Draft and is NOT offered in accordance 41 with Section 10 of RFC 2026, and the authors do not provide the IETF 42 with any rights other than to publish as an Internet-Draft. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in RFC 2119 47 [RFC 2119]. 49 Table of Contents 51 1. Introduction 4 53 2. Overview 5 55 3. Definitions and abbreviations 5 57 3.1. Definitions 5 58 3.2. Abbreviations 7 60 4. General concepts 7 62 4.1. Time-stamping services 7 63 4.2. Time-stamping authority 7 64 4.3. Subscriber 8 65 4.4. Time-stamp policy and TSA practice statement 8 66 4.4.1. Purpose 8 67 4.4.2. Level of specificity 8 68 4.4.3. Approach 9 70 5. Time-stamp Policies 9 72 5.1. Overview 9 73 5.2. Identification 9 74 5.3. User Community and applicability 10 75 5.4. Conformance 10 77 6. Obligations and liability 10 79 6.1. TSA obligations 10 80 6.1.1. General 10 81 6.1.2. TSA obligations towards subscribers 11 82 6.2. Subscriber obligations 11 83 6.3. Relying party obligations 11 84 6.4. Liability 11 86 7. Requirements on TSA practices 11 88 7.1. Practice and Disclosure Statements 12 89 7.1.1. TSA Practice statement 12 90 7.1.2. TSA disclosure Statement 13 91 7.2. Key management life cycle 14 92 7.2.1. TSA key generation 14 93 7.2.2. TSA private key protection 15 94 7.2.3. TSA public key Distribution 15 95 7.2.4. Rekeying TSA's Key 16 96 7.2.5. End of TSA key life cycle 16 97 7.2.6. Life cycle management of the cryptographic module 98 used to sign time-stamps 17 100 7.3. Time-stamping 17 102 7.3.1. Time-stamp token 17 103 7.3.2. Clock Synchronization with UTC 18 105 7.4. TSA management and operation 19 107 7.4.1. Security management 19 108 7.4.2. Asset classification and management 20 109 7.4.3. Personnel security 20 110 7.4.4. Physical and environmental security 22 111 7.4.5. Operations management 23 112 7.4.6. System Access Management 24 113 7.4.7. Trustworthy Systems Deployment and Maintenance 25 114 7.4.8. Compromise of TSA Services 25 115 7.4.9. TSA termination 26 116 7.4.10. Compliance with Legal Requirements 27 117 7.4.11. Recording of Information Concerning Operation 118 of Time-stamping Services 27 119 7.5. Organizational 28 121 8. Acknowledgments 29 123 9. References 29 125 10. Authors' addresses 31 127 Annex A (informative): Coordinated Universal Time 32 129 Annex B (informative): Possible for Implementation Architectures ū 130 Time-Stamping Services 34 132 Annex C (informative): Long Term Verification of time-stamp tokens 36 134 Annex D (informative): Model TSA disclosure statement 37 135 1. Introduction 137 In creating reliable and manageable digital evidence it becomes 138 necessary to have an agreed upon method of associating time data to 139 transaction so that they might be compared to each other at some later 140 time. The quality of this evidence is based in the process of creating 141 and managing the data structure that represent the events and the 142 quality of the parametric data points that anchor them to the real 143 world. In this instance this being the time data and how it was 144 applied. 146 A typical transaction is a digitally signed document, where it is 147 necessary to prove that the digital signature from the signer was 148 applied when the signer's certificate was valid. 150 A timestamp or a time mark (which is an audit record kept in a secure 151 audit trail from a trusted third party) applied to a digital signature 152 value proves that the digital signature was created before the date 153 included in the time-stamp or time mark. 155 To prove the digital signature was generated while the signer's 156 certificate was valid, the digital signature must be verified and 157 the following conditions satisfied: 159 1. the time-stamp (or time mark) has been applied before the end 160 of the validity period of the signerĘs certificate, 162 2. the time-stamp (or time mark) has been applied either 163 while the signerĘs certificate was not revoked or 164 before the revocation date of the certificate. 166 Thus a time-stamp (or time mark) applied in this manner proves that the 167 digital signature was created while the signerĘs certificate was valid. 168 This concept can be extended to prove the validity of a digital 169 signature over the whole of any certificate chain. 171 Policy requirements to cover that case is the primary reason of the 172 present document. However, it should be observed that these policy 173 requirements allow to address other needs. 175 The electronic time stamp is gaining an increasing interest by the 176 business sector and is becoming an important component of electronic 177 signatures, also featured by the ETSI Electronic Signature Format 178 standard [TS 101733] or Electronic Signature Formats for long term 179 electronic signatures [RFC 3126], built upon the Time-Stamp Protocol 180 [RFC 3161]. Agreed minimum security and quality requirements are 181 necessary in order to ensure trustworthy validation of long-term 182 electronic signatures. 184 The European Directive 1999/93/EC [Dir 99/93/EC] defines certification- 185 service-provider as "an entity or a legal or natural person who issues 186 certificates or provides other services related to electronic 187 signatures". 189 One example of a certification-service-provider is a Time-Stamping 190 Authority. 192 2. Overview 194 These policy requirements are primarily aimed at time-stamping services 195 used in support of qualified electronic signatures (i.e. in line with 196 article 5.1 of the European Directive on a community framework for 197 electronic signatures) but may be applied to any application requiring 198 to prove that a datum existed before a particular time. 200 These policy requirements are based upon the use of public key 201 cryptography, public key certificates and reliable time sources. 202 The present document may be used by independent bodies as the basis for 203 confirming that a TSA may be trusted for providing time-stamping 204 services. 206 The current document addresses requirements for TSAs issuing time-stamp 207 tokens which are synchronized with Coordinated universal time (UTC) and 208 digitally signed by the TSA. 210 Subscriber and relying parties should consult the TSA's practice 211 statement to obtain further details of precisely how this time-stamp 212 policy is implemented by the particular TSA (e.g. protocols used in 213 providing this service). 215 The current document does not specify: 217 - protocols used to access the TSA; 219 NOTE 1: A time-stamping protocol is defined in RFC 3161 [RFC 3161] and 220 profiled in TS 101 861 [TS 101861]. 222 - how the requirements identified herein may be assessed by an 223 independent body; 225 - requirements for information to be made available to such 226 independent bodies; 228 - requirements on such independent bodies. 230 NOTE 2: See CEN Workshop Agreement 14172 "EESSI Conformity Assessment 231 Guidance" [CWA 14172]. 233 3. Definitions and abbreviations 235 3.1. Definitions 237 For the purposes of the present document, the following terms and 238 definitions apply: 240 NOTE: Where a definition is copied from a referenced document this is 241 indicated by inclusion of the reference identifier number at the end of 242 the definition. 244 relying party: recipient of a time-stamp token who relies on that time- 245 stamp token. 247 subscriber: entity requiring data to be time-stamped by a TSA and which 248 has explicitly or implicitly agreed to its terms and conditions. 250 time-stamp token: data object that binds a representation of a datum to 251 a particular time, thus establishing evidence that the datum existed 252 before that time. 254 time-stamping authority: authority which issues time-stamp tokens. 256 TSA Disclosure statement: set of statements about the policies and 257 practices of a TSA that particularly require emphasis or disclosure to 258 subscribers and relying parties, for example to meet regulatory 259 requirements. 261 TSA practice statement: statement of the practices that a TSA employs 262 in issuing time-stamp tokens. 264 TSA system: composition of IT products and components organized to 265 support the provision of time-stamping services. 267 time-stamp policy: named set of rules that indicates the applicability 268 of a time-stamp token to a particular community and/or class of 269 application with common security requirements. 271 time-stamping unit: set of hardware and software which is managed as a 272 unit and has a single time-stamp token signing key active at a time. 274 Coordinated Universal Time (UTC): Time scale based on the second as 275 defined in ITU-R Recommendation TF.460-5 [TF.460-5] . 277 NOTE: For most practical purposes UTC is equivalent to mean solar time 278 at the prime meridian (0—). More specifically, UTC is a compromise 279 between the highly stable atomic time (Temps Atomique International - 280 TAI) and solar time derived from the irregular Earth rotation (related 281 to the Greenwich mean sidereal time (GMST) by a conventional 282 relationship). (See annex A for more details). 284 UTC(k): Time-scale realized by the laboratory "k" and kept in close 285 agreement with UTC, with the goal to reach plus or minus 100 ns. ( 286 See ITU-R Recommendation TF.536-1 [TF.536-1]). 288 NOTE: A list of UTC(k) laboratories is given in section 1 of 289 Circular T disseminated by BIPM and available from the BIPM website 290 (http://www.bipm.org/). 292 3.2. Abbreviations 294 For the purposes of the present document, the following abbreviations 295 apply: 297 TSA Time-Stamping Authority 298 TST Time-Stamp Token 299 UTC Coordinated Universal Time 301 4. General concepts 303 4.1 Time-stamping services 305 The provision of time-stamping services is broken down in the present 306 document into the following component services for the purposes of 307 classifying requirements: 309 - Time-stamping provision: This service component generates time- 310 stamp tokens. 312 - Time-stamping management: The service component that monitors and 313 controls the operation of the time-stamping services to ensure 314 that the service provided is as specified by the TSA. This service 315 component has responsibility for the installation and de- 316 installation of the time-stamping provision service. For example, 317 time-stamping management ensures that the clock used for time- 318 stamping is correctly synchronized with UTC. 320 This subdivision of services is only for the purposes of clarifying the 321 requirements specified in the current document and places no 322 restrictions on any subdivision of an implementation of time-stamping 323 services. 325 4.2 Time-stamping authority 327 The authority trusted by the users of the time-stamping services (i.e. 328 subscribers as well as relying parties) to issue time-stamp tokens is 329 called the Time-Stamping Authority (TSA). The TSA has overall 330 responsibility for the provision of the time-stamping services 331 identified in section 4.1. The TSA's key is used to sign a time-stamp 332 token and the TSA is identified in a time-stamp token as the issuer. 333 The TSA may make use of other parties to provide parts of the Time- 334 Stamping Services. However, the TSA always maintains overall 335 responsibility and ensures that the policy requirements identified in 336 the present document are met. For example, a TSA may sub-contract all 337 the component services, including the services which generate time- 338 stamps using the TSA's key. However, the private key or keys used to 339 generate the time-stamp tokens are identified as belonging to the TSA 340 which maintains overall responsibility for meeting the requirements 341 defined in the current document. 343 A TSA may operate several identifiable time-stamping units. Each unit 344 has a different key. See Annex B for possible implementations. 346 A TSA is a certification-service-provider, as defined in the EU 347 Directive on Electronic Signatures (see article 2(11)), which issues 348 time-stamp tokens. 350 4.3 Subscriber 352 The subscriber may be an organization comprising several end-users or 353 an individual end-user. 355 When the subscriber is an organization, some of the obligations that 356 apply to that organization will have to apply as well to the end-users. 357 In any case the organization will be held responsible if the 358 obligations from the end-users are not correctly fulfilled and 359 therefore the such an organization is expected to suitably inform its 360 end users. 362 When the subscriber is an end-user, the end-user will be held directly 363 responsible if its obligations are not correctly fulfilled. 365 4.4 Time-stamp policy and TSA practice statement 367 This section explains the relative roles of Time-stamp policy and TSA 368 practice statement. It places no restriction on the form of a time- 369 stamp policy or practice statement specification. 371 4.4.1 Purpose 373 In general, the time-stamp policy states "what is to be adhered to," 374 while a TSA practice statement states "how it is adhered to", i.e., the 375 processes it will use in creating time-stamps and maintaining the 376 accuracy of its clock. The relationship between the time-stamp policy 377 and TSA practice statement is similar in nature to the relationship of 378 other business policies which state the requirements of the business, 379 while operational units define the practices and procedures of how 380 these policies are to be carried out. 382 The present document specifies a time-stamp policy to meet general 383 requirements for trusted time-stamping services. TSAs specify in TSA 384 practice statements how these requirements are met. 386 4.4.2 Level of specificity 388 A time-stamp policy is a less specific document than a TSA practice 389 statement. A TSA practice statement is a more detailed description of 390 the terms and conditions as well as business and operational practices 391 of a TSA in issuing and otherwise managing time-stamping services. The 392 TSA practice statement of a TSA enforces the rules established by a 393 time-stamp policy. A TSA practice statement defines how a specific TSA 394 meets the technical, organizational and procedural requirements 395 identified in a time-stamp policy. 397 NOTE: Even lower-level internal documentation may be appropriate for a 398 TSA detailing the specific procedures necessary to complete the 399 practices identified in the TSA practice statement. 401 4.4.3 Approach 403 The approach of a time-stamp policy is significantly different from a 404 TSA practice statement. A time-stamp policy is defined independently of 405 the specific details of the specific operating environment of a TSA, 406 whereas a TSA practice statement is tailored to the organizational 407 structure, operating procedures, facilities, and computing environment 408 of a TSA. A time-stamp policy may be defined by the user of times-stamp 409 services, whereas the TSA practice statement is always defined by the 410 provider. 412 5 Time-stamp Policies 414 5.1 Overview 416 A time-stamp policy is a "named set of rules that indicates the 417 applicability of a time-stamp token to a particular community and/or 418 class of application with common security requirements" (see clauses 419 3.1 and 4.4). 421 The present document defines requirements for a baseline time-stamp 422 policy for TSAs issuing time-stamp tokens, supported by the public key 423 certificate of the TSA, with an accuracy of 1 second or better. 425 NOTE 1: Without additional measures the relying party may not be able 426 to ensure the validity of a time-stamp token beyond the end of the 427 validity period of the supporting certificate. See annex C on 428 verification of the validity of a time-stamp token beyond the validity 429 period of the TSA's certificate. 431 A TSA may define its own policy which enhances the policy defined in 432 the current document. Such a policy shall incorporate or further 433 constrain the requirements identified in the current document. 434 If an accuracy of better than 1 second is provided by the TSA then the 435 accuracy shall be indicated in the TSA's disclosure statement (see 436 section 7.1.2) and in each time-stamp token issued to an accuracy of 437 better than 1 second. 439 NOTE 2: It is required that a time-stamp token includes an identifier 440 for the applicable policy (see section 7.3.1). 442 5.2 Identification 444 The object-identifier of the baseline time-stamp policy is: 445 itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) 446 policy-identifiers(1) baseline-ts-policy (1) 448 A TSA shall also include the identifier for the time-stamp policy being 449 supported in the TSA disclosure statement made available to subscribers 450 and relying parties to indicate its claim of conformance. 452 5.3 User Community and applicability 454 This policy is aimed at meeting the requirements of time-stamping 455 qualified electronic signatures (see European Directive on Electronic 456 Signatures) for long term validity (e.g. as defined in TS 101 733 457 [TS 101733]) but is generally applicable to any use which has a 458 requirement for equivalent quality. 460 This policy may be used for public time-stamping services or time- 461 stamping services used within a closed community. 463 5.4 Conformance 465 The TSA shall use the identifier for the time-stamp policy in time- 466 stamp tokens as given in section 5.2, or define its own time-stamp 467 policy that incorporates or further constrains the requirements 468 identified in the present document: 470 a) if the TSA claims conformance to the identified time-stamp policy 471 and makes available to subscribers and relying parties on request the 472 evidence to support the claim of conformance; or 474 b) if the TSA has been assessed to be conformant to the identified 475 time-stamp policy by an independent party. 477 A conformant TSA must demonstrate that: 479 a) it meets its obligations as defined in section 6.1; 480 b) it has implemented controls which meet the requirements specified in 481 section 7. 483 6 Obligations and liability 485 6.1 TSA obligations 487 6.1.1 General 489 The TSA shall ensure that all requirements on TSA, as detailed in 490 section 7, are implemented as applicable to the selected trusted time- 491 stamp policy. 493 The TSA shall ensure conformance with the procedures prescribed in this 494 policy, even when the TSA functionality is undertaken by sub- 495 contractors. 497 The TSA shall also ensure adherence to any additional obligations 498 indicated in the time-stamp either directly or incorporated by 499 reference. 501 The TSA shall provide all its time-stamping services consistent with 502 its practice statement. 504 6.1.2 TSA obligations towards subscribers 506 The TSA shall meet its claims as given in its terms and conditions 507 including the availability and accuracy of its service. 509 6.2 Subscriber obligations 511 The current document places no specific obligations on the subscriber 512 beyond any TSA specific requirements stated in the TSA's terms and 513 condition. 515 NOTE: It is advisable that, when obtaining a time-stamp token, the 516 subscriber verifies that the time-stamp token has been correctly signed 517 and that the private key used to sign the time-stamp token has not been 518 compromised. 520 6.3 Relying party obligations 522 The terms and conditions made available to relying parties (see section 523 7.1.2) shall include an obligation on the relying party that, when 524 relying on a time-stamp token, it shall: 526 a) verify that the time-stamp token has been correctly signed and that 527 the private key used to sign the time-stamp has not been compromised 528 until the time of the verification; 530 NOTE: During the TSA's certificate validity period, the validity of the 531 signing key can be checked using current revocation status for the 532 TSA's certificate. If the time of verification exceeds the end of the 533 validity period of the corresponding certificate, see annex C for 534 guidance. 536 b) take into account any limitations on the usage of the time-stamp 537 indicated by the time-stamp policy; 539 c) take into account any other precautions prescribed in agreements or 540 elsewhere. 542 6.4 Liability 544 The present document does not specify any requirement on liability. In 545 particular, it should be noticed that a TSA may disclaim or limit any 546 liability unless otherwise stipulated by the applicable law. 548 7 Requirements on TSA practices 550 The TSA shall implement the controls that meet the following 551 requirements. 553 These policy requirements are not meant to imply any restrictions on 554 charging for TSA services. 556 The requirements are indicated in terms of the security objectives 557 followed by more specific requirements for controls to meet those 558 objectives where considered necessary to provide the necessary 559 confidence that those objective will be met. 561 NOTE: The details of controls required to meet an objective is a 562 balance between achieving the necessary confidence whilst minimizing 563 the restrictions on the techniques that a TSA may employ in issuing 564 time-stamp tokens. In case of section 7.4 (TSA management and 565 operation) reference is made to other more general standards which may 566 be used as a source of more detailed control requirements. Due to these 567 factors the specificity of the requirements given under a given topic 568 may vary. 570 The provision of a time-stamp token in response to a request is at the 571 discretion of the TSA depending on any service level agreements with 572 the subscriber. 574 7.1 Practice and Disclosure Statements 576 7.1.1 TSA Practice statement 578 The TSA shall ensure that it demonstrates the reliability necessary for 579 providing time-stamping services. 581 In particular: 583 a) The TSA shall have a risk assessment carried out in order to 584 evaluate business assets and threats to those assets in order to 585 determine the necessary security controls and operational procedures. 587 b) The TSA shall have a statement of the practices and procedures used 588 to address all the requirements identified in this time-stamp policy. 590 NOTE 1: This policy makes no requirement as to the structure of the TSA 591 practice statement. 593 c) The TSA's practice statement shall identify the obligations of all 594 external organizations supporting the TSA services including the 595 applicable policies and practices. 597 d) The TSA shall make available to subscribers and relying parties its 598 practice statement, and other relevant documentation, as necessary to 599 assess conformance to the time-stamp policy. 601 NOTE 2: The TSA is not generally required to make all the details of 602 its practices public. 604 e) The TSA shall disclose to all subscribers and potential relying 605 parties the terms and conditions regarding use of its time-stamping 606 services as specified in section 7.1.2. 608 f) The TSA shall have a high level management body with final authority 609 for approving the TSA practice statement. 611 g) The senior management of the TSA shall ensure that the practices are 612 properly implemented. 614 h) The TSA shall define a review process for the practices including 615 responsibilities for maintaining the TSA practice statement. 617 i) The TSA shall give due notice of changes it intends to make in its 618 practice statement and shall, following approval as in (f) above, make 619 the revised TSA practice statement immediately available as required 620 under (d) above. 622 7.1.2 TSA disclosure Statement 624 The TSA shall disclose to all subscribers and potential relying parties 625 the terms and conditions regarding use of its time-stamping services. 626 This statement shall at least specify for each time-stamp policy 627 supported by the TSA: 629 a) The TSA contact information. 631 b) The time-stamp policy being applied. 633 c) At least one hashing algorithm which may be used to represent the 634 datum being time-stamped. 636 d) The expected life-time of the signature used to sign the time-stamp 637 token (depends on the hashing algorithm being used, the signature 638 algorithm being used and the private key length). 640 e) The accuracy of the time in the time-stamp tokens with respect to 641 UTC. 643 f) Any limitations on the use of the time-stamping service. 645 g) The subscriber's obligations as defined in section 6.2, if any. 647 h) The relying party's obligations as defined in section 6.3. 649 i) Information on how to verify the time-stamp token such that the 650 relying party is considered to "reasonably rely" on the time-stamp 651 token (see section 6.3) and any possible limitations on the validity 652 period. 654 j) The period of time during which TSA event logs (see section 7.4.10) 655 are retained. 657 k) The applicable legal system, including any claim to meet the 658 requirements on time-stamping services under national law. 660 l) Limitations of liability. 662 m) Procedures for complaints and dispute settlement. 664 n) If the TSA has been assessed to be conformant with the identified 665 time-stamp policy, and if so by which independent body. 667 NOTE 1: It is also recommended that the TSA includes in its time- 668 stamping disclosure statement availability of its service, for example 669 the expected mean time between failure of the time-stamping service, 670 the mean time to recovery following a failure and provisions made for 671 disaster recovery including back-up services; 673 This information shall be available through a durable means of 674 communication. This information shall be available in a readily 675 understandable language. It may be transmitted electronically. 677 NOTE 2: A model TSA disclosure statement which may be used as the basis 678 of such a communication is given in annex D. Alternatively this may be 679 provided as part of a subscriber / relying party agreement. These TSA 680 disclosure statement may be included in a TSA practice statement 681 provided that they are conspicuous to the reader. 683 7.2 Key management life cycle 685 7.2.1 TSA key generation 687 The TSA shall ensure that any cryptographic keys are generated in under 688 controlled circumstances. 690 In particular: 692 a) The generation of the TSA's signing key(s) shall be undertaken in a 693 physically secured environment (see section 7.4.4) by personnel in 694 trusted roles (see section 7.4.3) under, at least, dual control. The 695 personnel authorized to carry out this function shall be limited to 696 those requiring to do so under the TSA's practices. 698 b) The generation of the TSA's signing key(s) shall be carried out 699 within a cryptographic module(s) which either: 701 - meets the requirements identified in FIPS 140-1 [FIPS 140-1] 702 level 3 or higher, or 704 - meets the requirements identified in CEN Workshop Agreement 705 14167-2 [CWA 14167-2], or 707 - is a trustworthy system which is assured to EAL 4 or higher in 708 accordance to ISO 15408 [ISO 15408], or equivalent security 709 criteria. This shall be to a security target or protection 710 profile which meets the requirements of the current document, 711 based on a risk analysis and taking into account physical and 712 other non-technical security measures. 714 c) The TSA key generation algorithm, the resulting signing key length 715 and signature algorithm used for signing time-stamp tokens key shall be 716 recognized by any national supervisory body, or in accordance with 717 existing current state of art, as being fit for the purposes of time- 718 stamp tokens as issued by the TSA. 720 7.2.2 TSA private key protection 722 The TSA shall ensure that TSA private keys remain confidential and 723 maintain their integrity. 725 In particular: 727 a) The TSA private signing key shall be held and used within a 728 cryptographic module which: 730 - meets the requirements identified in FIPS 140-1 [FIPS 140-1] level 3 731 or higher; or 733 - meets the requirements identified in CEN Workshop Agreement 734 14167-2 [CWA 14167-2]; or 736 - is a trustworthy system which is assured to EAL 4 or higher in 737 accordance to ISO 15408 [ISO 15408], or equivalent security criteria. 738 This shall be to a security target or protection profile which meets 739 the requirements of the current document, based on a risk analysis 740 and taking into account physical and other non-technical security 741 measures. 743 NOTE: Backup of TSA private keys is deprecated in order to minimize 744 risk of key compromise. 746 b) If TSA private keys are backed up, they shall be copied, stored 747 and recovered only by personnel in trusted roles using, at least, dual 748 control in a physically secured environment. (see section 7.4.4). The 749 personnel authorized to carry out this function shall be limited to 750 those requiring to do so under the TSA's practices. 752 c) Any backup copies of the TSA private signing keys shall be protected 753 to ensure its confidentiality by the cryptographic module before being 754 stored outside that device. 756 7.2.3 TSA public key Distribution 758 The TSA shall ensure that the integrity and authenticity of the TSA 759 signature verification (public) key and any associated parameters are 760 maintained during its distribution to relying parties. 762 In particular: 764 a) TSA signature verification (public) keys shall be made available to 765 relying parties in a public key certificate. 767 NOTE: For example, TSA's certificate may be issued by a certification 768 authority operated by the same organization as the TSA, or issued by 769 another authority. 771 b) The TSA's signature verification (public) key certificate shall be 772 issued by a certification authority operating under a certificate 773 policy which provides a level of security equivalent to, or higher 774 than, this time-stamping policy. 776 7.2.4 Rekeying TSA's Key 778 The life-time of TSA's certificate shall be not longer than the period 779 of time that the chosen algorithm and key length is recognized as being 780 fit for purpose (see section 7.2.1c)). 782 NOTE 1: The following additional considerations apply when limiting 783 that lifetime: 785 - Section 7.4.10 requires that records concerning time-stamping 786 services shall be held for a period of time as appropriate for at 787 least 1 year after the expiration of the validity of the TSA's 788 signing key. The longer the validity period of the TSA certificate 789 will be, the longer the size of the records to be kept will be. 791 - Should a TSA private key be compromised, then the longer the life- 792 time, the more affected time-stamp tokens there will be. 794 NOTE 2: TSA key compromise does not only depend on the characteristics 795 of the cryptographic module being used but also on the procedures being 796 used at system initialization and key export (when that function is 797 supported). 799 7.2.5 End of TSA key life cycle 801 The TSA shall ensure that TSA private signing keys are not used beyond 802 the end of their life cycle. 804 In particular: 806 a) Operational or technical procedures shall be in place to ensure that 807 a new key is put in place when a TSA's key expires. 809 b) The TSA private signing keys, or any key part, including any copies 810 shall be destroyed such that the private keys cannot be retrieved. 812 c) The TST generation system SHALL reject any attempt to issue TSTs if 813 the signing private key has expired. 815 7.2.6 Life cycle management of the cryptographic module used to sign 816 time-stamps 818 The TSA shall ensure the security of cryptographic hardware throughout 819 its lifecycle. 821 In particular the TSA shall ensure that: 823 a) Time-stamp token signing cryptographic hardware is not tampered with 824 during shipment; 826 b) Time-stamp token signing cryptographic hardware is not tampered with 827 while stored; 829 c) Installation, activation and duplication of TSA's signing keys in 830 cryptographic hardware shall be done only by personnel in trusted roles 831 using, at least, dual control in a physically secured environment. (see 832 section 7.4.4); 834 d) Time-stamp token signing cryptographic hardware is functioning 835 correctly; and 837 e) TSA private signing keys stored on TSA cryptographic module are 838 erased upon device retirement. 840 7.3 Time-stamping 842 7.3.1 Time-stamp token 844 The TSA shall ensure that time-stamp tokens are issued securely and 845 include the correct time. 847 In particular: 849 a) The time-stamp token shall include an identifier for the time-stamp 850 policy; 852 b) Each time-stamp token shall have a unique identifier; 854 c) The time values the TSA uses in the time-stamp token shall be 855 traceable to at least one of the real time values distributed by a 856 UTC(k) laboratory. 858 NOTE 1: The Bureau International des Poids et Mesures (BIPM) computes 859 UTC on the basis of its local representations UTC(k) from a large 860 ensemble of atomic clocks in national metrology institutes and national 861 astronomical observatories round the world. The BIPM disseminates UTC 862 through its monthly Circular T [list 1]. This is available on the BIPM 863 website (www.bipm.org) and it officially identifies all those 864 institutes having recognized UTC(k) time scales. 866 d) The time included in the time-stamp token shall be synchronized with 867 UTC within the accuracy defined in this policy and, if present, within 868 the accuracy defined in the time-stamp token itself; 870 e) If the time-stamp provider's clock is detected (see section 7.3.2c)) 871 as being out of the stated accuracy (see section 7.1.2e)) then time- 872 stamp tokens shall not be issued. 874 f) The time-stamp token shall include a representation (e.g. hash 875 value) of the datum being time-stamped as provided by the requestor; 877 g) The time-stamp token shall be signed using a key generated 878 exclusively for this purpose. 880 NOTE 2: A protocol for a time-stamp token is defined in RFC 3631 and 881 profiled in TS 101 861 [TS 101861]. 883 NOTE 3: In the case of a number of requests at approximately the same 884 time, the ordering of the time within the accuracy of the TSA clock is 885 not mandated. 887 h) The name of the issuing TSA shall be identified in the time-stamp 888 token. This shall include: 890 - where applicable, an identifier for the country in which the TSA 891 is established; 893 - an identifier for the TSA; 895 - an identifier for the unit which issues the time-stamps. 897 7.3.2 Clock Synchronization with UTC 899 The TSA shall ensure that its clock is synchronized with UTC within the 900 declared accuracy. 902 In particular: 904 a) The calibration of the TSA clocks shall be maintained such that the 905 clocks shall not be expected to drift outside the declared accuracy. 907 b) The TSA clocks shall be protected against threats which could result 908 in an undetected change to the clock that takes it outside its 909 calibration. 911 NOTE 1: Threats may include tampering by unauthorized personnel, radio 912 or electrical shocks. 914 c) The TSA shall ensure that, if the time that would be indicated in a 915 time-stamp token drifts or jumps out of synchronization with UTC, this 916 will be detected (see also 7.3.1e)). 918 NOTE 2: Relying parties are required to be informed of such events (see 919 section 7.4.8). 921 d) The TSA shall ensure that clock synchronization is maintained when a 922 leap second occurs as notified by the appropriate body. The change to 923 take account of the leap second shall occur during the last minute of 924 the day when the leap second is scheduled to occur. A record shall be 925 maintained of the exact time (within the declared accuracy) when this 926 change occurred. See annex A for more details. 928 NOTE 3: A leap second is an adjustment to UTC by skipping or adding an 929 extra second on the last second of a UTC month. First preference is 930 given to the end of December and June, and second preference is given 931 to the end of March and September. 933 7.4 TSA management and operation 935 7.4.1 Security management 937 The TSA shall ensure that administrative and management procedures are 938 applied which are adequate and correspond to recognized best practice. 940 In particular: 942 TSA General 944 a) The TSA shall retain responsibility for all aspects of the provision 945 of time-stamping services within the scope of this time-stamp policy, 946 whether or not functions are outsourced to subcontractors. 947 Responsibilities of third parties shall be clearly defined by the TSA 948 and appropriate arrangements made to ensure that third parties are 949 bound to implement any controls required by the TSA. The TSA shall 950 retain responsibility for the disclosure of relevant practices of all 951 parties. 953 b) The TSA management shall provide direction on information security 954 through a suitable high level steering forum that is responsible for 955 defining the TSA's information security policy. The TSA shall ensure 956 publication and communication of this policy to all employees who are 957 impacted by it. 959 c) The information security infrastructure necessary to manage the 960 security within the TSA shall be maintained at all times. Any changes 961 that will impact on the level of security provided shall be approved by 962 the TSA management forum. 964 NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on information 965 security management including information security infrastructure, 966 management information security forum and information security 967 policies. 969 d) The security controls and operating procedures for TSA facilities, 970 systems and information assets providing the time-stamping services 971 shall be documented, implemented and maintained. 973 NOTE 2: The present documentation (commonly called a system security 974 policy or manual) should identify all relevant targets, objects and 975 potential threats related to the services provided and the safeguards 976 required to avoid or limit the effects of those threats, consistent 977 with the Risk Assessment required under section 7.1.1a). It should 978 describe the rules, directives and procedures regarding how the 979 specified services and the associated security assurance are granted in 980 addition to stating policy on incidents and disasters. 982 e) TSA shall ensure that the security of information is maintained when 983 the responsibility for TSA functions has been outsourced to another 984 organization or entity. 986 7.4.2 Asset classification and management 988 The TSA shall ensure that its information and other assets receive an 989 appropriate level of protection. 991 In particular: 993 - The TSA shall maintain an inventory of all assets and shall assign a 994 classification for the protection requirements to those assets 995 consistent with the risk analysis. 997 7.4.3 Personnel security 999 The TSA shall ensure that personnel and hiring practices enhance and 1000 support the trustworthiness of the TSA's operations. 1002 In particular (TSA general): 1004 a) The TSA shall employ personnel which possess the expert knowledge, 1005 experience and qualifications necessary for the offered services and as 1006 appropriate to the job function. 1008 NOTE 1: TSA personnel should be able to fulfil the requirement of 1009 "expert knowledge, experience and qualifications" through formal 1010 training and credentials, actual experience, or a combination of the 1011 two. 1013 NOTE 2: Personnel employed by a TSA include individual personnel 1014 contractually engaged in performing functions in support of the TSA's 1015 time-stamping services. Personnel who may be involved in monitoring the 1016 TSA services need not be TSA personnel. 1018 b) Security roles and responsibilities, as specified in the TSA's 1019 security policy, shall be documented in job descriptions. Trusted 1020 roles, on which the security of the TSA's operation is dependent, shall 1021 be clearly identified. 1023 c) TSA personnel (both temporary and permanent) shall have job 1024 descriptions defined from the view point of separation of duties and 1025 least privilege, determining position sensitivity based on the duties 1026 and access levels, background screening and employee training and 1027 awareness. Where appropriate, these shall differentiate between general 1028 functions and TSA specific functions. These should include skills and 1029 experience requirements. 1031 d) Personnel shall exercise administrative and management procedures 1032 and processes that are in line with the TSA's information security 1033 management procedures (see section 7.4.1). 1035 NOTE 3: See ISO/IEC 17799 [ISO 17799] for guidance. 1037 The following additional controls shall be applied to time-stamping 1038 management: 1040 e) Managerial personnel shall be employed who possess: 1042 - knowledge of time-stamping technology; and 1043 - knowledge of digital signature technology; and 1044 - knowledge of mechanisms for calibration or synchronization the 1045 TSA clock with UTC; and 1046 - familiarity with security procedures for personnel with security 1047 responsibilities; and 1048 - experience with information security and risk assessment. 1050 f) All TSA personnel in trusted roles shall be free from conflict of 1051 interest that might prejudice the impartiality of the TSA operations. 1053 g) Trusted roles include roles that involve the following 1054 responsibilities: 1056 - Security Officers: Overall responsibility for administering the 1057 implementation of the security practices. 1059 - System Administrators: Authorized to install, configure and 1060 maintain the TSA trustworthy systems for time-stamping management. 1062 - System Operators: Responsible for operating the TSA trustworthy 1063 systems on a day-to-day basis. Authorized to perform system backup 1064 and recovery. 1066 - System Auditors: Authorized to view archives and audit logs of 1067 the TSA trustworthy systems. 1069 h) TSA personnel shall be formally appointed to trusted roles by senior 1070 management responsible for security. 1072 i) The TSA shall not appoint to trusted roles or management any person 1073 who is known to have a conviction for a serious crime or other offence 1074 which affects his/her suitability for the position. Personnel shall not 1075 have access to the trusted functions until any necessary checks are 1076 completed. 1078 NOTE 4: In some countries it may not be possible for TSA to obtain 1079 information on past convictions without the collaboration of the 1080 candidate employee. 1082 7.4.4 Physical and environmental security 1084 The TSA shall ensure that physical access to critical services is 1085 controlled and physical risks to its assets minimized. 1087 In particular (general): 1089 a) For both the time-stamping provision and the time-stamping 1090 management: 1092 - physical access to facilities concerned with time-stamping services 1093 shall be limited to properly authorized individuals; 1094 - controls shall be implemented to avoid loss, damage or compromise of 1095 assets and interruption to business activities; and 1096 - controls shall be implemented to avoid compromise or theft of 1097 information and information processing facilities. 1099 b) Access controls shall be applied to the cryptographic module to meet 1100 the requirements of security of cryptographic modules as identified in 1101 clauses 7.2.1 and 7.2.2. 1103 c) The following additional controls shall be applied to time-stamping 1104 management: 1106 - The time-stamping management facilities shall be operated in an 1107 environment which physically protects the services from compromise 1108 through unauthorized access to systems or data. 1110 - Physical protection shall be achieved through the creation of 1111 clearly defined security perimeters (i.e. physical barriers) around 1112 the time-stamping management. Any parts of the premises shared with 1113 other organizations shall be outside this perimeter. 1115 - Physical and environmental security controls shall be implemented to 1116 protect the facility that houses system resources, the system 1117 resources themselves, and the facilities used to support their 1118 operation. The TSA's physical and environmental security policy for 1119 systems concerned with time-stamping management shall address as a 1120 minimum the physical access control, natural disaster protection, 1121 fire safety factors, failure of supporting utilities (e.g. power, 1122 telecommunications), structure collapse, plumbing leaks, protection 1123 against theft, breaking and entering, and disaster recovery. 1125 - Controls shall be implemented to protect against equipment, 1126 information, media and software relating to the time-stamping 1127 services being taken off-site without authorization. 1129 NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on physical and 1130 environmental security. 1132 NOTE 2: Other functions may be supported within the same secured area 1133 provided that the access is limited to authorized personnel. 1135 7.4.5 Operations management 1137 The TSA shall ensure that the TSA system components are secure and 1138 correctly operated, with minimal risk of failure: 1140 In particular (general): 1142 a) The integrity of TSA system components and information shall be 1143 protected against viruses, malicious and unauthorized software. 1145 b) Incident reporting and response procedures shall be employed in such 1146 a way that damage from security incidents and malfunctions shall be 1147 minimized. 1149 c) Media used within the TSA trustworthy systems shall be securely 1150 handled to protect media from damage, theft, unauthorized access and 1151 obsolescence. 1153 NOTE 1: Every member of personnel with management responsibilities is 1154 responsible for planning and effectively implementing the time-stamp 1155 policy and associated practices as documented in the TSA practice 1156 statement. 1158 d) Procedures shall be established and implemented for all trusted and 1159 administrative roles that impact on the provision of time-stamping 1160 services. 1162 Media handling and security 1164 e) All media shall be handled securely in accordance with requirements 1165 of the information classification scheme (see section 7.4.2). Media 1166 containing sensitive data shall be securely disposed of when no longer 1167 required. 1169 System Planning 1171 f) Capacity demands shall be monitored and projections of future 1172 capacity requirements made to ensure that adequate processing power and 1173 storage are available. 1175 Incident reporting and response 1177 g) The TSA shall act in a timely and coordinated manner in order to 1178 respond quickly to incidents and to limit the impact of breaches of 1179 security. All incidents shall be reported as soon as possible after the 1180 incident. 1182 The following additional controls shall be applied to time-stamping 1183 management: 1185 Operations procedures and responsibilities 1187 h) TSA security operations shall be separated from other operations. 1189 NOTE 2: TSA security operations' responsibilities include: 1190 - operational procedures and responsibilities; 1191 - secure systems planning and acceptance; 1192 - protection from malicious software; 1193 - housekeeping; 1194 - network management; 1195 - active monitoring of audit journals, event analysis and follow-up; 1196 - media handling and security; 1197 - data and software exchange. 1199 These operations shall be managed by TSA trusted personnel, but, may 1200 actually be performed by, non-specialist, operational personnel (under 1201 supervision), as defined within the appropriate security policy, and, 1202 roles and responsibility documents. 1204 7.4.6 System Access Management 1206 The TSA shall ensure that TSA system access is limited to properly 1207 authorized individuals. 1209 In particular (general): 1211 a) Controls (e.g., firewalls) shall be implemented to protect the TSA's 1212 internal network domains from unauthorized access including access by 1213 subscribers and third parties. 1215 NOTE 1: Firewalls should also be configured to prevent all protocols 1216 and accesses not required for the operation of the TSA. 1218 b) The TSA shall ensure effective administration of user (this includes 1219 operators, administrators and auditors) access to maintain system 1220 security, including user account management, auditing and timely 1221 modification or removal of access. 1223 c) The TSA shall ensure that access to information and application 1224 system functions is restricted in accordance with the access control 1225 policy and that the TSA system provides sufficient computer security 1226 controls for the separation of trusted roles identified in TSA's 1227 practices, including the separation of security administrator and 1228 operation functions. Particularly, use of system utility programs is 1229 restricted and tightly controlled. 1231 d) TSA personnel shall be properly identified and authenticated before 1232 using critical applications related to time-stamping. 1234 e) TSA personnel shall be accountable for their activities, for example 1235 by retaining event logs (see section 7.4.10). 1237 The following additional controls shall be applied to time-stamping 1238 management: 1240 f) The TSA shall ensure that local network components (e.g. routers) 1241 are kept in a physically secure environment and that their 1242 configurations are periodically audited for compliance with the 1243 requirements specified by the TSA. 1245 g) Continuous monitoring and alarm facilities shall be provided to 1246 enable the TSA to detect, register and react in a timely manner upon 1247 any unauthorized and/or irregular attempts to access its resources. 1249 NOTE 2: This may use, for example, an intrusion detection system, 1250 access control monitoring and alarm facilities. 1252 7.4.7 Trustworthy Systems Deployment and Maintenance 1254 The TSA shall use trustworthy systems and products that are protected 1255 against modification. 1257 NOTE: The risk analysis carried out on the TSA's services (see section 1258 7.1.1) should identify its critical services requiring trustworthy 1259 systems and the levels of assurance required. 1261 In particular: 1263 a) An analysis of security requirements shall be carried out at the 1264 design and requirements specification stage of any systems development 1265 project undertaken by the TSA or on behalf of the TSA to ensure that 1266 security is built into IT systems. 1268 b) Change control procedures shall be applied for releases, 1269 modifications and emergency software fixes of any operational software. 1271 7.4.8 Compromise of TSA Services 1273 The TSA shall ensure in the case of events which affect the security of 1274 the TSA's services, including compromise of the TSA's private signing 1275 key or detected loss of calibration, that relevant information is made 1276 available to subscribers and relying parties. 1278 In particular: 1280 a) The TSA's disaster recovery plan shall address the compromise or 1281 suspected compromise of a TSA's private signing key or loss of 1282 calibration of the TSA clock, which may have affected time-stamp tokens 1283 which have been issued. 1285 b) In the case of a compromise, or suspected compromise or loss of 1286 calibration the TSA shall make available to all subscribers and relying 1287 parties a description of compromise that occurred. 1289 c) In the case of compromise to the TSA's operation (e.g. TSA key 1290 compromise), suspected compromise or loss of calibration the TSA shall 1291 not issue time-stamp tokens until steps are taken to recover from the 1292 compromise 1294 d) In case of major compromise of the TSA's operation or loss of 1295 calibration, wherever possible, the TSA shall make available to all 1296 subscribers and relying parties information which may be used to 1297 identify the time-stamp tokens which may have been affected, unless 1298 this breaches the privacy of the TSAs users or the security of the TSA 1299 services. 1301 NOTE: In case the private key does become compromised, an audit trail 1302 of all tokens generated by the TSA may provide a means to discriminate 1303 between genuine and false backdated tokens. Two time-stamp tokens from 1304 two different TSAs may be another way to address this issue. 1306 7.4.9 TSA termination 1308 The TSA shall ensure that potential disruptions to subscribers and 1309 relying parties are minimized as a result of the cessation of the TSA's 1310 time-stamping services, and in particular ensure continued maintenance 1311 of information required to verify the correctness of time-stamp tokens. 1313 In particular: 1315 a) Before the TSA terminates its time-stamping services the following 1316 procedures shall be executed as a minimum: 1318 - the TSA shall make available to all subscribers and relying 1319 parties information concerning its termination; 1321 - TSA shall terminate authorization of all subcontractors to act on 1322 behalf of the TSA in carrying out any functions relating to the 1323 process of issuing time-stamp tokens; 1325 - the TSA shall transfer obligations to a reliable party for 1326 maintaining event log and audit archives (see section 7.4.10) 1327 necessary to demonstrate the correct operation of the TSA for a 1328 reasonable period; 1330 - the TSA shall maintain or transfer to a reliable party its 1331 obligations to make available its public key or its certificates to 1332 relying parties for a reasonable period; 1334 - TSA private keys, including backup copies, shall be destroyed in 1335 a manner such that the private keys cannot be retrieved. 1337 b) The TSA shall have an arrangement to cover the costs to fulfil these 1338 minimum requirements in case the TSA becomes bankrupt or for other 1339 reasons is unable to cover the costs by itself. 1341 c) The TSA shall state in its practices the provisions made for 1342 termination of service. This shall include: 1344 - notification of affected entities; 1345 - transferring the TSA obligations to other parties. 1347 d) The TSA shall take steps to have its certificates revoked. 1349 7.4.10 Compliance with Legal Requirements 1351 The TSA shall ensure compliance with legal requirements. 1353 In particular: 1355 a) The TSA shall ensure that the requirements of the European data 1356 protection Directive [Dir 95/46/EC], as implemented through national 1357 legislation, are met. 1359 b) Appropriate technical and organizational measures shall be taken 1360 against unauthorized or unlawful processing of personal data and 1361 against accidental loss or destruction of, or damage to, personal data. 1363 c) The information contributed by users to the TSA shall be completely 1364 protected from disclosure unless with their agreement or by court order 1365 or other legal requirement. 1367 7.4.11 Recording of Information Concerning Operation of Time-stamping 1368 Services 1370 The TSA shall ensure that all relevant information concerning the 1371 operation of time-stamping services is recorded for a defined period of 1372 time, in particular for the purpose of providing evidence for the 1373 purposes of legal proceedings. 1375 In particular: 1377 General 1379 a) The specific events and data to be logged shall be documented by the 1380 TSA. 1382 b) The confidentiality and integrity of current and archived records 1383 concerning operation of time-stamping services shall be maintained. 1385 c) Records concerning the operation of time-stamping services shall be 1386 completely and confidentially archived in accordance with disclosed 1387 business practices. 1389 d) Records concerning the operation of time-stamping services shall be 1390 made available if required for the purposes of providing evidence of 1391 the correct operation of the time-stamping services for the purpose of 1392 legal proceedings. 1394 e) The precise time of significant TSA environmental, key management 1395 and clock synchronization events shall be recorded. 1397 f) Records concerning time-stamping services shall be held for a period 1398 of time after the expiration of the validity of the TSA's signing key 1399 as appropriate for providing necessary legal evidence and as notified 1400 in the TSA disclosure statement (see section 7.1.2). 1402 g) The events shall be logged in a way that they cannot be easily 1403 deleted or destroyed (except if reliably transferred to long-term 1404 media) within the period of time that they are required to be held. 1406 NOTE: This may be achieved, for example, through the use of write-only 1407 media, a record of each removable media used and the use of off-site 1408 backup. 1410 h) Any information recorded about subscribers shall be kept 1411 confidential except as where agreement is obtained from the subscriber 1412 for its wider publication. 1414 TSA key management 1416 i) Records concerning all events relating to the life-cycle of TSA keys 1417 shall be logged. 1419 j) Records concerning all events relating to the life-cycle of TSA 1420 certificates (if appropriate) shall be logged. 1421 Clock Synchronization 1423 k) Records concerning all events relating to synchronization of the 1424 TSA's clock to UTC shall be logged. This shall include information 1425 concerning normal re-calibration or synchronization of clocks use in 1426 time-stamping. 1428 l) Records concerning all events relating to detection of loss of 1429 synchronization shall be logged. 1431 7.5 Organizational 1433 The TSA shall ensure that its organization is reliable. 1435 In particular that: 1437 a) Policies and procedures under which the TSA operates shall be non- 1438 discriminatory. 1440 b) The TSA shall make its services accessible to all applicants whose 1441 activities fall within its declared field of operation and that agree 1442 to abide by their obligations as specified in the TSA disclosure 1443 statement. 1445 c) The TSA is a legal entity according to national law. 1447 d) The TSA has a system or systems for quality and information security 1448 management appropriate for the time-stamping services it is providing. 1450 e) The TSA has adequate arrangements to cover liabilities arising from 1451 its operations and/or activities. 1453 f) It has the financial stability and resources required to operate in 1454 conformity with this policy. 1456 NOTE 1: This includes requirements for TSA termination identified in 1457 section 7.4.9. 1459 g) It employs a sufficient number of personnel having the necessary 1460 education, training, technical knowledge and experience relating to the 1461 type, range and volume of work necessary to provide time-stamping 1462 services. 1464 NOTE 2: Personnel employed by a TSA include individual personnel 1465 contractually engaged in performing functions in support of the TSA's 1466 time-stamping services. Personnel who may be involved only in 1467 monitoring the TSA services need not be TSA personnel. 1469 h) It has policies and procedures for the resolution of complaints and 1470 disputes received from customers or other parties about the 1471 provisioning of the time-stamping services or any other related 1472 matters. 1474 i) It has a properly documented agreement and contractual relationship 1475 in place where the provisioning of services involves subcontracting, 1476 outsourcing or other third party arrangements. 1478 8. Acknowledgments 1480 The development of this document was supported by ETSI and the 1481 European Commission. Special thanks are due to Nick Pope and Franco 1482 Ruggieri for their valuable inputs. 1484 9. References 1486 [CWA 14167-2] CEN Workshop Agreement 14167-2: Cryptographic Module 1487 for CSP Signing Operations - Protection Profile 1488 (MCSO-PP). 1490 [CWA 14172] CEN Workshop Agreement 14172: EESSI Conformity 1491 Assessment Guidance. 1493 [Dir 95/46/EC] Directive 95/46/EC of the European Parliament and 1494 of the Council of 24 October 1995 on the protection 1495 of individuals with regard to the processing of 1496 personal data and on the free movement of such data. 1498 [Dir 99/93/EC] Directive 1999/93/EC of the European Parliament and 1499 of the Council of 13 December 1999 on a Community 1500 framework for electronic signatures. 1502 [FIPS 140-1] FIPS PUB 140-1 (1994): Security Requirements for 1503 Cryptographic Modules. 1505 [ISO 15408] ISO/IEC 15408 (1999) (parts 1 to 3): 1506 Information technology - Security techniques ū 1507 Evaluation criteria for IT security. 1509 [ISO 17799] ISO/IEC 17799: Information technology ū 1510 Code of practice for information security management 1512 [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate 1513 Requirement Levels", BCP 14, RFC 2119, March 1997. 1515 [RFC 3126] D. Pinkas, J. Ross, N. Pope. "Electronic Signature 1516 Formats for long term electronic signatures". 1517 RFC 3126. September 2001. 1519 [RFC 3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, 1520 "Internet X.509 Public Key Infrastructure Time-Stamp 1521 Protocol (TSP)", RFC 3161, August 2001. 1523 [TF.460-5] ITU-R Recommendation TF.460-5 (1997): 1524 Standard-frequency and time-signal emissions. 1526 [TF.536-1] ITU-R Recommendation TF.536-1 (1998): 1527 Time-scale notations. 1529 [TS 101733] ETSI Technical Standard TS 101 733 V.1.2.2 (2000-12) 1530 Electronic Signature Formats. Note: copies of ETSI 1531 TS 101 733 can be freely downloaded from the ETSI web 1532 site www.etsi.org. 1534 [TS 101861] ETSI Technical Standard TS 101 861 V1.2.1. (2001-11). 1535 Time stamping profile. Note: copies of ETSI TS 101 861 1536 can be freely downloaded from the ETSI web site 1537 www.etsi.org. 1539 [TS 102023] ETSI Technical Standard TS 102 023 V1.1.1 (2002-01). 1540 Policy requirements for Time-Stamping Authorities. 1541 Note: copies of ETSI TS 102 023 can be freely 1542 downloaded from the ETSI web site www.etsi.org. 1544 10. Authors' addresses 1546 This Informational RFC has been produced in ETSI ESI. 1548 ETSI 1549 F-06921 Sophia Antipolis, Cedex - FRANCE 1550 650 Route des Lucioles - Sophia Antipolis 1551 Valbonne - France 1552 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 1553 secretariat@etsi.fr 1554 http://www.etsi.org 1556 Contact Point 1558 Gerry Mc Auley 1559 ETSI 1560 650 Route des Lucioles 1561 F-06921 Sophia Antipolis, Cedex 1562 FRANCE 1564 EMail: Gerry.McAuley@etsi.fr 1566 Denis Pinkas 1567 Bull 1568 68, Route de Versailles 1569 78434 Louveciennes CEDEX 1570 FRANCE 1572 EMail: Denis.Pinkas@bull.net 1574 John Ross 1575 Security & Standards 1576 192 Moulsham Street 1577 Chelmsford, Essex 1578 CM2 0LG 1579 United Kingdom 1581 EMail: ross@secstan.com 1583 Annex A (informative): Coordinated Universal Time 1585 Coordinated Universal Time (UTC) is the international time standard 1586 that became effective on January 1, 1972. UTC has superseded Greenwich 1587 Mean Time (GMT), but in practice they are never more than 1 second 1588 different. Hence many people continue to refer to GMT when in fact they 1589 operate to UTC. 1591 Zero (0) hours UTC is midnight in Greenwich, England, which lies on the 1592 zero longitudinal meridian. Universal time is based on a 24 hour clock, 1593 therefore, afternoon hours such as 4 pm UTC are expressed as 16:00 UTC 1594 (sixteen hours, zero minutes). 1596 International Atomic Time (TAI) is calculated by the Bureau 1597 International des Poids et Mesures (BIPM) from the readings of more 1598 than 200 atomic clocks located in metrology institutes and 1599 observatories in more than 30 countries around the world. Information 1600 on TAI is made available every month in the BIPM Circular T 1601 (ftp://62.161.69.5/pub/tai/publication). It is that TAI does not lose 1602 or gain with respect to an imaginary perfect clock by more than about 1603 one tenth of a microsecond (0.0000001 second) per year. 1605 Coordinated Universal Time (UTC): Time scale, based on the second, as 1606 defined and recommended by the International Telecommunications Radio 1607 Committee (ITU-R), and maintained by the Bureau International des Poids 1608 et Mesures (BIPM). The maintenance by BIPM includes cooperation among 1609 various national laboratories around the world. The full definition of 1610 UTC is contained in ITU-R Recommendation TF.460-4. 1612 Atomic Time, with the unit of duration the Systeme International (SI) 1613 second defined as the duration of 9 192 631 770 cycles of radiation, 1614 corresponds to the transition between two hyperfine levels of the 1615 ground state of caesium 133. TAI is the International Atomic Time 1616 scale, a statistical timescale based on a large number of atomic 1617 clocks. 1619 Universal Time (UT) is counted from 0 hours at midnight, with unit of 1620 duration the mean solar day, defined to be as uniform as possible 1621 despite variations in the rotation of the Earth. 1623 - UT0 is the rotational time of a particular place of observation. 1624 It is observed as the diurnal motion of stars or extraterrestrial 1625 radio sources. 1627 - UT1 is computed by correcting UT0 for the effect of polar motion 1628 on the longitude of the observing site. It varies from uniformity 1629 because of the irregularities in the Earth's rotation. 1630 UT1, is based on the somewhat irregular rotation of the Earth. 1631 Rotational irregularities usually result in a net decrease in the 1632 Earth's average rotational velocity, and ensuing lags of UT1 with 1633 respect to UTC. 1635 Coordinated Universal Time (UTC) is the basis for international time- 1636 keeping and follows TAI exactly except for an integral number of 1637 seconds, 32 in year 2001. These leap seconds are inserted on the advice 1638 of the International Earth Rotation Service (IERS) 1639 (http://hpiers.obspm.fr/) to ensure that, having taken into account 1640 irregularities, the Sun is overhead within 0,9 seconds of 12:00:00 UTC 1641 on the meridian of Greenwich. UTC is thus the modern successor of 1642 Greenwich Mean Time, GMT, which was used when the unit of time was the 1643 mean solar day. 1645 Adjustments to the atomic, i.e., UTC, time scale consist of an 1646 occasional addition or deletion of one full second, which is called a 1647 leap second. Twice yearly, during the last minute of the day of June 30 1648 and December 31, Universal Time, adjustments may be made to ensure that 1649 the accumulated difference between UTC and UT1 will not exceed 0,9 s 1650 before the next scheduled adjustment. Historically, adjustments, when 1651 necessary, have usually consisted of adding an extra second to the UTC 1652 time scale in order to allow the rotation of the Earth to "catch up." 1653 Therefore, the last minute of the UTC time scale, on the day when an 1654 adjustment is made, will have 61 seconds. 1656 Coordinated Universal Time (UTC) differs thus from TAI by an integral 1657 number of seconds. UTC is kept within 0,9 s of UT1 by the introduction 1658 of one-second steps to UTC, the "leap second." To date these steps have 1659 always been positive. 1661 Annex B (informative): Possible for Implementation Architectures ū 1662 Time-stamping Services 1664 B.1 Managed Time-stamping Service 1666 Some organizations may be willing to host one or more Time-Stamping 1667 Authorities and take advantage of both the proximity and the quality of 1668 the Time-Stamping Service, without being responsible for the 1669 installation, operation and management of these Time-Stamping 1670 Authorities. 1672 This can be achieved by using units that are installed in the premises 1673 from the hosting organization and then remotely managed by a Time- 1674 Stamping Service provider that takes the overall responsibility of the 1675 quality of the service delivered to the hosting organization. 1677 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1678 + + 1679 + Time-Stamping Authority + 1680 + + 1681 + + 1682 +_____________ _____________ _____________+ 1683 |+ __________ | | | | __________ +| 1684 |+| | | | Time - | | | |+| 1685 |+| Time - |<-------------| Stamping |------------->| Time - |+| 1686 |+| Stamping | | Install. | Management | Install. | | Stamping |+| 1687 |+| Unit | | Management | | Management | | Unit |+| 1688 |+|__________| | |_____________| | |__________|+| 1689 |+ | | +| 1690 |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 1691 | Hosting | | Hosting | 1692 | Organization | | Organization | 1693 |______________| |______________| 1695 Figure B.1: Managed Time-stamping Service 1697 The requirements for time-stamping services described in the current 1698 document includes requirements on both the time-stamping management and 1699 for the operation of the unit which issues the time-stamp tokens. The 1700 TSA, as identified in the time-stamp token, has the responsibility to 1701 ensure that these requirements are met (for example through contractual 1702 obligations). 1704 It should be clear that the hosting organization will generally want to 1705 be able to monitor the use of the service and, at a minimum, know 1706 whether the service is working or not and even be able to measure the 1707 performances of the service, e.g. the number of time-stamps generated 1708 during some period of time. Such monitoring can be considered to be 1709 outside of TSA's time-stamping service. 1711 Therefore the description of the management operation described in the 1712 main body of the document is not limitative. Monitoring operations, if 1713 performed directly on the unit, may be permitted by the Time-Stamping 1714 service provider. 1716 B.2 Selective Alternative Quality 1718 Some relying parties may be willing to take advantage of particular 1719 characteristics from a time-stamp token such as a specific signature 1720 algorithm and/or key length or a specific accuracy for the time 1721 contained in the time stamp token. These parameters can be considered 1722 as specifying a "quality" for the time stamp token. 1724 Time stamp tokens with various qualities may be issued by different 1725 time-stamping units operated by the same or different TSAs. 1727 A particular time-stamping unit will only provide one combination of 1728 algorithm and key length (since a time-stamping unit is a set of 1729 hardware and software which is managed as a unit and has a single time- 1730 stamp token signing key). In order to obtain different combinations of 1731 algorithm and key length, different time-stamping units shall be used. 1733 A particular time-stamping unit may provide a fixed accuracy for the 1734 time contained in the time stamp token or different accuracy if 1735 instructed to do so either by using a specific mode of access (e.g. e- 1736 mail or http) or by using specific parameters in the request. 1738 Policy requirements for Time-Stamping Authorities March 2002 1740 Annex C (informative): Long Term Verification of time-stamp tokens 1742 Usually, a time-stamp token becomes unverifiable beyond the end of the 1743 validity period of the certificate from the TSA, because the CA that 1744 has issued the certificate does not warrant any more that it will 1745 publish revocation data, including data about revocations due to key 1746 compromises. However, verification of a time-stamp token might still be 1747 performed beyond the end of the validity period of the certificate from 1748 the TSA, if, at the time of verification, it can be known that: 1750 - the TSA private key has not been compromised at any time up to the 1751 time that a relying part verifies a time-stamp token; 1753 - the hash algorithms used in the time-stamp token exhibits no 1754 collisions at the time of verification; 1756 - the signature algorithm and signature key size under which the 1757 time-stamp token has been signed is still beyond the reach of 1758 cryptographic attacks at the time of verification. 1760 If these conditions cannot be met, then the validity may be maintained 1761 by applying an additional time-stamp to protect the integrity of the 1762 previous one. 1764 The present document does not specify the details of how such 1765 protection may be obtained. For the time being, and until some 1766 enhancements are defined to support these features, the information may 1767 be obtained using-out-of bands means or alternatively in the context of 1768 closed environments. As an example, should a CA guaranty to maintain 1769 the revocation status of TSA certificate after the end of its validity 1770 period, this would fulfil the first requirement. 1772 NOTE 1: An alternative to Time-Stamping is for a Trusted Service 1773 Provider to record a representation of a datum bound to a particular 1774 time in an audit trail, thus establishing evidence that the datum 1775 existed before that time. This technique, which is called Time-Marking, 1776 can be a valuable alternative for checking the long term validity of 1777 signatures. 1779 NOTE 2: The TSA or other trusted third party service provider may 1780 support the verification of time-stamp tokens. 1782 Annex D (informative): Model TSA disclosure statement structure. 1784 The TSA disclosure statement contains a section for each defined 1785 statement type. Each section of a TSA disclosure statement contains a 1786 descriptive statement, which MAY include hyperlinks to the relevant 1787 certificate policy/certification practice statement sections. 1789 D.1. STATEMENT TYPE: Entire agreement 1791 STATEMENT DESCRIPTION: A statement indicating that the disclosure 1792 statement is not the entire agreement, but only a part of it. 1794 D.2. STATEMENT TYPE: TSA contact info 1796 STATEMENT DESCRIPTION: The name, location and relevant contact 1797 information for the TSA. 1799 D.3. STATEMENT TYPE: time-stamp token types and usage 1801 STATEMENT DESCRIPTION: A description of each class/type of 1802 time-stamp tokens issued by the TSA (in accordance with each 1803 time-stamp policy) and any restrictions on time-stamp usage. 1805 SPECIFIC REQUIREMENT: Indication of the policy being applied, 1806 including the contexts for which the time-stamp token can be used 1807 (e.g. only for use with electronic signatures), the hashing 1808 algorithms, the expected life time of the time-stamp token 1809 signature, any limitations on the use of the time-stamp token and 1810 information on how to verify the time-stamp token. 1812 D.4. STATEMENT TYPE: Reliance limits. 1814 STATEMENT DESCRIPTION: reliance limits, if any. 1816 SPECIFIC REQUIREMENT: Indication of the accuracy of the time in 1817 the time-stamp token, and the period of time for which TSA event 1818 logs (see section 7.4.10) are maintained (and hence are available 1819 to provide supporting evidence). 1821 D.5. STATEMENT TYPE: Obligations of subscribers. 1823 STATEMENT DESCRIPTION: The description of, or reference to, the 1824 critical subscriber obligations. 1826 SPECIFIC REQUIREMENT: No specific requirements identified in the 1827 current document. Where applicable the TSA may specify additional 1828 obligations. 1830 D.6. STATEMENT TYPE: TSA public key status checking obligations of 1831 relying parties. 1833 STATEMENT DESCRIPTION: The extent to which relying parties are 1834 obligated to check the TSA public key status, and references to 1835 further explanation. 1837 SPECIFIC REQUIREMENT: Information on how to validate the TSA 1838 public key status, including requirements to check the revocation 1839 status of TSA public key, such that the relying party is 1840 considered to "reasonably rely" on the time-stamp token (see 1841 section 6.3). 1843 D.7. STATEMENT TYPE: Limited warranty and disclaimer/Limitation of 1844 liability. 1846 STATEMENT DESCRIPTION: Summary of the warranty, disclaimers, 1847 limitations of liability and any applicable warranty or insurance 1848 programs 1850 SPECIFIC REQUIREMENT: Limitations of liability (see section 6.4). 1852 D.8. STATEMENT TYPE: Applicable agreements and practice statement. 1854 STATEMENT DESCRIPTION: Identification and references to applicable 1855 agreements, practice statement, time-stamp policy and other 1856 relevant documents. 1858 D.9. STATEMENT TYPE: Privacy policy. 1860 STATEMENT DESCRIPTION: A description of and reference to the 1861 applicable privacy policy. 1863 SPECIFIC REQUIREMENT: Note: TSA's under this policy are required 1864 to comply with the requirements of Data Protection Legislation. 1866 D.10. STATEMENT TYPE: Refund policy 1868 STATEMENT DESCRIPTION: A description of and reference to the 1869 applicable refund policy. 1871 D.11. STATEMENT TYPE: Applicable law, complaints and dispute resolution 1872 mechanisms. 1874 STATEMENT DESCRIPTION: Statement of the choice of law, complaints 1875 procedure and dispute resolution mechanisms. 1877 SPECIFIC REQUIREMENT: The procedures for complaints and dispute 1878 settlements. The applicable legal system. 1880 D.12. STATEMENT TYPE: TSA and repository licenses, trust marks, and 1881 audit. 1883 STATEMENT DESCRIPTION: Summary of any governmental licenses, seal 1884 programs; and a description of the audit process and if 1885 applicable the audit firm. 1887 SPECIFIC REQUIREMENT: If the TSA has been assessed to be 1888 conformant with the identified time-stamp policy, and if so 1889 through which independent party. 1891 Full Copyright Statement 1893 Copyright (C) The Internet Society (2001). All Rights Reserved. 1895 This document and translations of it may be copied and furnished to 1896 others, and derivative works that comment on or otherwise explain it 1897 or assist in its implementation may be prepared, copied, published 1898 and distributed, in whole or in part, without restriction of any 1899 kind, provided that the above copyright notice and this paragraph 1900 are included on all such copies and derivative works. However, this 1901 document itself may not be modified in any way, such as by removing 1902 the copyright notice or references to the Internet Society or other 1903 Internet organizations, except as needed for the purpose of 1904 developing Internet standards in which case the procedures for 1905 copyrights defined in the Internet Standards process must be 1906 followed, or as required to translate it into languages other than 1907 English. 1909 The limited permissions granted above are perpetual and will not be 1910 revoked by the Internet Society or its successors or assigns. 1912 This document and the information contained herein is provided on an 1913 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1914 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1915 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1916 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1917 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1919 Acknowledgement 1921 Funding for the RFC Editor function is currently provided by the 1922 Internet Society.