T (ftp://62.161.69.5/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.
Annex B (informative): Possible for Implementation Architectures
and Time-Stamping Services
B.1. Managed Time-Stamping Service
Some organizations may be willing to host one or more Time-Stamping
Units in order to take advantage of both the proximity and the
quality of the Time-Stamping Service, without being responsible for
the installation, operation and management of these Time-Stamping
Units.
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.
B.2. Selective Alternative Quality
Some relying parties may be willing to take advantage of particular
characteristics from a time-stamp token such as a specific signature
algorithm and/or key length or a specific accuracy for the time
contained in the time stamp token. These parameters can be
considered as specifying a "quality" for the time stamp token.
Time stamp tokens with various qualities may be issued by different
time-stamping units operated by the same or different TSAs.
A particular time-stamping unit will only provide one combination of
algorithm and key length (since a time-stamping unit is a set of
hardware and software which is managed as a unit and has a single
time-stamp token signing key). In order to obtain different
combinations of algorithm and key length, different time-stamping
units shall be used.
A particular time-stamping unit may provide a fixed accuracy for the
time contained in the time stamp token or different accuracy if
instructed to do so either by using a specific mode of access (e.g.,
e-mail or http) or by using specific parameters in the request.
Annex C (informative): Long Term Verification of Time-Stamp Tokens
Usually, a time-stamp token becomes unverifiable beyond the end of
the validity period of the certificate from the TSU, because the CA
that has issued the certificate does not warrant any more that it
will publish revocation data, including data about revocations due to
key compromises. However, verification of a time-stamp token might
still be performed beyond the end of the validity period of the
certificate from the TSU, if, at the time of verification, it can be
known that:
- the TSU private key has not been compromised at any time up to
the time that a relying part verifies a time-stamp token;
- the hash algorithms used in the time-stamp token exhibits no
collisions at the time of verification;
- the signature algorithm and signature key size under which the
time-stamp token has been signed is still beyond the reach of
cryptographic attacks at the time of verification.
If these conditions cannot be met, then the validity may be
maintained by applying an additional time-stamp to protect the
integrity of the previous one.
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.
Annex D (informative): Model TSA Disclosure Statement Structure.
The TSA disclosure statement contains a section for each defined
statement type. Each section of a TSA disclosure statement contains
a descriptive statement, which MAY include hyperlinks to the relevant
certificate policy/certification practice statement sections.
D.1. STATEMENT TYPE: Entire agreement
STATEMENT DESCRIPTION: A statement indicating that the
disclosure statement is not the entire agreement, but only a
part of it.
D.2. STATEMENT TYPE: TSA contact info
STATEMENT DESCRIPTION: The name, location and relevant contact
information for the TSA.
D.3. STATEMENT TYPE: time-stamp token types and usage
STATEMENT DESCRIPTION: A description of each class/type of
time-stamp tokens issued by the TSA (in accordance with each
time-stamp policy) and any restrictions on time-stamp usage.
SPECIFIC REQUIREMENT: Indication of the policy being applied,
including the contexts for which the time-stamp token can be
used (e.g., only for use with electronic signatures), the
hashing algorithms, the expected life time of the time-stamp
token signature, any limitations on the use of the time-stamp
token and information on how to verify the time-stamp token.
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.
D.9. STATEMENT TYPE: Privacy policy.
STATEMENT DESCRIPTION: A description of and reference to the
applicable privacy policy.
SPECIFIC REQUIREMENT: Note: TSA’s under this policy are
required to comply with the requirements of Data Protection
Legislation.
D.10. STATEMENT TYPE: Refund policy
STATEMENT DESCRIPTION: A description of and reference to the
applicable refund policy.
D.11. STATEMENT TYPE: Applicable law, complaints and dispute
resolution mechanisms.
STATEMENT DESCRIPTION: Statement of the choice of law,
complaints procedure and dispute resolution mechanisms.
SPECIFIC REQUIREMENT: The procedures for complaints and dispute
settlements. The applicable legal system.
D.12. STATEMENT TYPE: TSA and repository licenses, trust marks, and
audit.
STATEMENT DESCRIPTION: Summary of any governmental licenses,
seal programs; and a description of the audit process and if
applicable the audit firm.
SPECIFIC REQUIREMENT: If the TSA has been assessed to be
conformant with the identified time-stamp policy, and if so
through which independent party.
Authors’ Addresses
Denis Pinkas
Bull
Rue Jean Jaures,
78340 Les Clayes CEDEX
FRANCE
EMail: Denis.Pinkas@bull.net
Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: pope@secstan.com
John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: ross@secstan.com
This Informational RFC has been produced in ETSI ESI.
ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - France
Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org
Contact Point
Claire d’Esclercs
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis, Cedex
FRANCE
EMail: claire.desclercs@etsi.org
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.