1# Abstract
2
3This document defines requirements for a baseline time-stamp policy
4for Time-Stamping Authorities (TSAs) issuing time-stamp tokens,
5supported by public key certificates, with an accuracy of one second
6or better. A TSA may define its own policy which enhances the policy
7defined in this document. Such a policy shall incorporate or further
8constrain the requirements identified in this document.
9
10# 1. Introduction
11
12The content of this RFC is based on [RFC 3628](https://datatracker.ietf.org/doc/html/rfc3628).
13The primary changes in this RFC are the removal of legal requirements,
14requirements to comply with the EU Directive, and requirements that specify the
15TSA will use on-premise hardware to manage the TSA primary key and service.
16
17In creating reliable and manageable digital evidence it is necessary to have an
18agreed upon method of associating time data to transaction so that they might be
19compared to each other at a later time. The quality of this evidence is based on
20creating and managing the data structure that represent the events and the
21quality of the parametric data points that anchor them to the real world.
22In this instance this being the time data and how it was applied.
23
24A typical transaction is a digitally signed document, where it is
25necessary to prove that the digital signature from the signer was
26applied when the signer's certificate was valid.
27
28A timestamp or a time mark (which is an audit record kept in a secure
29audit trail from a trusted third party) applied to a digital
30signature value proves that the digital signature was created before
31the date included in the time-stamp or time mark.
32
33To prove the digital signature was generated while the signer's
34certificate was valid, the digital signature must be verified and the
35following conditions satisfied:
36
371. the time-stamp (or time mark) was applied before the end of the
38 validity period of the signer's certificate,
391. the time-stamp (or time mark) was applied either while the signer's
40 certificate was not revoked or before the revocation date of the certificate.
41
42Thus a time-stamp (or time mark) applied in this manner proves that
43the digital signature was created while the signer's certificate was
44valid. This concept proves the validity of a digital signature over
45the whole of any certificate chain.
46
47Policy requirements to cover that case is the primary reason of this
48document. However, it should be observed that these policy
49requirements can be used to address other needs.
50
51The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
52"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
53document are to be interpreted as described in
54[BCP 14](https://datatracker.ietf.org/doc/html/bcp14),
55[RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
56
57# 2. Overview
58
59These policy requirements are aimed at time-stamping services used in
60support of qualified electronic signatures but may be applied to any application
61requiring to prove that a datum existed before a particular time.
62
63These policy requirements are based on the use of public key
64cryptography, public key certificates and reliable time sources. The
65present document may be used by independent bodies as the basis for
66confirming that a TSA may be trusted for providing time-stamping
67services.
68
69This document addresses requirements for synchronizing TSAs issuing
70time-stamp tokens with Coordinated universal time (UTC) and digitally
71signed by TSUs.
72
73Subscriber and relying parties should consult the TSA's practice
74statement to obtain further details of precisely how this time-stamp
75policy is implemented by the particular TSA (e.g., protocols used in
76providing this service).
77
78This document does not specify:
79
80- protocols used to access the TSUs;
81
82NOTE 1: A time-stamping protocol is defined in
83[RFC 3161](https://datatracker.ietf.org/doc/html/rfc3161)
84and profiled in [TS 101 861](https://www.etsi.org/deliver/etsi_ts/101800_101899/101861/01.04.01_60/ts_101861v010401p.pdf).
85
86- how the requirements identified herein may be assessed by an independent body;
87- requirements for information to be made available to such independent bodies;
88- requirements on such independent bodies.
89
90# 3. Definitions and Abbreviations
91
92## 3.1. Definitions
93
94For the purposes of the present document, the following terms and
95definitions apply:
96
97- relying party: recipient of a time-stamp token who relies on that time-stamp token.
98
99- subscriber: entity requiring the services provided by a TSA and which has
100 explicitly or implicitly agreed to its terms and conditions.
101
102- time-stamp token: data object that binds a representation of a datum to a
103 particular time, thus establishing evidence that the datum existed before that time.
104
105- time-stamping authority: authority which issues time-stamp tokens.
106
107- TSA Disclosure statement: set of statements about the policies and practices
108 of a TSA that particularly require emphasis or disclosure to subscribers and
109 relying parties, for example to meet regulatory requirements.
110
111- TSA practice statement: statement of the practices that a TSA employs
112 in issuing time-stamp tokens.
113
114- TSA system: composition of IT products and components organized to support
115 the provision of time-stamping services.
116
117- time-stamp policy: named set of rules that indicates the applicability of a
118 time-stamp token to a particular community and/or class of application with
119 common security requirements.
120
121- time-stamping unit: set of hardware and software which is managed as a unit
122 and has a single time-stamp token signing key active at a time.
123
124- Coordinated Universal Time (UTC): Time scale based on the second as defined
125 in ITU-R Recommendation TF.460-5.
126
127 NOTE: For most practical purposes UTC is equivalent to mean
128 solar time at the prime meridian. More specifically, UTC is a
129 compromise between the highly stable atomic time (Temps
130 Atomique International - TAI) and solar time derived from the irregular Earth
131 rotation (related to the Greenwich mean sidereal time (GMST) by
132 a conventional relationship).
133
134- UTC(k): Time-scale realized by the laboratory "k" and kept in close
135 agreement with UTC, with the goal to reach plus or minus 100
136 ns. (See ITU-R Recommendation TF.536-1.
137
138 NOTE: A list of UTC(k) laboratories is given in section 1 of
139 Circular T disseminated by BIPM and available from the BIPM
140 website (http://www.bipm.org/).
141
142## 3.2. Abbreviations
143
144For the purposes of the present document, the following abbreviations
145apply:
146
147- TSA Time-Stamping Authority
148- TSU Time-Stamping Unit
149- TST Time-Stamp Token
150- UTC Coordinated Universal Time
151
152# 4. General Concepts
153
154## 4.1. Time-Stamping Services
155
156The provision of time-stamping services is broken down into the
157following component services for the purposes of classifying
158requirements:
159
160- Time-stamping provision: This service component generates time-stamp tokens.
161
162- Time-stamping management: The service component that monitors and controls
163 the operation of the time-stamping services to ensure that the service is
164 provided as specified by the TSA. This service component is responsible for
165 the installation and de-installation of the time-stamping provision service.
166 For example, time-stamping management ensures that the clock used for
167 time-stamping is correctly synchronized with UTC.
168
169This subdivision of services is only for the purposes of clarifying
170the requirements specified in the current document and places no
171restrictions on any subdivision of an implementation of time-stamping
172services.
173
174## 4.2. Time-Stamping Authority
175
176The authority to issue time-stamp tokens, trusted by the users of the
177time-stamping services, i.e., subscribers and relying parties, is
178called the Time-Stamping Authority (TSA).
179
180TSA has overall
181responsibility for time-stamping services identified in clause 4.1.
182The TSA has responsibility for the operation of one or more TSU's
183which creates and signs on behalf of the TSA. The TSA responsible
184for issuing a time-stamp token is identifiable (see 7.3.1 h).
185
186The TSA may delegate the signing of timestamps to a cloud key management
187service. However, the TSA always maintains overall responsibility and ensures
188that the policy requirements identified in the present document are met.
189
190A TSA may operate several identifiable time-stamping units.
191Each unit has a different key.
192
193A TSA is a certification-service-provider which issues time-stamp tokens.
194
195## 4.3.Subscriber
196
197The subscriber may be an organization comprising several end-users or an
198individual end-user.
199
200When the subscriber is an organization, some of the obligations that apply to
201that organization will have to apply as well to the end-users.
202
203In any case the organization will be held responsible if the
204obligations from the end-users are not correctly fulfilled and therefore the
205organization is expected to suitably inform its end users.
206
207When the subscriber is an end-user, the end-user will be held directly
208responsible if its obligations are not correctly fulfilled.
209
210## 4.4. Time-Stamp Policy and TSA Practice Statement
211
212This section explains the relative roles of Time-stamp policy and TSA
213practice statement. It places no restriction on the form of a time-
214stamp policy or practice statement specification.
215
216### 4.4.1. Purpose
217
218In general, the time-stamp policy states "what is to be adhered to,"
219while a TSA practice statement states "how it is adhered to", i.e.,
220the processes it will use in creating time-stamps and maintaining the accuracy
221of its clock.
222
223The relationship between the time-stamp policy and TSA practice statement is
224similar in nature to the relationship of other business policies which state
225the requirements of the business, while operational units define the practices
226and procedures of how these policies are to be carried out.
227
228The present document specifies a time-stamp policy to meet general
229requirements for trusted time-stamping services.
230TSAs specify in TSA practice statements how these requirements are met.
231
232### 4.4.2. Level of Specificity
233
234The TSA practice statement is more specific than a time-stamp policy.
235
236A TSA practice statement is a more detailed description of the terms
237and conditions as well as business and operational practices of a TSA
238in issuing and otherwise managing time-stamping services.
239
240The TSA practice statement of a TSA enforces the rules established by a
241time-stamp policy. A TSA practice statement defines how a specific
242TSA meets the technical, organizational and procedural requirements
243identified in a time-stamp policy.
244
245NOTE: Even lower-level internal documentation may be appropriate for
246a TSA detailing the specific procedures necessary to complete the
247practices identified in the TSA practice statement.
248
249### 4.4.3. Approach
250
251The approach of a time-stamp policy is significantly different from a
252TSA practice statement.
253
254A time-stamp policy is defined independently of the specific details of the
255specific operating environment of a TSA, whereas a TSA practice statement is
256tailored to the organizational structure, operating procedures, facilities,
257and computing environment of a TSA.
258
259A time-stamp policy may be defined by the user of times-stamp services,
260whereas the TSA practice statement is always defined by the provider.
261
262# 5. Time-Stamp Policies
263
264## 5.1. Overview
265
266A time-stamp policy is a "named set of rules that indicates the
267applicability of a time-stamp token to a particular community and/or
268class of application with common security requirements" (see clauses
269[3.1](#31-definitions) and [4.4](#44-time-stamp-policy-and-tsa-practice-statement)).
270
271The present document defines requirements for a baseline time-stamp
272policy for TSAs issuing time-stamp tokens, supported by public key
273certificates, with an accuracy of 1 second or better.
274
275NOTE 1: Without additional measures the relying party may not be able to ensure
276the validity of a time-stamp token beyond the end of the validity period of the
277supporting certificate. See Annex A on verification of the validity of a
278time-stamp token beyond the validity period of the TSU's certificate.
279
280A TSA may define its own policy which enhances the policy defined in this
281document. Such a policy shall incorporate or further constrain the requirements
282identified in this document.
283
284NOTE 1: It is required that a time-stamp token includes an identifier
285for the applicable policy (see section [7.3.1](#731-time-stamp-token)).
286
287## 5.2. Identification
288
289The object-identifier X.208 of this time-stamp policy is `1.3.6.1.4.1.57264.2`.
290In the TSA disclosure statement made available to subscribers and relying
291parties, a TSA shall also include the identifier for the time-stamp policy
292to indicate its conformance.
293
294## 5.3. User Community and Applicability
295
296This service aims to provide binary transparency. This policy may be used for
297public time-stamping services or time-stamping services used
298within a closed community.
299
300## 5.4. Conformance
301
302The TSA shall use the identifier for the timestamp policy in timestamp tokens
303as given in section [5.2](#52-identification), or define its own time-stamp
304policy that incorporates or further constrains the requirements identified
305in the present document:
306
307- If the TSA claims conformance to the identified timestamp policy and makes
308 available to subscribers and relying parties on request the evidence to
309 support the claim of conformance; or
310
311- If the TSA has been assessed to conform to the identified timestamp
312 policy by an independent party.
313
314A conformant TSA must demonstrate that:
315
316- It meets its obligations as defined in section [6.1](#61-tsa-obligation);
317
318- It has implemented controls which meet the requirements specified in
319 section [7](#7-requirements-on-tsa-practices).
320
321# 6. Obligations and Liability
322
323## 6.1. TSA Obligations
324
325### 6.1.1. General
326
327The TSA shall ensure that all requirements on TSA, as detailed in section
328[7](#7-requirements-on-tsa-practices), are implemented as applicable to the
329selected trusted time-stamp policy.
330
331The TSA shall ensure conformance with the procedures prescribed in this policy,
332even when the TSA functionality is undertaken by subcontractors.
333
334The TSA shall also ensure adherence to any additional obligations indicated in
335the time-stamp either directly or incorporated by reference.
336
337The TSA shall provide all its time-stamping services consistent with
338its practice statement.
339
340### 6.1.2. TSA Obligations Towards Subscribers
341
342The TSA shall meet its claims as given in its terms and conditions including
343the availability and accuracy of its service.
344
345## 6.2. Subscriber Obligations
346
347The current document places no specific obligations on the subscriber beyond
348any TSA specific requirements stated in the TSA's terms and condition.
349
350NOTE: It is advisable that, when obtaining a time-stamp token, the subscriber
351verifies that the time-stamp token has been correctly signed and that the
352private key used to sign the time-stamp token has not been compromised.
353
354## 6.3. Relying Party Obligations
355
356The terms and conditions made available to relying parties shall include an
357obligation on the relying party that, when relying on a time-stamp token, it shall:
358
3591. verify that the time-stamp token has been correctly signed and that the
360 private key used to sign the time-stamp has not been compromised
361 until the time of the verification;
362
363 NOTE: During the TSU's certificate validity period, the validity
364 of the signing key can be checked using current revocation status
365 for the TSU's certificate. If the time of verification exceeds
366 the end of the validity period of the corresponding certificate,
367 see annex A for guidance.
368
3691. take into account any limitations on the usage of the time-stamp
370 indicated by the time-stamp policy;
371
3721. take into account any other precautions prescribed in agreements or elsewhere.
373
374# 7. Requirements on TSA Practices
375
376The TSA shall implement the controls that meet the following requirements.
377
378These policy requirements are not meant to imply any restrictions on charging
379for TSA services.
380
381The requirements are indicated in terms of the security objectives, followed by
382more specific requirements for controls to meet those objectives where it is
383necessary to provide confidence that those objective will be met.
384
385NOTE: The details of controls required to meet an objective is a balance
386between achieving the necessary confidence whilst minimizing the restrictions
387on the techniques that a TSA may employ in issuing time-stamp tokens.
388In the case of section [7.4](#74-tsa-management-and-operation)
389(TSA management and operation), a reference is made to a source of more
390detailed control requirements. Due to these factors the specificity of the
391requirements given under a given topic may vary.
392
393The provision of a time-stamp token in response to a request is at the
394discretion of the TSA depending on any service level agreements with the subscriber.
395
396## 7.1. Practice and Disclosure Statements
397
398### 7.1.1. TSA Practice Statement
399
400The TSA shall ensure that it demonstrates the reliability necessary
401for providing time-stamping services.
402
403In particular:
404
4051. The TSA shall have a risk assessment carried out in order to evaluate
406 business assets and threats to those assets in order to determine the necessary security controls and operational procedures.
407
4081. The TSA shall have a statement of the practices and procedures used to
409 address all the requirements identified in this time-stamp policy.
410
411 - NOTE 1: This policy makes no requirement as to the structure
412 of the TSA practice statement.
413
4141. The TSA's practice statement shall identify the obligations of all
415 external organizations supporting the TSA services including
416 the applicable policies and practices.
417
4181. The TSA may make available to subscribers and relying parties its practice
419 statement, and other relevant documentation, as necessary, to assess
420 conformance to the time-stamp policy.
421
422 - NOTE 2: The TSA is not generally required to make all the details
423 of its practices public.
424
4251. Maintainers of the TSA shall have final authority for approving the TSA
426 practice statement and ensuring that the practices are properly implemented.
427 Maintainers shall also review any changes to the TSA to confirm that they
428 follow the approved practice statement.
429
4301. The TSA shall give due notice of changes it intends to make in its practice
431 statement and shall, following approval as in (5) above, make the revised
432 TSA practice statement immediately available as required under (4) above.
433
434## 7.2. Key Management Life Cycle
435
436### 7.2.1. TSA Key Generation
437
438The TSA shall ensure that any cryptographic keys are generated in
439under controlled circumstances.
440
441In particular:
442
4431. The generation of the TSU's signing key(s) shall be undertaken by personnel
444 in trusted roles. The personnel authorized to carry out this function shall
445 be limited to those requiring to do so under the TSA's practices.
446
4471. The generation of the TSU's signing key(s) shall be carried out in a secure
448 environment. It MAY be carried out in a cloud based environment
449 that protects the key.
450
4511. The TSU key generation algorithm, the resulting signing key length and
452 signature algorithm used for signing time-stamp tokens key shall be
453 recognized by TSA maintainers as being fit for the purposes of time-stamp
454 tokens as issued by the TSA.
455
456### 7.2.2. TSU Private Key Protection
457
458The TSA shall ensure that TSU private keys remain confidential and maintain
459their integrity. The TSU private signing key shall be securely
460stored in one of the following:
461
462- HSM
463- Cloud environment
464- On-prem environment with controlled access
465
466### 7.2.3. TSU Public Key Distribution
467
468The TSA shall ensure that the integrity and authenticity of the TSU signature
469verification (public) keys and any associated parameters are maintained
470during its distribution to relying parties.
471
472In particular:
473
4741. TSU signature verification (public) keys shall be made available to relying
475 parties in a public key certificate.
476
477 NOTE: For example, TSU's certificates may be issued by a certification
478 authority operated by the same organization as the TSA,
479 or issued by another authority.
480
4811. The TSU's signature verification (public) key certificate shall be issued
482 by a certification authority operating under a certificate policy which
483 provides a level of security equivalent to, or higher than,
484 this time-stamping policy.
485
486### 7.2.4. Rekeying TSU's Key
487
488The life-time of TSU's certificate shall be not longer than the period of
489time that the chosen algorithm and key length is recognized as being
490fit for purpose (see section [7.2.1c](#721-tsa-key-generation))).
491
492NOTE 1: The following additional considerations apply when limiting
493that lifetime:
494
495- Should a TSU private key be compromised, then the longer the life-time,
496 the more affected time-stamp tokens there will be.
497
498NOTE 2: TSU key compromise does not only depend on the characteristics of
499the storage system being used but also on the procedures being used at system
500initialization and key export (when that function is supported).
501
502### 7.2.5. End of TSU Key Life Cycle
503
504The TSA shall ensure that TSU private signing keys are not used
505beyond the end of their life cycle.
506
507In particular:
508
5091. Operational or technical procedures shall be in place to ensure that a
510 new key is put in place when a TSU's key expires.
511
5121. The TSU private signing keys, or any key part, including any copies shall
513 be destroyed such that the private keys cannot be retrieved.
514
5151. The TST generation system SHALL reject any attempt to issue TSTs
516 if the signing private key has expired.
517
518### 7.2.6. Life Cycle Management of the Cryptographic Module used to Sign Time-Stamps
519
520The TSA shall use one of the following to host the token signing software:
521
522- HSM
523- Cloud environment
524- On-prem environment with controlled access
525
526## 7.3. Time-Stamping
527
528### 7.3.1. Time-Stamp Token
529
530The TSA shall ensure that time-stamp tokens are issued securely and include the correct time.
531
532In particular:
533
5341. The time-stamp token shall include an identifier for the time-stamp policy.
535
5361. Each time-stamp token shall have a unique identifier.
537
5381. The time values the TSU uses in the time-stamp token shall be traceable to
539 at least one of the real time values distributed by a UTC(k) laboratory.
540
5411. The time-stamp provider should periodically monitor its correctness of time
542 with a set of trusted UTC sources. The recorded accuracy should be included
543 in the returned time-stamp token.
544
5451. The time-stamp provider SHOULD monitor for accuracy and alert if it's found
546 to be out of sync.
547
5481. The time-stamp token shall include a representation (e.g., hash value) of
549 the datum being time-stamped as provided by the requestor.
550
5511. The time-stamp token shall be signed using a key generated exclusively
552 for this purpose.
553
554 NOTE 1: A protocol for a time-stamp token is defined in RFC 3631 and
555 profiled in TS 101 861.
556
557 NOTE 2: In the case of a number of requests at approximately the same time,
558 the ordering of the time within the accuracy of the TSU clock is not mandated.
559
5601. The time-stamp token shall include:
561 - where applicable, an identifier for the country in which
562 the TSA is established;
563 - an identifier for the TSA;
564 - an identifier for the unit which issues the time-stamps.
565
566### 7.3.2. Clock Synchronization with UTC
567
568The TSA shall ensure that its clock is synchronized with UTC
569within the declared accuracy.
570
571In particular:
572
5731. The calibration of the TSU clocks shall be maintained such that the
574 clocks shall not be expected to drift outside the declared accuracy.
575
5761. The TSA shall ensure that, if the time that would be indicated in a
577 time-stamp token drifts or jumps out of synchronization with UTC,
578 this will be detected (see also [7.3.1e](#731-time-stamp-token))).
579
580 NOTE 1: Relying parties are required to be informed of such events
581 (see section [7.4.8](#748-compromise-of-tsa-services)).
582
5831. The TSA shall ensure that clock synchronization is maintained when a
584 leap second occurs as notified by the appropriate body. The change to take
585 account of the leap second shall occur during the last minute of the day
586 when the leap second is scheduled to occur.
587
588 NOTE 1: A leap second is an adjustment to UTC by skipping or adding an
589 extra second on the last second of a UTC month. First preference is given
590 to the end of December and June, and second preference is given to the end
591 of March and September.
592
593## 7.4. TSA Management and Operation
594
595### 7.4.1. Security Management
596
597The TSA shall ensure that the administrative and management procedures applied
598are adequate and correspond to recognized best practice.
599
600In particular:
601
602TSA General
603
6041. The TSA shall retain responsibility for all aspects of the provision of
605 time-stamping services within the scope of this time-stamp policy,
606 whether or not functions are outsourced to subcontractors.
607 Responsibilities of third parties shall be clearly defined by the TSA
608 and appropriate arrangements made to ensure that third parties are bound
609 to implement any controls required by the TSA. The TSA shall retain
610 responsibility for the disclosure of relevant practices of all parties.
611
6121. The TSA management shall provide direction on information security
613 through a suitable high level steering forum that is responsible for
614 defining the TSA's information security policy. The TSA shall ensure
615 publication and communication of this policy to all employees who are
616 impacted by it.
617
6181. The information security infrastructure necessary to manage the security
619 within the TSA shall be maintained at all times. Any changes that will
620 impact on the level of security provided shall be approved
621 by the TSA management forum.
622
6231. The security controls and operating procedures for TSA systems and
624 information assets providing the time-stamping services shall be documented,
625 implemented and maintained.
626
627 NOTE 1: The present documentation (commonly called a system
628 security policy or manual) should identify all relevant targets,
629 objects and potential threats related to the services provided and
630 the safeguards required to avoid or limit the effects of those
631 threats. It should describe the rules, directives and procedures regarding
632 how the specified services and the associated security assurance are granted
633 in addition to stating policy on incidents and disasters.
634
635- TSA shall ensure that the security of information is maintained when the
636 responsibility for TSA functions has been outsourced to another
637 organization or entity.
638
639### 7.4.2. Asset Classification and Management
640
641The TSA shall ensure that its information and other assets receive an
642appropriate level of protection.
643
644In particular:
645
646- The TSA shall maintain an inventory of all assets and shall assign a
647 classification for the protection requirements to those assets consistent
648 with the risk analysis.
649
650### 7.4.3. Personnel Security
651
652The TSA shall follow the principle of least privilege and ensure that those
653working on the TSA only have the minimal privilege needed to perform functions.
654
655### 7.4.4. Physical and Environmental Security
656
657Ths TSA will host the timestamping authority service and store private keys
658with either on-prem hardware or a trusted cloud provider. If the TSA uses a
659cloud provider to host the service and private key, it shall ensure it uses a
660provider that has appropriate physical security settings.
661
662For both the time-stamping provision and the time-stamping management:
663
664- The TSA shall only use cloud providers that control physical access to
665 facilities that will host the timestamping authority service and private key;
666
667- The TSA shall implement controls to avoid loss, damage or compromise of
668 assets and interruption to business activities;
669
670- controls shall be implemented to avoid compromise or theft of information.
671
672- The following additional controls shall be applied to time-stamping management:
673 - The TSA shall ensure it uses a cloud provider that keeps infrastructure
674 in an environment which physically protects the services from compromise through unauthorized access to systems or data.
675
676### 7.4.5. Operations Management
677
678The TSA shall ensure that the TSA system components are secure and
679correctly operated, with minimal risk of failure. In particular (general):
680
6811. The integrity of TSA system components and information shall be protected
682 against viruses, malicious and unauthorized software.
683
6841. Incident reporting and response procedures shall be employed in such a way
685 that damage from security incidents and malfunctions shall be minimized.
686
6871. Media used within the TSA trustworthy systems shall be securely handled to
688 protect media from damage, theft, unauthorized access and obsolescence.
689
690 NOTE 1: Every member of personnel with management responsibilities is
691 responsible for planning and effectively implementing the time-stamp
692 policy and associated practices as documented in the TSA practice statement.
693
6941. Procedures shall be established and implemented for all trusted and
695 administrative roles that impact on the provision of time-stamping services.
696
697Media handling and security:
698
6991. All media shall be handled securely in accordance with requirements of the
700 information classification scheme (see section
701 [7.4.2](#742-asset-classification-and-management)). Media containing
702 sensitive data shall be securely disposed of when no longer required.
703
704System Planning:
705
7061. Capacity demands shall be monitored and projections of future capacity
707 requirements made to ensure that adequate processing power and storage
708 are available.
709
710Incident reporting and response:
711
7121. The TSA shall act in a timely and coordinated manner in order to respond
713 quickly to incidents and to limit the impact of breaches of security.
714 All incidents shall be reported as soon as possible after the incident.
715
716The following additional controls shall be applied to time-stamping
717management:
718
719Operations procedures and responsibilities
720
7211. TSA security operations shall be separated from other operations.
722 NOTE 1: TSA security operations' responsibilities include: - operational
723 procedures and responsibilities; - secure systems planning and acceptance;
724 - protection from malicious software; - housekeeping; - network management;
725 - active monitoring of audit journals, event analysis and follow-up;
726 - media handling and security; - data and software exchange.
727
728These operations shall be managed by TSA trusted personnel, as defined within
729the appropriate security policy, and, roles and responsibility documents.
730
731### 7.4.6. System Access Management
732
733The TSA shall ensure that TSA system access is limited to
734properly authorized individuals.
735
736In particular (general):
737
7381. Controls (e.g., firewalls) shall be implemented to protect the TSA's
739 internal network domains from unauthorized access including access by
740 subscribers and third parties.
741
742 NOTE: Firewalls should also be configured to prevent all protocols and
743 accesses not required for the operation of the TSA.
744
7451. The TSA shall ensure effective administration of user (this includes
746 operators, administrators and auditors) access to maintain system security,
747 including user account management, auditing and timely modification
748 or removal of access.
749
7501. The TSA shall ensure that access to information and application system
751 functions is restricted in accordance with the access control policy and
752 that the TSA system provides sufficient computer security controls for the
753 separation of trusted roles identified in TSA's practices, including the
754 separation of security administrator and operation functions.
755 Particularly, use of system utility programs is restricted
756 and tightly controlled.
757
7581. TSA personnel shall be accountable for their activities
759
760The following additional controls shall be applied to time-stamping
761management:
762
7631. The TSA shall ensure that it uses a cloud provider that keeps local network
764 components (e.g., routers) in a physically secure environment.
765
766### 7.4.7. Trustworthy Systems Deployment and Maintenance
767
768The TSA shall use trustworthy systems and products that are protected
769against modification.
770
771NOTE: The risk analysis carried out on the TSA's services (see section
772[7.1.1](#711-tsa-practice-statement)) should identify its critical services
773requiring trustworthy systems and the levels of assurance required.
774
775In particular:
776
777- An analysis of security requirements shall be carried out at the design
778 and requirements specification stage of any systems development project
779 undertaken by the TSA or on behalf of the TSA to ensure that security is
780 built into IT systems.
781
782- Change control procedures shall be applied for releases, modifications and
783 emergency software fixes of any operational software.
784
785### 7.4.8. Compromise of TSA Services
786
787The TSA shall ensure in the case of events which affect the security of the
788TSA's services, including compromise of TSU's private signing keys or
789detected loss of calibration, that relevant information is made available to
790subscribers and relying parties.
791
792In particular:
793
7941. The TSA's disaster recovery plan shall address the compromise or suspected
795 compromise of TSU's private signing keys or loss of calibration of a
796 TSU clock, which may have affected time-stamp tokens which have been issued.
797
7981. In the case of a compromise, or suspected compromise or loss of
799 calibration the TSA shall make available to all subscribers and relying
800 parties a description of compromise that occurred.
801
8021. In the case of compromise to a TSU's operation (e.g., TSU key compromise),
803 suspected compromise or loss of calibration the TSU shall not issue
804 time-stamp tokens until steps are taken to recover from the compromise.
805
806- In case of major compromise of the TSA's operation or loss of calibration,
807 wherever possible, the TSA shall make available to all subscribers and
808 relying parties information which may be used to identify the time-stamp
809 tokens which may have been affected, unless this breaches the privacy of
810 the TSAs users or the security of the TSA services.
811
812 NOTE: In case the private key does become compromised, an audit trail of
813 all tokens generated by the TSA may provide a means to discriminate between
814 genuine and false backdated tokens. Two time-stamp tokens from two
815 different TSAs may be another way to address this issue.
816
817### 7.4.9. TSA Termination
818
819The TSA shall ensure that potential disruptions to subscribers and relying
820parties are minimized as a result of the cessation of the TSA's time-stamping
821services, and in particular ensure continued maintenance of information
822required to verify the correctness of time-stamp tokens.
823
824In particular:
825
8261. Before the TSA terminates its time-stamping services the following
827 procedures shall be executed as a minimum:
828
829 - the TSA shall make available to all subscribers and relying parties
830 information concerning its termination;
831
832 - TSA shall terminate authorization of any outside services
833 performing key singing
834
835 - the TSA shall maintain or transfer to a reliable party its obligations
836 to make available its public key or its certificates to relying parties for a reasonable period;
837
838 - TSU private keys, including backup copies, shall be destroyed in a
839 manner such that the private keys cannot be retrieved.
840
8411. The TSA shall state in its practices the provisions made for
842 termination of service. This shall include:
843
844 - notification of affected entities;
845 - transferring the TSA obligations to other parties.
846
8471. The TSA shall take steps to have the TSU's certificates revoked.
848
849# 8. Security Considerations
850
851When verifying time-stamp tokens it is necessary for the verifier to ensure
852that the TSU certificate is trusted and not revoked. This means that the
853security is dependent upon the security of the CA that has issued the
854TSU certificate for both issuing the certificate and providing accurate
855revocation status information for that certificate.
856
857When a time-stamp is verified as valid at a given point of time, this does
858not mean that it will necessarily remain valid later on. Every time,
859a time-stamp token is verified during the validity period of the TSU
860certificate, it must be verified again against the current revocation
861status information, since in case of compromise of a TSU private key,
862all the time-stamp tokens generated by that TSU become invalid. Annex A
863provides guidance about the long term verification of time-stamp tokens.
864
865In applying time-stamping to applications, consideration also needs to be
866given to the security of the application. In particular, when applying
867time-stamps it is necessary to ensure that the integrity of data is
868maintained before the time-stamp is applied. The requester ought to
869really make sure that the hash value included in the time-stamp token
870matches with the hash of the data.
871
872# Annex A (informative): Long Term Verification of Time-Stamp Tokens
873
874Usually, a time-stamp token becomes unverifiable beyond the end of the
875validity period of the certificate from the TSU, because the CA that has
876issued the certificate does not warrant any more that it will publish
877revocation data, including data about revocations due to key compromises.
878However, verification of a time-stamp token might still be performed beyond
879the end of the validity period of the certificate from the TSU, if,
880at the time of verification, it can be known that:
881
882- the TSU private key has not been compromised at any time up to the
883 time that a relying part verifies a time-stamp token;
884
885- the hash algorithms used in the time-stamp token exhibits no
886 collisions at the time of verification;
887
888- the signature algorithm and signature key size under which the
889 time-stamp token has been signed is still beyond the reach of cryptographic
890 attacks at the time of verification.
891
892If these conditions cannot be met, then the validity may be maintained by
893applying an additional time-stamp to protect the integrity of the previous one.
894
895The present document does not specify the details of how such protection
896may be obtained. For the time being, and until some enhancements are defined
897to support these features, the information may be obtained using-out-of
898bands means or alternatively in the context of closed environments.
899As an example, should a CA guaranty to maintain the revocation status of
900TSU certificates after the end of its validity period,
901this would fulfill the first requirement.
View as plain text