Network Working Group D. Pinkas Request for Comments: 3628 Bull Category: Informational N. Pope J. Ross Security & Standards November 2003 Policy Requirements for Time-Stamping Authorities (TSAs) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 5 3.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6 4. General Concepts. . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Time-Stamping Services . . . . . . . . . . . . . . . . . 6 4.2. Time-Stamping Authority. . . . . . . . . . . . . . . . . 7 4.3. Subscriber . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Time-Stamp Policy and TSA Practice Statement . . . . . . 8 4.4.1. Purpose. . . . . . . . . . . . . . . . . . . . . 8 4.4.2. Level of Specificity . . . . . . . . . . . . . . 8 4.4.3. Approach . . . . . . . . . . . . . . . . . . . . 8 5. Time-Stamp Policies . . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Identification . . . . . . . . . . . . . . . . . . . . . 9 5.3. User Community and Applicability . . . . . . . . . . . . 10
5.4. Conformance. . . . . . . . . . . . . . . . . . . . . . . 10 6. Obligations and Liability . . . . . . . . . . . . . . . . . . 10 6.1. TSA Obligations. . . . . . . . . . . . . . . . . . . . . 10 6.1.1. General. . . . . . . . . . . . . . . . . . . . . 10 6.1.2. TSA Obligations Towards Subscribers. . . . . . . 11 6.2. Subscriber Obligations . . . . . . . . . . . . . . . . . 11 6.3. Relying Party Obligations. . . . . . . . . . . . . . . . 11 6.4. Liability. . . . . . . . . . . . . . . . . . . . . . . . 11 7. Requirements on TSA Practices . . . . . . . . . . . . . . . . 12 7.1. Practice and Disclosure Statements . . . . . . . . . . . 12 7.1.1. TSA Practice Statement . . . . . . . . . . . . . 12 7.1.2. TSA Disclosure Statement . . . . . . . . . . . . 13 7.2. Key Management Life Cycle. . . . . . . . . . . . . . . . 15 7.2.1. TSU Key Generation . . . . . . . . . . . . . . . 15 7.2.2. TSU Private Key Protection . . . . . . . . . . . 15 7.2.3. TSU Public Key Distribution. . . . . . . . . . . 16 7.2.4. Rekeying TSU's Key . . . . . . . . . . . . . . . 17 7.2.5. End of TSU Key Life Cycle. . . . . . . . . . . . 17 7.2.6. Life Cycle Management of the Cryptographic Module used to Sign Time-Stamps . . . . . . . . . . . . 17 7.3. Time-Stamping. . . . . . . . . . . . . . . . . . . . . . 18 7.3.1. Time-Stamp Token . . . . . . . . . . . . . . . . 18 7.3.2. Clock Synchronization with UTC . . . . . . . . . 19 7.4. TSA Management and Operation . . . . . . . . . . . . . . 20 7.4.1. Security Management. . . . . . . . . . . . . . . 20 7.4.2. Asset Classification and Management. . . . . . . 21 7.4.3. Personnel Security . . . . . . . . . . . . . . . 22 7.4.4. Physical and Environmental Security. . . . . . . 23 7.4.5. Operations Management. . . . . . . . . . . . . . 25 7.4.6. System Access Management . . . . . . . . . . . . 26 7.4.7. Trustworthy Systems Deployment and Maintenance . 27 7.4.8. Compromise of TSA Services . . . . . . . . . . . 28 7.4.9. TSA Termination. . . . . . . . . . . . . . . . . 29 7.4.10. Compliance with Legal Requirements . . . . . . . 29 7.4.11. Recording of Information Concerning Operation of Time-Stamping Services. . . . . . . . . . . . 30 7.5. Organizational . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References. . . . . . . . . . . . . . . . . . 33 10.2. Informative References. . . . . . . . . . . . . . . . . 34 Annex A (informative): Coordinated Universal Time . . . . . . . . 35 Annex B (informative): Possible for Implementation Architectures and Time-Stamping Services . . . . . . . . 36 Annex C (informative): Long Term Verification of Time-Stamp Tokens . . . . . . . . . . . . . . . . . . 38 Annex D (informative): Model TSA Disclosure Statement . . . . . . 39
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 42 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 43 TS 102023]. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org In creating reliable and manageable digital evidence it is necessary to have an agreed upon method of associating time data to transaction so that they might be compared to each other at a later time. The quality of this evidence is based on creating and managing the data structure that represent the events and the quality of the parametric data points that anchor them to the real world. In this instance this being the time data and how it was applied. A typical transaction is a digitally signed document, where it is necessary to prove that the digital signature from the signer was applied when the signer's certificate was valid. A timestamp or a time mark (which is an audit record kept in a secure audit trail from a trusted third party) applied to a digital signature value proves that the digital signature was created before the date included in the time-stamp or time mark. To prove the digital signature was generated while the signer's certificate was valid, the digital signature must be verified and the following conditions satisfied: 1. the time-stamp (or time mark) was applied before the end of the validity period of the signer's certificate, 2. the time-stamp (or time mark) was applied either while the signer's certificate was not revoked or before the revocation date of the certificate. Thus a time-stamp (or time mark) applied in this manner proves that the digital signature was created while the signer's certificate was valid. This concept proves the validity of a digital signature over the whole of any certificate chain. Policy requirements to cover that case is the primary reason of this document. However, it should be observed that these policy requirements can be used to address other needs.
The electronic time stamp is gaining interest from the business sector as an important component of electronic signatures. It is also featured by the ETSI Electronic Signature Format standard [TS 101733] or Electronic Signature Formats for long term electronic signatures [RFC 3126], built upon the Time-Stamp Protocol [RFC 3161]. Agreed minimum security and quality requirements are necessary in order to ensure trustworthy validation of long-term electronic signatures. The European Directive 1999/93/EC [Dir 99/93/EC] defines certification service provider as "an entity or a legal or natural person who issues certificates or provides other services related to electronic signatures". One example of a certification-service- provider is a Time-Stamping Authority. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC 2119].
NOTE 1: A time-stamping protocol is defined in RFC 3161 [RFC 3161] and profiled in TS 101 861 [TS 101861]. - how the requirements identified herein may be assessed by an independent body; - requirements for information to be made available to such independent bodies; - requirements on such independent bodies. NOTE 2: See CEN Workshop Agreement 14172 "EESSI Conformity Assessment Guidance" [CWA 14172].
time-stamp policy: named set of rules that indicates the applicability of a time-stamp token to a particular community and/or class of application with common security requirements. time-stamping unit: set of hardware and software which is managed as a unit and has a single time-stamp token signing key active at a time. Coordinated Universal Time (UTC): Time scale based on the second as defined in ITU-R Recommendation TF.460-5 [TF.460-5]. NOTE: For most practical purposes UTC is equivalent to mean solar time at the prime meridian. More specifically, UTC is a compromise between the highly stable atomic time (Temps Atomique International - TAI) and solar time derived from the irregular Earth rotation (related to the Greenwich mean sidereal time (GMST) by a conventional relationship). (See annex A for more details). UTC(k): Time-scale realized by the laboratory "k" and kept in close agreement with UTC, with the goal to reach plus or minus 100 ns. (See ITU-R Recommendation TF.536-1 [TF.536-1]). NOTE: A list of UTC(k) laboratories is given in section 1 of Circular T disseminated by BIPM and available from the BIPM website (http://www.bipm.org/).
- Time-stamping management: The service component that monitors and controls the operation of the time-stamping services to ensure that the service is provided as specified by the TSA. This service component is responsibile for the installation and de-installation of the time-stamping provision service. For example, time-stamping management ensures that the clock used for time-stamping is correctly synchronized with UTC. This subdivision of services is only for the purposes of clarifying the requirements specified in the current document and places no restrictions on any subdivision of an implementation of time-stamping services. Annex B for possible implementations. A TSA is a certification-service-provider, as defined in the EU Directive on Electronic Signatures (see article 2(11)), which issues time-stamp tokens.
obligations from the end-users are not correctly fulfilled and therefore the organization is expected to suitably inform its end users. When the subscriber is an end-user, the end-user will be held directly responsible if its obligations are not correctly fulfilled.
TSA, whereas a TSA practice statement is tailored to the organizational structure, operating procedures, facilities, and computing environment of a TSA. A time-stamp policy may be defined by the user of times-stamp services, whereas the TSA practice statement is always defined by the provider. Annex C on verification of the validity of a time-stamp token beyond the validity period of the TSU's certificate. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document. If an accuracy of better than 1 second is provided by a TSA and if all the TSUs have that same characteristics, then the accuracy shall be indicated in the TSA's disclosure statement (see section 7.1.2) that each time-stamp token is issued with an accuracy of better than 1 second. NOTE 2: It is required that a time-stamp token includes an identifier for the applicable policy (see section 7.3.1). X.208] of the baseline time-stamp policy is: itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) policy-identifiers(1) baseline-ts-policy (1) In the TSA disclosure statement made available to subscribers and relying parties, a TSA shall also include the identifier for the time-stamp policy to indicate its conformance.
TS 101733]), but is generally applicable to any requirement for an equivalent quality. This policy may be used for public time-stamping services or time- stamping services used within a closed community. section 5.2, or define its own time-stamp policy that incorporates or further constrains the requirements identified in the present document: a) if the TSA claims conformance to the identified time-stamp policy and makes available to subscribers and relying parties on request the evidence to support the claim of conformance; or b) if the TSA has been assessed to conform to the identified time- stamp policy by an independent party. A conformant TSA must demonstrate that: a) it meets its obligations as defined in section 6.1; b) it has implemented controls which meet the requirements specified in section 7. section 7, are implemented as applicable to the selected trusted time-stamp policy. The TSA shall ensure conformance with the procedures prescribed in this policy, even when the TSA functionality is undertaken by sub- contractors. The TSA shall also ensure adherence to any additional obligations indicated in the time-stamp either directly or incorporated by reference.
The TSA shall provide all its time-stamping services consistent with its practice statement. section 7.1.2) shall include an obligation on the relying party that, when relying on a time-stamp token, it shall: a) verify that the time-stamp token has been correctly signed and that the private key used to sign the time-stamp has not been compromised until the time of the verification; NOTE: During the TSU's certificate validity period, the validity of the signing key can be checked using current revocation status for the TSU's certificate. If the time of verification exceeds the end of the validity period of the corresponding certificate, see annex C for guidance. b) take into account any limitations on the usage of the time-stamp indicated by the time-stamp policy; c) take into account any other precautions prescribed in agreements or elsewhere.
section 7.4 (TSA management and operation), a reference is made to a source of more detailed control requirements. Due to these factors the specificity of the requirements given under a given topic may vary. The provision of a time-stamp token in response to a request is at the discretion of the TSA depending on any service level agreements with the subscriber.
c) The TSA's practice statement shall identify the obligations of all external organizations supporting the TSA services including the applicable policies and practices. d) The TSA shall make available to subscribers and relying parties its practice statement, and other relevant documentation, as necessary, to assess conformance to the time-stamp policy. NOTE 2: The TSA is not generally required to make all the details of its practices public. e) The TSA shall disclose to all subscribers and potential relying parties the terms and conditions regarding use of its time- stamping services as specified in section 7.1.2. f) The TSA shall have a high level management body with final authority for approving the TSA practice statement. g) The senior management of the TSA shall ensure that the practices are properly implemented. h) The TSA shall define a review process for the practices including responsibilities for maintaining the TSA practice statement. i) The TSA shall give due notice of changes it intends to make in its practice statement and shall, following approval as in (f) above, make the revised TSA practice statement immediately available as required under (d) above.
e) The accuracy of the time in the time-stamp tokens with respect to UTC. f) Any limitations on the use of the time-stamping service. g) The subscriber's obligations as defined in section 6.2, if any. h) The relying party's obligations as defined in section 6.3. i) Information on how to verify the time-stamp token such that the relying party is considered to "reasonably rely" on the time-stamp token (see section 6.3) and any possible limitations on the validity period. j) The period of time during which TSA event logs (see section 7.4.10) are retained. k) The applicable legal system, including any claim to meet the requirements on time-stamping services under national law. l) Limitations of liability. m) Procedures for complaints and dispute settlement. n) If the TSA has been assessed to be conformant with the identified time-stamp policy, and if so by which independent body. NOTE 1: It is also recommended that the TSA includes in its time-stamping disclosure statement availability of its service, for example the expected mean time between failure of the time- stamping service, the mean time to recovery following a failure, and provisions made for disaster recovery including back-up services; This information shall be available through a durable means of communication. This information shall be available in a readily understandable language. It may be transmitted electronically. NOTE 2: A model TSA disclosure statement which may be used as the basis of such a communication is given in annex D. Alternatively this may be provided as part of a subscriber / relying party agreement. These TSA disclosure statements may be included in a TSA practice statement provided that they are conspicuous to the reader.
section 7.4.4) by personnel in trusted roles (see section 7.4.3) under, at least, dual control. The personnel authorized to carry out this function shall be limited to those requiring to do so under the TSA's practices. b) The generation of the TSU's signing key(s) shall be carried out within a cryptographic module(s) which either: - meets the requirements identified in FIPS 140-1 [FIPS 140-1] level 3 or higher, or - meets the requirements identified in CEN Workshop Agreement 14167-2 [CWA 14167-2], or - is a trustworthy system which is assured to EAL 4 or higher in accordance to ISO 15408 [ISO 15408], or equivalent security criteria. This shall be to a security target or protection profile which meets the requirements of the current document, based on a risk analysis and taking into account physical and other non-technical security measures. c) The TSU key generation algorithm, the resulting signing key length and signature algorithm used for signing time-stamp tokens key shall be recognized by any national supervisory body, or in accordance with existing current state of art, as being fit for the purposes of time-stamp tokens as issued by the TSA.
- meets the requirements identified in FIPS 140-1 [FIPS 140-1] level 3 or higher; or - meets the requirements identified in CEN Workshop Agreement 14167-2 [CWA 14167-2]; or - is a trustworthy system which is assured to EAL 4 or higher in accordance to ISO 15408 [ISO 15408], or equivalent security criteria. This shall be a security target or protection profile which meets the requirements of the current document, based on a risk analysis and taking into account physical and other non-technical security measures. NOTE: Backup of TSU private keys is deprecated in order to minimize risk of key compromise. b) If TSU private keys are backed up, they shall be copied, stored and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment. (see section 7.4.4). The personnel authorized to carry out this function shall be limited to those requiring to do so under the TSA's practices. c) Any backup copies of the TSU private signing keys shall be protected to ensure its confidentiality by the cryptographic module before being stored outside that device.
section 7.2.1c)). NOTE 1: The following additional considerations apply when limiting that lifetime: - Section 7.4.10 requires that records concerning time-stamping services shall be held for a period of time,as appropriate, for at least 1 year after the expiration of the validity of the TSU's signing keys. The longer the validity period of the TSU certificates will be, the longer the size of the records to be kept will be. - Should a TSU private key be compromised, then the longer the life-time, the more affected time-stamp tokens there will be. NOTE 2: TSU key compromise does not only depend on the characteristics of the cryptographic module being used but also on the procedures being used at system initialization and key export (when that function is supported).
In particular the TSA shall ensure that: a) Time-stamp token signing cryptographic hardware is not tampered with during shipment; b) Time-stamp token signing cryptographic hardware is not tampered with while stored; c) Installation, activation and duplication of TSU's signing keys in cryptographic hardware shall be done only by personnel in trusted roles using, at least, dual control in a physically secured environment. (see section 7.4.4); d) Time-stamp token signing cryptographic hardware is functioning correctly; and e) TSU private signing keys stored on TSU cryptographic module are erased upon device retirement.
d) The time included in the time-stamp token shall be synchronized with UTC within the accuracy defined in this policy and, if present, within the accuracy defined in the time-stamp token itself; e) If the time-stamp provider's clock is detected (see section 7.3.2c)) as being out of the stated accuracy (see section 7.1.2e)) then time-stamp tokens shall not be issued. f) The time-stamp token shall include a representation (e.g., hash value) of the datum being time-stamped as provided by the requestor; g) The time-stamp token shall be signed using a key generated exclusively for this purpose. NOTE 2: A protocol for a time-stamp token is defined in RFC 3631 and profiled in TS 101 861 [TS 101861]. NOTE 3: In the case of a number of requests at approximately the same time, the ordering of the time within the accuracy of the TSU clock is not mandated. h) The time-stamp token shall include: - where applicable, an identifier for the country in which the TSA is established; - an identifier for the TSA; - an identifier for the unit which issues the time-stamps.
NOTE 1: Threats may include tampering by unauthorized personnel, radio or electrical shocks. c) The TSA shall ensure that, if the time that would be indicated in a time-stamp token drifts or jumps out of synchronization with UTC, this will be detected (see also 7.3.1e)). NOTE 2: Relying parties are required to be informed of such events (see section 7.4.8). d) The TSA shall ensure that clock synchronization is maintained when a leap second occurs as notified by the appropriate body. The change to take account of the leap second shall occur during the last minute of the day when the leap second is scheduled to occur. A record shall be maintained of the exact time (within the declared accuracy) when this change occurred. See annex A for more details. NOTE 3: A leap second is an adjustment to UTC by skipping or adding an extra second on the last second of a UTC month. First preference is given to the end of December and June, and second preference is given to the end of March and September.
b) The TSA management shall provide direction on information security through a suitable high level steering forum that is responsible for defining the TSA's information security policy. The TSA shall ensure publication and communication of this policy to all employees who are impacted by it. c) The information security infrastructure necessary to manage the security within the TSA shall be maintained at all times. Any changes that will impact on the level of security provided shall be approved by the TSA management forum. NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on information security management including information security infrastructure, management information security forum and information security policies. d) The security controls and operating procedures for TSA facilities, systems and information assets providing the time-stamping services shall be documented, implemented and maintained. NOTE 2: The present documentation (commonly called a system security policy or manual) should identify all relevant targets, objects and potential threats related to the services provided and the safeguards required to avoid or limit the effects of those threats, consistent with the Risk Assessment required under section 7.1.1a). It should describe the rules, directives and procedures regarding how the specified services and the associated security assurance are granted in addition to stating policy on incidents and disasters. e) TSA shall ensure that the security of information is maintained when the responsibility for TSA functions has been outsourced to another organization or entity.
section 7.4.1). NOTE 3: See ISO/IEC 17799 [ISO 17799] for guidance. The following additional controls shall be applied to time- stamping management: e) Managerial personnel shall be employed who possess: - knowledge of time-stamping technology; and - knowledge of digital signature technology; and
- knowledge of mechanisms for calibration or synchronization the TSU clocks with UTC; and - familiarity with security procedures for personnel with security responsibilities; and - experience with information security and risk assessment. f) All TSA personnel in trusted roles shall be free from conflict of interest that might prejudice the impartiality of the TSA operations. g) Trusted roles include roles that involve the following responsibilities: - Security Officers: Overall responsibility for administering the implementation of the security practices. - System Administrators: Authorized to install, configure and maintain the TSA trustworthy systems for time-stamping management. - System Operators: Responsible for operating the TSA trustworthy systems on a day-to-day basis. Authorized to perform system backup and recovery. - System Auditors: Authorized to view archives and audit logs of the TSA trustworthy systems. h) TSA personnel shall be formally appointed to trusted roles by senior management responsible for security. i) The TSA shall not appoint to trusted roles or management any person who is known to have a conviction for a serious crime or other offense which affects his/her suitability for the position. Personnel shall not have access to the trusted functions until any necessary checks are completed. NOTE 4: In some countries it may not be possible for TSA to obtain information on past convictions without the collaboration of the candidate employee.
In particular (general): a) For both the time-stamping provision and the time-stamping management: - physical access to facilities concerned with time-stamping services shall be limited to properly authorized individuals; - controls shall be implemented to avoid loss, damage or compromise of assets and interruption to business activities; and - controls shall be implemented to avoid compromise or theft of information and information processing facilities. b) Access controls shall be applied to the cryptographic module to meet the requirements of security of cryptographic modules as identified in clauses 7.2.1 and 7.2.2. c) The following additional controls shall be applied to time- stamping management: - The time-stamping management facilities shall be operated in an environment which physically protects the services from compromise through unauthorized access to systems or data. - Physical protection shall be achieved through the creation of clearly defined security perimeters (i.e., physical barriers) around the time-stamping management. Any parts of the premises shared with other organizations shall be outside this perimeter. - Physical and environmental security controls shall be implemented to protect the facility that houses system resources, the system resources themselves, and the facilities used to support their operation. The TSA's physical and environmental security policy for systems concerned with time- stamping management shall address as a minimum the physical access control, natural disaster protection, fire safety factors, failure of supporting utilities (e.g., power, telecommunications), structure collapse, plumbing leaks, protection against theft, breaking and entering, and disaster recovery. - Controls shall be implemented to protect against equipment, information, media and software relating to the time-stamping services being taken off-site without authorization. NOTE 1: See ISO/IEC 17799 [ISO 17799] for guidance on physical and environmental security.
NOTE 2: Other functions may be supported within the same secured area provided that the access is limited to authorized personnel. section 7.4.2). Media containing sensitive data shall be securely disposed of when no longer required. System Planning f) Capacity demands shall be monitored and projections of future capacity requirements made to ensure that adequate processing power and storage are available.
Incident reporting and response g) The TSA shall act in a timely and coordinated manner in order to respond quickly to incidents and to limit the impact of breaches of security. All incidents shall be reported as soon as possible after the incident. The following additional controls shall be applied to time-stamping management: Operations procedures and responsibilities h) TSA security operations shall be separated from other operations. NOTE 2: TSA security operations' responsibilities include: - operational procedures and responsibilities; - secure systems planning and acceptance; - protection from malicious software; - housekeeping; - network management; - active monitoring of audit journals, event analysis and follow-up; - media handling and security; - data and software exchange. These operations shall be managed by TSA trusted personnel, but, may actually be performed by, non-specialist, operational personnel (under supervision), as defined within the appropriate security policy, and, roles and responsibility documents.
b) The TSA shall ensure effective administration of user (this includes operators, administrators and auditors) access to maintain system security, including user account management, auditing and timely modification or removal of access. c) The TSA shall ensure that access to information and application system functions is restricted in accordance with the access control policy and that the TSA system provides sufficient computer security controls for the separation of trusted roles identified in TSA's practices, including the separation of security administrator and operation functions. Particularly, use of system utility programs is restricted and tightly controlled. d) TSA personnel shall be properly identified and authenticated before using critical applications related to time-stamping. e) TSA personnel shall be accountable for their activities, for example by retaining event logs (see section 7.4.10). The following additional controls shall be applied to time-stamping management: f) The TSA shall ensure that local network components (e.g., routers) are kept in a physically secure environment and that their configurations are periodically audited for compliance with the requirements specified by the TSA. g) Continuous monitoring and alarm facilities shall be provided to enable the TSA to detect, register and react in a timely manner upon any unauthorized and/or irregular attempts to access its resources. NOTE 2: This may use, for example, an intrusion detection system, access control monitoring and alarm facilities. section 7.1.1) should identify its critical services requiring trustworthy systems and the levels of assurance required.
In particular: a) An analysis of security requirements shall be carried out at the design and requirements specification stage of any systems development project undertaken by the TSA or on behalf of the TSA to ensure that security is built into IT systems. b) Change control procedures shall be applied for releases, modifications and emergency software fixes of any operational software.
section 7.4.10) necessary to demonstrate the correct operation of the TSA for a reasonable period; - the TSA shall maintain or transfer to a reliable party its obligations to make available its public key or its certificates to relying parties for a reasonable period; - TSU private keys, including backup copies, shall be destroyed in a manner such that the private keys cannot be retrieved. b) The TSA shall have an arrangement to cover the costs to fulfill these minimum requirements in case the TSA becomes bankrupt or for other reasons is unable to cover the costs by itself. c) The TSA shall state in its practices the provisions made for termination of service. This shall include: - notification of affected entities; - transferring the TSA obligations to other parties. d) The TSA shall take steps to have the TSU's certificates revoked.
In particular: a) The TSA shall ensure that the requirements of the European data protection Directive [Dir 95/46/EC], as implemented through national legislation, are met. b) Appropriate technical and organizational measures shall be taken against unauthorized or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data. c) The information contributed by users to the TSA shall be completely protected from disclosure unless with their agreement or by court order or other legal requirement.
signing keys as appropriate for providing necessary legal evidence and as notified in the TSA disclosure statement (see section 7.1.2). g) The events shall be logged in a way that they cannot be easily deleted or destroyed (except if reliably transferred to long-term media) within the period of time that they are required to be held. NOTE: This may be achieved, for example, through the use of write-only media, a record of each removable media used and the use of off-site backup. h) Any information recorded about subscribers shall be kept confidential except as where agreement is obtained from the subscriber for its wider publication. TSU key management i) Records concerning all events relating to the life-cycle of TSU keys shall be logged. j) Records concerning all events relating to the life-cycle of TSU certificates (if appropriate) shall be logged. Clock Synchronization k) Records concerning all events relating to synchronization of a TSU's clock to UTC shall be logged. This shall include information concerning normal re-calibration or synchronization of clocks use in time-stamping. l) Records concerning all events relating to detection of loss of synchronization shall be logged.
c) The TSA is a legal entity according to national law. d) The TSA has a system or systems for quality and information security management appropriate for the time-stamping services it is providing. e) The TSA has adequate arrangements to cover liabilities arising from its operations and/or activities. f) It has the financial stability and resources required to operate in conformity with this policy. NOTE 1: This includes requirements for TSA termination identified in section 7.4.9. g) It employs a sufficient number of personnel having the necessary education, training, technical knowledge and experience relating to the type, range and volume of work necessary to provide time- stamping services. NOTE 2: Personnel employed by a TSA include individual personnel contractually engaged in performing functions in support of the TSA's time-stamping services. Personnel who may be involved only in monitoring the TSA services need not be TSA personnel. h) It has policies and procedures for the resolution of complaints and disputes received from customers or other parties about the provisioning of the time-stamping services or any other related matters. i) It has a properly documented agreement and contractual relationship in place where the provisioning of services involves subcontracting, outsourcing or other third party arrangements.
private key, all the time-stamp tokens generated by that TSU become invalid. Annex C provides guidance about the long term verification of time-stamp tokens. In applying time-stamping to applications, consideration also needs to be given to the security of the application. In particular, when applying time-stamps it is necessary to ensure that the integrity of data is maintained before the time-stamp is applied. The requester ought to really make sure that the hash value included in the time- stamp token matches with the hash of the data. [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TF.460-5] ITU-R Recommendation TF.460-5 (1997): Standard- frequency and time-signal emissions. [TF.536-1] ITU-R Recommendation TF.536-1 (1998): Time-scale notations. [CWA 14167-2] CEN Workshop Agreement 14167-2: Cryptographic Module for CSP Signing Operations - Protection Profile (MCSO-PP). [FIPS 140-1] FIPS PUB 140-1 (1994): Security Requirements for Cryptographic Modules. [ISO 15408] ISO/IEC 15408 (1999) (parts 1 to 3): Information technology - Security techniques and Evaluation criteria for IT security.
[CWA 14172] CEN Workshop Agreement 14172: EESSI Conformity Assessment Guidance. [Dir 95/46/EC] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. [Dir 99/93/EC] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures. [ISO 17799] ISO/IEC 17799: Information technology Code of practice for information security management [RFC 3126] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001. [RFC 3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [TS 101733] ETSI Technical Specification TS 101 733 V.1.2.2 (2000-12) Electronic Signature Formats. Note: copies of ETSI TS 101 733 can be freely downloaded from the ETSI web site www.etsi.org. [TS 101861] ETSI Technical Specification TS 101 861 V1.2.1. (2001-11). Time stamping profile. Note: copies of ETSI TS 101 861 can be freely downloaded from the ETSI web site www.etsi.org. [TS 102023] ETSI Technical Specification TS 102 023. Policy requirements for Time-Stamping Authorities. Note: copies of ETSI TS 102 023 can be freely downloaded from the ETSI web site www.etsi.org. [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
ftp://126.96.36.199/pub/tai/publication). It is that TAI does not lose or gain with respect to an imaginary perfect clock by more than about one tenth of a microsecond (0.0000001 second) per year. Coordinated Universal Time (UTC): Time scale, based on the second, as defined and recommended by the International Telecommunications Radio Committee (ITU-R), and maintained by the Bureau International des Poids et Mesures (BIPM). The maintenance by BIPM includes cooperation among various national laboratories around the world. The full definition of UTC is contained in ITU-R Recommendation TF.460-4. Atomic Time, with the unit of duration the Systeme International (SI) second defined as the duration of 9 192 631 770 cycles of radiation, corresponds to the transition between two hyperfine levels of the ground state of caesium 133. TAI is the International Atomic Time scale, a statistical timescale based on a large number of atomic clocks. Universal Time (UT) is counted from 0 hours at midnight, with unit of duration the mean solar day, defined to be as uniform as possible despite variations in the rotation of the Earth. - UT0 is the rotational time of a particular place of observation. It is observed as the diurnal motion of stars or extraterrestrial radio sources. - UT1 is computed by correcting UT0 for the effect of polar motion on the longitude of the observing site. It varies from uniformity because of the irregularities in the Earth's
rotation. UT1, is based on the somewhat irregular rotation of the Earth. Rotational irregularities usually result in a net decrease in the Earth's average rotational velocity, and ensuing lags of UT1 with respect to UTC. Coordinated Universal Time (UTC) is the basis for international time-keeping and follows TAI exactly except for an integral number of seconds, 32 in year 2001. These leap seconds are inserted on the advice of the International Earth Rotation Service (IERS) (http://hpiers.obspm.fr/) to ensure that, having taken into account irregularities, the Sun is overhead within 0,9 seconds of 12:00:00 UTC on the meridian of Greenwich. UTC is thus the modern successor of Greenwich Mean Time, GMT, which was used when the unit of time was the mean solar day. Adjustments to the atomic, i.e., UTC, time scale consist of an occasional addition or deletion of one full second, which is called a leap second. Twice yearly, during the last minute of the day of June 30 and December 31, Universal Time, adjustments may be made to ensure that the accumulated difference between UTC and UT1 will not exceed 0,9 s before the next scheduled adjustment. Historically, adjustments, when necessary, have usually consisted of adding an extra second to the UTC time scale in order to allow the rotation of the Earth to "catch up". Therefore, the last minute of the UTC time scale, on the day when an adjustment is made, will have 61 seconds. Adjustments dates are typically announced several months in advance in IERS Bulletin C: ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat. Coordinated Universal Time (UTC) differs thus from TAI by an integral number of seconds. UTC is kept within 0,9 s of UT1 by the introduction of one-second steps to UTC, the "leap second". To date these steps have always been positive.
This can be achieved by using units that are installed in the premises from the hosting organization and then remotely managed by a Time-Stamping Authority that takes the overall responsibility of the quality of the service delivered to the hosting organization. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Time-Stamping Authority + +_____________ _____________ _____________+ |+ __________ | | | | __________ +| |+| | | | Time - | | | |+| |+| Time - |<-------------| Stamping |------------->| Time - |+| |+| Stamping | | Install. | Management | Install. | | Stamping |+| |+| Unit | | Management | | Management | | Unit |+| |+|__________| | |_____________| | |__________|+| |+ | | +| |+ | | +| |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | Hosting | | Hosting | | Organization | | Organization | |______________| |______________| Figure B.1: Managed Time-stamping Service The requirements for time-stamping services described in the current document includes requirements on both the time-stamping management and for the operation of the unit which issues the time-stamp tokens. The TSA, as identified in the time-stamp token, has the responsibility to ensure that these requirements are met (for example through contractual obligations). It should be clear that the hosting organization will generally want to be able to monitor the use of the service and, at a minimum, know whether the service is working or not and even be able to measure the performances of the service, e.g., the number of time-stamps generated during some period of time. Such monitoring can be considered to be outside of TSA's time-stamping authority. Therefore the description of the management operation described in the main body of the document is not limitative. Monitoring operations, if performed directly on the unit, may be permitted by the Time-Stamping service provider.
The present document does not specify the details of how such protection may be obtained. For the time being, and until some enhancements are defined to support these features, the information may be obtained using-out-of bands means or alternatively in the context of closed environments. As an example, should a CA guaranty to maintain the revocation status of TSU certificates after the end of its validity period, this would fulfill the first requirement. NOTE 1: An alternative to Time-Stamping is for a Trusted Service Provider to record a representation of a datum bound to a particular time in an audit trail, thus establishing evidence that the datum existed before that time. This technique, which is called Time- Marking, can be a valuable alternative for checking the long term validity of signatures. NOTE 2: The TSA or other trusted third party service provider may support the verification of time-stamp tokens.
D.4. STATEMENT TYPE: Reliance limits. STATEMENT DESCRIPTION: reliance limits, if any. SPECIFIC REQUIREMENT: Indication of the accuracy of the time in the time-stamp token, and the period of time for which TSA event logs (see section 7.4.10) are maintained (and hence are available to provide supporting evidence). D.5. STATEMENT TYPE: Obligations of subscribers. STATEMENT DESCRIPTION: The description of, or reference to, the critical subscriber obligations. SPECIFIC REQUIREMENT: No specific requirements identified in the current document. Where applicable the TSA may specify additional obligations. D.6. STATEMENT TYPE: TSU public key status checking obligations of relying parties. STATEMENT DESCRIPTION: The extent to which relying parties are obligated to check the TSU public key status, and references to further explanation. SPECIFIC REQUIREMENT: Information on how to validate the TSU public key status, including requirements to check the revocation status of TSU public key, such that the relying party is considered to "reasonably rely" on the time-stamp token (see section 6.3). D.7. STATEMENT TYPE: Limited warranty and disclaimer/Limitation of liability. STATEMENT DESCRIPTION: Summary of the warranty, disclaimers, limitations of liability and any applicable warranty or insurance programs SPECIFIC REQUIREMENT: Limitations of liability (see section 6.4). D.8. STATEMENT TYPE: Applicable agreements and practice statement. STATEMENT DESCRIPTION: Identification and references to applicable agreements, practice statement, time-stamp policy and other relevant documents.
http://www.etsi.org Contact Point Claire d'Esclercs ETSI 650 Route des Lucioles F-06921 Sophia Antipolis, Cedex FRANCE EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.