Information technology — Security techniques — Time-stamping services — Part 1: Framework

ISO/IEC 18014 specifies time-stamping techniques. It consists of three parts, which include the general notion, models for a time-stamping service, data structures, and protocols. ISO/IEC 18014-1:2008 describes a framework and defines the basic notion, the data structures, and protocols which are used for any time-stamping technique. ISO/IEC 18014-1:2008: identifies the objective of a time-stamping authority; describes a general model on which time-stamping services are based; describes a process of generating and verifying time-stamp; defines the data structures of time-stamp token; defines the basic protocols of time-stamping; specifies the protocols between the involved entities.

Technologies de l'information — Techniques de sécurité — Services d'estampillage de temps — Partie 1: Cadre général

General Information

Status
Published
Publication Date
25-Aug-2008
Current Stage
9093 - International Standard confirmed
Completion Date
12-Sep-2020
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 18014-1:2008 - Information technology -- Security techniques -- Time-stamping services
English language
28 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 18014-1
Second edition
2008-09-01

Information technology — Security
techniques — Time-stamping services —
Part 1:
Framework
Technologies de l'information — Techniques de sécurité — Services
d'estampillage de temps —
Partie 1: Cadre général



Reference number
ISO/IEC 18014-1:2008(E)
©
ISO/IEC 2008

---------------------- Page: 1 ----------------------
ISO/IEC 18014-1:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2008 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 18014-1:2008(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Symbols and abbreviated terms .4
5 General.4
5.1 Background and Summary .4
5.2 Services involved in Time-stamping.5
5.3 Entities of the Time-Stamping Process.5
5.4 Use of Time-Stamps .5
5.5 Generation of a Time-Stamp Token .6
5.6 Verification of a Time-Stamp Token.6
5.7 Time-Stamp renewal.6
6 Communications between entities involved.7
6.1 Time-Stamp Request Transaction.7
6.2 Time-Stamp Verification Transaction.8
7 Message Formats.8
7.1 Time-stamp request.9
7.2 Time-stamp response.10
7.3 Time-stamp verification.12
7.4 Extension fields .12
7.4.1 ExtHash extension.12
7.4.2 ExtMethod extension.13
7.4.3 ExtRenewal extension.13
Annex A (normative) ASN.1 Module for time-stamping .14
Annex B (normative) Excerpt of the Cryptographic Message Syntax .20
B.1 Introduction.20
B.2 General Overview.20
B.3 General Syntax.20
B.4 Data Content Type .21
B.5 Signed-data Content Type .21
B.5.1 SignedData Type.22
B.5.2 EncapsulatedContentInfo Type.23
B.5.3 SignerInfo Type.23
B.5.4 Message Digest Calculation Process .25
B.5.5 Signature Generation Process .25
B.5.6 Signature Verification Process.25
B.6 Useful Attributes.26
B.6.1 Content Type.26
B.6.2 Message Digest.26
B.6.3 Countersignature.27
Bibliography .28

© ISO/IEC 2008 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 18014-1:2008(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 18014-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
This second edition cancels and replaces the first edition (ISO/IEC 18014-1:2002), which has been technically
revised.
ISO/IEC 18014 consists of the following parts, under the general title Information technology — Security
techniques — Time-stamping services:
⎯ Part 1: Framework
⎯ Part 2: Mechanisms producing independent tokens
⎯ Part 3: Mechanisms producing linked tokens

iv © ISO/IEC 2008 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 18014-1:2008(E)
Introduction
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC)
draw attention to the fact that it is claimed that compliance with this International Standard may involve the
use of patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect,
the statements of the holders of these patent rights are registered with ISO and IEC. Information may be
obtained from:
ISO/IEC JTC 1/SC 27 Standing Document 8 (SD 8) "Patent Information"
SD 8 is publicly available at: http://www.din.de/ni/sc27
Attention is drawn to the possibility that some of the elements of this International Standard may be the
subject of patent rights other than those identified above. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.

© ISO/IEC 2008 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 18014-1:2008(E)

Information technology — Security techniques —
Time-stamping services —
Part 1:
Framework
1 Scope
This part of ISO/IEC 18014:
⎯ identifies the objective of a time-stamping authority;
⎯ describes a general model on which time-stamping services are based;
⎯ defines time-stamping services;
⎯ defines the basic protocols between the involved entities.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and
times
ISO/IEC 10118 (all parts), Information technology — Security techniques — Hash-functions
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
certification authority
CA
centre trusted to create and assign public key certificates
NOTE Optionally, the certification authority can create and assign keys to the entities.
[ISO/IEC 11770-1:1996]
© ISO/IEC 2008 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC 18014-1:2008(E)
3.2
collision-resistant hash-function
hash-function satisfying the following property: it is computationally infeasible to find any two distinct inputs
which map to the same output
NOTE Computational feasibility depends on the specific security requirements and environment.
[ISO/IEC 10118-1:2000]
3.3
data items’ representation
data item or some representation thereof such as a cryptographic hash value
3.4
digital signature
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to
prove the origin and integrity of the data unit and protect the sender and the recipient of the data unit against
forgery by third parties and sender against forgery by the recipient
[ISO/IEC 11770-3:1999]
3.5
entity authentication
corroboration that an entity is the one claimed
[ISO/IEC 9798-1:1997]
3.6
hash-function
function which maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
⎯ it is computationally infeasible to find for a given output, an input which maps to this output;
⎯ it is computationally infeasible to find for a given input, a second input which maps to the same output
NOTE Computational feasibility depends on the specific security requirements and environment.
[ISO/IEC 10118-1:2000]
3.7
hash value
string of bits which is the output of a hash-function
NOTE Identical to the definition of hash-code in ISO/IEC 10118-1:2000.
3.8
private key
that key of an entity’s asymmetric key pair which should only be used by that entity
[ISO/IEC 11770-1:1996]
3.9
public key
that key of an entity’s asymmetric key pair which can be made public
[ISO/IEC 11770-1:1996]
2 © ISO/IEC 2008 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 18014-1:2008(E)
3.10
public key certificate
public key information of an entity signed by the certification authority and thereby rendered unforgeable
[ISO/IEC 11770-1:1996]
3.11
sequence number
time variant parameter whose value is taken from a specified sequence which is nonrepeating within a certain
time period
[ISO/IEC 11770-1:1996]
3.12
time stamp
time variant parameter which denotes a point in time with respect to a common time reference
[ISO/IEC 11770-1:1996]
3.13
time-stamp renewal
process of issuing a new time-stamp token to extend the validity period of an earlier time-stamp token
3.14
time-stamp requester
entity which possesses data it wants to be time-stamped
NOTE A requester can also be a trusted third party including a time-stamping authority.
3.15
time-stamp token
TST
data structure containing a verifiable binding between a data items’ representation and a time-value
NOTE A time-stamp token can also include additional data items in the binding.
3.16
time-stamp verifier
entity which possesses data and wants to verify that it has a valid time stamp bound to it
NOTE The verification process can be performed by the verifier itself or by a trusted third party.
3.17
time-stamping authority
TSA
trusted third party trusted to provide a time-stamping service
3.18
time-stamping service
TSS
service providing evidence that a data item existed before a certain point in time
3.19
time variant parameter
data item used by an entity to verify that a message is not a replay, such as a random number, a sequence
number, or a time stamp
[ISO/IEC 11770-1:1996]
© ISO/IEC 2008 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC 18014-1:2008(E)
3.20
trusted third party
TTP
security authority, or its agent, trusted by other entities with respect to security-related activities
[ISO/IEC 11770-3:1999]
3.21
time referencing scheme
concepts for describing temporal characteristics of geographic information, about the use of an atomic clock,
the clock of the GPS signal, etc.
NOTE See ISO 19108:2002.
3.22
time-signal emission
standard time signals are emitted with reference to UTC according to standard schemes
[ITU-R TF.460-6]
3.23
time-stamping policy
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
4 Symbols and abbreviated terms
TS (x , x , …, x ) generation of time-stamp token for the data x , x , …, x
1 2 n 1 2 n
D data to be time-stamped
other info information used to generate the time-stamp token, and which equals
“TSTInfo” less the hash value of the data to be time-stamped
T T …T the point in time to be time-stamped
0, 1, n,
t t , t , … t , the point in time to be time-stamped
0, 1 2 n
S the point in time at which the end entity’s digital signature is generated
5 General
5.1 Background and Summary
The use of digital data that may be provided on easily modifiable media raises the issue of how to certify when
this data was created or last changed. Digital time-stamping shall provide evidence of timeliness. Digital time-
stamping shall fulfill the following requirements:
⎯ A time variant parameter shall be bound to the data in a non-forgeable way to provide evidence that the
data existed prior to a certain point in time.
⎯ Data shall be provided in a way that it is not disclosed.
4 © ISO/IEC 2008 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 18014-1:2008(E)
The time-stamping methods specified in this international standard solve these requirements by time-stamping
the hash value of data, which allows for the control of integrity and nondisclosure. The data themselves are
not exposed. The hash of the data will be bound to the current time value by the TSA. This binding
demonstrates the integrity and authenticity of the time-stamp. A time-stamp token providing these elements
will be sent to the requester of the time-stamp.
Time-stamp tokens may also include information relating to previously generated tokens. Here the data’s
representation and additional information from data time-stamped prior to that time-stamp request are input
parameters to the time-stamping process. The TSA may in addition publish various data items relating to the
time-stamping process, to provide evidence that the data was available in a timely manner after the other
included data hash. The publication of consecutive hashes gives evidence that the related data existed prior
to the second published hash. This approach allows the verifier to verify a time-stamp without involving
another authority.
5.2 Services involved in Time-stamping
There are two basic operations involved with time-stamping:
⎯ a time-stamping process, which binds time values to data values, and
⎯ a time-stamp verification process, which evaluates the correctness of those cryptographic bindings.
A Time-Stamping Authority (TSA) provides the time-stamping services, whereas the time-stamp verification
process may involve other trusted authorities.
The time provided shall fulfill the general requirement of being accurate; the service providing the time for the
TSA is outside the scope of this document.
NOTE Time sources are typically dependent on standard time-signal emissions based on standard time referencing
schemes.
5.3 Entities of the Time-Stamping Process
The following entities may be involved when a time-stamp is requested:
An entity possesses data it wants to be time-stamped; e.g. to have evidence of the data’s existence at a
certain point in time. In this case it acts as the requester of a time-stamp. An entity may also request evidence
that the time-stamped data received has a valid time-stamp, and may act as the verifier of a time-stamp.
The time-stamping authority (TSA) offers a time-stamping service. The nature of this service is highly sensitive
for it helps to identify the validity of data and especially the validity of cryptographic elements related to these
data. The TSA offers evidence that data existed at a certain point in time and guarantees the correctness of
the time parameter.
All the entities introduced communicate using a two-way handshake protocol. That is, an entity sends a
request to the TSA and receives in return a time-stamp (see details in clause 5.1 and clause 5.2). The token
contains sufficient information to allow the entity to verify the token at a later point in time.
A time-stamping service may operate online and offline (e.g. using a store-and-forward protocol); the
distinction is made at the transport level of the communication protocols between the involved entities.
5.4 Use of Time-Stamps
A time-stamp does not present the exact time when an electronic document was generated, altered or even
signed. The entity providing a document for time-stamping may sign the document independently from the
TSA, while the TSA binds a time value to the hash of the signed document.
© ISO/IEC 2008 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC 18014-1:2008(E)
The only evidence available is that a document existed prior to the included time-stamp.
Time-stamps also play an important role for the validity of signed documents. There exist three different
possibilities for the time at which time-stamping and signing of data may occur. Data may be time-stamped
before the requester of the time-stamp signs it, after the provision of the signature of the document’s sender,
and before and after the signature. This leads to different results when examining the timely validity of the
signature. Table 1 describes these possibilities.
Table 1 —Timely arrangement of signatures and time-stamps
Case 1 t TSA generates a time-stamp
1
S Requester signs data together with the provided
time-stamp
Case 2 S Requester signs data
t TSA time-stamps signed data
2
Case 3 t TSA generates a time-stamp
1
S Requester signs data together with the provided
time-stamp
t TSA time-stamps signed data
2

Technically:
Case 1: (Signature includes time-stamp) does not exactly define the point in time when data was signed. It
states that the signature was provided after data was time-stamped.
Case 2: expresses that data was signed prior to the stated point in time.
Case 3: defines an interval during which the document was signed.
5.5 Generation of a Time-Stamp Token
When generating a time-stamp token, first the requester computes the hash value for the data to be time-
stamped and sends it to TSA within a time-stamp request message. TSA binds the hash value and the time-
stamp request message to the current time value as a Time-Stamp Token and sends it back to the requester.
5.6 Verification of a Time-Stamp Token
When verifying a time-stamp token, the validity of the Time-Stamp Token containing the time parameter is
verified. Alternatively, the evaluation of the correctness of the Time-Stamp Token may be delegated to a
trusted third party (TTP).
5.7 Time-Stamp renewal
Time-stamped data may be time-stamped again at a later time. This process is called time-stamp renewal and
may optionally be implemented by the TSA. This may be necessary for example for the following reasons:
⎯ The mechanism used to bind the time value to the data is near the end of its operational life cycle (e.g.:
when using a digital signature and the public key certificate is about to expire).
6 © ISO/IEC 2008 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 18014-1:2008(E)
⎯ The cryptographic function used to bind the time value to the data is still trusted; however, there is strong
evidence that it will become vulnerable in the near future (e.g. when a hash function is close to being
broken by new attacks or available computing power).
⎯ The issuing TSA is about to terminate operations as a service provider.
Renewal is a variant of the basic time-stamping process where an existing time-stamp over previously time-
stamped digital data is explicitly incorporated as data to be bound to a newly generated time-stamp over the
same digital data with a new (current) time value. By incorporating the pre-existing time-stamp in the
generation of the new time-stamp, and assuming that security considerations are satisfied appropriately, the
validity period of the earlier time-stamp over the time-stamped digital data is extended by the coverage of the
new time-stamp.
Let data D be time-stamped at time T
0
TS(D, (other info), T )
0
At time T , while the time-stamp is trusted, a renewal such as
1
TS(D, (TS(D, (other info), T ), other info), T )
0 1
still proves the existence of D at T , given that the first time-stamp is valid at T .
0 1
Renewal has to be performed before any of the above-mentioned conditions make the original time-stamp
void.
When verifying a renewed time-stamp token:
⎯ the outermost time-stamp token issued at T is verified at the current time
1
⎯ the enclosed time-stamp token issued at T is verified at the time of issuance T of the enclosing time-
0 1
stamp token.
In the event of multiple nested renewals, each nested time-stamp token is verified at the time of issuance of
the subsequent renewal, until the innermost time-stamp token is verified.
6 Communications between entities involved
The entities involved in the time-stamping process are an entity either requesting a time-stamp or verifying a
time-stamp, and one or more TSAs on the other side. The transactions between these entities will be
introduced in the following clauses.
6.1 Time-Stamp Request Transaction
The communication between an entity (requester) and the TSA when requesting a time-stamp consists of the
following steps:
The requester generates the hash value for the data to be time-stamped. The hash generation mechanism
shall be one of the hash-functions specified in ISO/IEC 10118.
a) A time-stamp request message is sent to the TSA including the following data:
⎯ Hash value,
⎯ Hash algorithm used, and
⎯ (optional) a nonce.
© ISO/IEC 2008 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/IEC 18014-1:2008(E)
b) The TSA checks the completeness of the received request.
c) The TSA generates a time-stamp (Time-Stamp Token). The time-stamp itself is a data structure
containing
⎯ The time-parameter generated or received from a reliable source,
⎯ The data delivered by the requester, and
⎯ Data generated by the TSA to bind the time value to the hash value, hash algorithm, and optionally,
the nonce.
d) If the cryptographic binding uses digital signatures then the TSA may use cryptographic algorithms as
provided in ISO/IEC 14888. The TSA returns the Time-Stamp Token to the requesting entity.
e) The entity may immediately check the completeness and correctness of the received Time-Stamp Token,
or allow the eventual relying party to do so.
Figure 1 shows the communications between the requester and the TSA; the lettering refers to the text.


(e) (b),(c)
(d)
Requester TSA

(a)
Figure 1 — Communications between Requester and TSA
6.2 Time-Stamp Verification Transaction
Verification of tokens produced using independent token mechanisms makes use of information contained in a
single time-stamp token. The verifier may be required to obtain additional information required by the
mechanism in order to complete the verification operation; this may be done by the requesting entity or on
behalf of the entity by another TTP.
Verification of tokens produced using linked token mechanisms makes use of information contained in a single
time-stamp token and possibly other tokens produced by the TSA. The verifier may be required to obtain
additional information required by the mechanism in order to complete the verification operation; this may be
done by the requesting entity or on behalf of the entity by another TTP.
Additional information is provided in ISO/IEC 18014-2 and ISO/IEC 18014-3.
7 Message Formats
There are two types of messages that are needed to generate the transactions introduced in Clause 5:
messages between time-stamping requester/verifier and TSA, and messages between TSA and
requester/verifier. All messages will be described in the ASN.1 notation. A complete ASN.1 module is
provided in annex A. Messages will be distinguished according to the service they represent.
8 © ISO/IEC 2008 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC 18014-1:2008(E)
7.1 Time-stamp request
TimeStampReq messages are used by entities to request time-stamping services from time-stamping
authorities. A TimeStampReq message is formed as follows:
TimeStampReq ::= SEQUENCE {
version Version,
messageImprint MessageImprint,
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0]Extensions OPTIONAL
}
The following table explains the variables and their v
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.