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.
Abstract
This 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.
Table of Contents
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
1. Introduction
The contents of this Informational RFC is technically equivalent to
ETSI TS 102 023 V 1.2.1 (2002-06) [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].
2. Overview
These policy requirements are aimed at time-stamping services used in
support of qualified electronic signatures (i.e., in line with
article 5.1 of the European Directive on a community framework for
electronic signatures) but may be applied to any application
requiring to prove that a datum existed before a particular time.
These policy requirements are based on the use of public key
cryptography, public key certificates and reliable time sources. The
present document may be used by independent bodies as the basis for
confirming that a TSA may be trusted for providing time-stamping
services.
This document addresses requirements for synchronizing TSAs issuing
time-stamp tokens with Coordinated universal time (UTC) and digitally
signed by TSUs.
Subscriber and relying parties should consult the TSA’s practice
statement to obtain further details of precisely how this time-stamp
policy is implemented by the particular TSA (e.g., protocols used in
providing this service).
This document does not specify:
- protocols used to access the TSUs;
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].
3. Definitions and Abbreviations
3.1. Definitions
For the purposes of the present document, the following terms and
definitions apply:
NOTE: Where a definition is copied from a referenced document this is
indicated by inclusion of the reference identifier number at the end
of the definition.
relying party: recipient of a time-stamp token who relies on that
time-stamp token.
subscriber: entity requiring the services provided by a TSA and which
has explicitly or implicitly agreed to its terms and
conditions.
time-stamp token: data object that binds a representation of a datum
to a particular time, thus establishing evidence that the datum
existed before that time.
time-stamping authority: authority which issues time-stamp tokens.
TSA Disclosure statement: set of statements about the policies and
practices of a TSA that particularly require emphasis or
disclosure to subscribers and relying parties, for example to
meet regulatory requirements.
TSA practice statement: statement of the practices that a TSA employs
in issuing time-stamp tokens.
TSA system: composition of IT products and components organized to
support the provision of time-stamping services.
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/).
3.2. Abbreviations
For the purposes of the present document, the following abbreviations
apply:
TSA Time-Stamping Authority
TSU Time-Stamping Unit
TST Time-Stamp Token
UTC Coordinated Universal Time
4. General Concepts
4.1. Time-Stamping Services
The provision of time-stamping services is broken down into the
following component services for the purposes of classifying
requirements:
- Time-stamping provision: This service component generates
time-stamp tokens.
- 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.
4.2. Time-Stamping Authority
The authority to issue time-stamp tokens, trusted by the users of the
time-stamping services, i.e., subscribers and relying parties, is
called the Time-Stamping Authority (TSA). TSA has overall
responsibility for time-stamping services identified in clause 4.1.
The TSA has responsibility for the operation of one or more TSU’s
which creates and signs on behalf of the TSA. The TSA responsible
for issuing a time-stamp token is identifiable (see 7.3.1 h).
The TSA may use other parties to provide parts of the Time-Stamping
Services. However, the TSA always maintains overall responsibility
and ensures that the policy requirements identified in the present
document are met. For example, a TSA may sub-contract all the
component services, including the services which generate time-stamp
tokens using the TSU’s keys. However, the private key or keys used
to generate the time-stamp tokens belong to the TSA which maintains
overall responsibility for meeting the requirements in this document.
A TSA may operate several identifiable time-stamping units. Each
unit has a different key. See 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.
4.3. Subscriber
The subscriber may be an organization comprising several end-users or
an individual end-user.
When the subscriber is an organization, some of the obligations that
apply to that organization will have to apply as well to the end-
users. In any case the organization will be held responsible if the
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.
4.4. Time-Stamp Policy and TSA Practice Statement
This section explains the relative roles of Time-stamp policy and TSA
practice statement. It places no restriction on the form of a time-
stamp policy or practice statement specification.
4.4.1. Purpose
In general, the time-stamp policy states "what is to be adhered to,"
while a TSA practice statement states "how it is adhered to", i.e.,
the processes it will use in creating time-stamps and maintaining the
accuracy of its clock. The relationship between the time-stamp
policy and TSA practice statement is similar in nature to the
relationship of other business policies which state the requirements
of the business, while operational units define the practices and
procedures of how these policies are to be carried out.
The present document specifies a time-stamp policy to meet general
requirements for trusted time-stamping services. TSAs specify in TSA
practice statements how these requirements are met.
4.4.2. Level of Specificity
The TSA practice statement is more specific than a time-stamp policy.
A TSA practice statement is a more detailed description of the terms
and conditions as well as business and operational practices of a TSA
in issuing and otherwise managing time-stamping services. The TSA
practice statement of a TSA enforces the rules established by a
time-stamp policy. A TSA practice statement defines how a specific
TSA meets the technical, organizational and procedural requirements
identified in a time-stamp policy.
NOTE: Even lower-level internal documentation may be appropriate for
a TSA detailing the specific procedures necessary to complete the
practices identified in the TSA practice statement.
4.4.3. Approach
The approach of a time-stamp policy is significantly different from a
TSA practice statement. A time-stamp policy is defined independently
of the specific details of the specific operating environment of a
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.
5. Time-Stamp Policies
5.1. Overview
A time-stamp policy is a "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" (see clauses
3.1 and 4.4).
The present document defines requirements for a baseline time-stamp
policy for TSAs issuing time-stamp tokens, supported by public key
certificates, with an accuracy of 1 second or better.
NOTE 1: Without additional measures the relying party may not be able
to ensure the validity of a time-stamp token beyond the end of the
validity period of the supporting certificate. See 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).
5.2. Identification
The object-identifier [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.
5.3. User Community and Applicability
This policy is aimed at meeting the requirements of time-stamping
qualified electronic signatures (see European Directive on Electronic
Signatures) for long term validity (e.g., as defined in TS 101 733
[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.
5.4. Conformance
The TSA shall use the identifier for the time-stamp policy in time-
stamp tokens as given in 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.
6. Obligations and Liability
6.1. TSA Obligations
6.1.1. General
The TSA shall ensure that all requirements on TSA, as detailed in
section 7, are implemented as applicable to the selected trusted
time-stamp policy.