ISO/IEC 18014-1:2002

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

ISO/IEC 18014-1:2002: 1. identifies the objective of a time-stamping authority; 2. describes a general model on which time-stamping services are based; 3. defines time-stamping services; 4. defines the basic protocols of time-stamping; 5. 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: Withdrawn
• Publication Date: 16-Oct-2002
• Withdrawal Date: 16-Oct-2002
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 2 - Cryptography and security mechanisms
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 26-Aug-2008

Relations

• Revised: ISO/IEC 18014-1:2008 - Information technology — Security techniques — Time-stamping services — Part 1: Framework
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 18014-1
First edition
2002-10-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:2002(E)
©
 ISO/IEC 2002

---------------------- Page: 1 ----------------------
ISO/IEC 18014-1:2002(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.


©  ISO/IEC 2002
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 [e-mail]
Web www.iso.ch
Printed in Switzerland

ii © ISO/IEC 2002 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 18014-1:2002(E)

Contents
1 Scope . 1
2 Normative References. 1
3 Terms and Definitions. 1
4 General Discussion on Time-stamping. 2
4.1 Entities of the Time-Stamping Process. 3
4.2 Time-Stamps. 3
4.3 Use of Time-Stamps . 3
4.4 Verification of a Time-Stamp Token. 4
4.5 Services involved in Time-stamping . 4
5 Communications between entities involved. 4
5.1 Time-Stamp Request Transaction . 4
5.2 Time-Stamp Verification Transactions. 4
6 Message Formats . 5
6.1 Time-stamp request . 5
6.2 Time-stamp response . 5
6.3 Time-stamp verification. 6
6.4 Extension fields . 7
A ASN.1 Module for time-stamping . 8
B Excerpt of the Cryptographic Message Syntax . 13
Bibliography . 19
© ISO/IEC 2002 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 18014-1:2002(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 3.
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 part of ISO/IEC 18014 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.
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
Further parts may follow.
Annexes A and B form a normative part of this part of ISO/IEC 18014.

iv © ISO/IEC 2002 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 18014-1:2002(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 this patent right.
The holder of this patent right has assured the ISO and IEC that he is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the holder of this patent right is registered with the 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 2002 – All rights reserved v

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 18014-1:2002(E)
Information technology — Security techniques — Time-stamping
services —
Part 1:
Framework
1 Scope
ISO/IEC 8825-1: 1998 | X.690: ITU-T Recommendation
X. 690 (1997), Information technology – ASN.1
This part of ISO/IEC 18014:
encoding rules: Specification of Basic Encoding
1. identifies the objective of a time-stamping
Rules (BER), Canonical Encoding Rules (CER) and
authority;
Distinguished Encoding Rules (DER)
2. describes a general model on which time-
ISO/IEC 9798-1: 1997 Information technology –
stamping services are based;
Security techniques – Entity authentication – Part 1:
3. defines time-stamping services;
General
4. defines the basic protocols of time-stamping;
ISO/IEC 10118 (all parts), Information technology –
5. specifies the protocols between the involved
Security techniques – Hash-functions
entities.
ISO/IEC 11770-1: 1996 Information technology –
Security techniques – Key management – Part 1:
Framework
2 Normative References
ISO/IEC 11770-3: 1999 Information technology –
Security techniques – Key management – Part 3:
The following normative documents contain provisions
Mechanisms using asymmetric techniques
which, through reference in this text, constitute
provisions of this part of ISO/IEC 18014 . For dated
ISO/IEC 14888-2: 1999 Information technology –
references, subsequent amendments to, or revisions
Security techniques - Digital signatures with appendix
of, any of these publications do not apply. However,
– Part 2: Identity-based mechanisms
parties to agreements based on this part of
ISO/IEC 14888-3: 1999 Information technology –
ISO/IEC 18014 are encouraged to investigate the
Security techniques - Digital signatures with appendix
possibility of applying the most recent editions of the
– Part 3: Certificate-based mechanisms
normative documents indicated below. For undated
references, the latest edition of the normative document
ISO/IEC 15946-2, Information technology – Security
referred to applies. Members of ISO and IEC maintain
techniques – Cryptographic techniques based on elliptic
registers of currently valid International Standards.
curves – Part 2: Digital signatures
ISO 8601:2000, Data elements and interchange
formats – Information interchange – Representation of
3 Terms and Definitions
dates and times
The following term is used as defined in ISO/IEC 9798-1 :
ISO/IEC 8824-1: 1998 | X.680: ITU-T Recommendation
X. 680 (1997), Information technology – Abstract
entity authentication: the corroboration that an entity
Syntax Notation One (ASN.1): Specification of basic
is the one claimed.
notation
The following terms are used as defined in ISO/IEC
ISO/IEC 8824-2: 1998 | X.681: ITU-T Recommendation
10118-1:
X. 681 (1997), Information technology – Abstract
Syntax Notation One (ASN.1): Information object
collision-resistant hash-function: a hash-function
specification
satisfying the following property:
ISO/IEC 8824-3: 1998 | X.682: ITU-T Recommendation
- it is computationally infeasible to find any two
X. 682 (1997), Information technology – Abstract
distinct inputs which map to the same output.
Syntax Notation One (ASN.1): Constraint specification
hash-function: a function which maps strings of bits
ISO/IEC 8824-4: 1998 | X.683: ITU-T Recommendation
to fixed-length strings of bits, satisfying two important
X. 683 (1997), Information technology – Abstract
properties. The first property states that for a given
Syntax Notation One (ASN.1): Parameterization of
output, it is computationally infeasible to find an input
ASN.1 specifications
which map to this output. The second property states
Ó ISO/IEC 2002 - All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC 18014-1:2002(E)
that, for a given output, it is computationally infeasible Note: An example is given by adding a time-stamp to a
to find a second input which map to the same output. data items representation and signing the result.
hash value: the string of bits which is the output of a 3.4 time-stamp requester: an entity which
hash-function. possesses data it wants to be time-stamped.
The following terms are used as defined in ISO/IEC Note: A requester may also be a Trusted Third Party
11770-1: including a time-stamping authority.
certification authority (CA): a centre trusted to 3.5 time-stamp token: a data structure containing a
create and assign public key certificates. Optionally, verifiable cryptographic binding between a data items’
the certification authority may create and assign keys representation and a time-value. A time-stamp token
to the entities. may also include additional data items in the binding.
private key: that key of an entity’s asymmetric key 3.6 time-stamp verifier: an entity which possesses
pair which should only be used by that entity. data and wants to verify that it has a valid time-stamp
bound to it. The verification process may be performed
public key: that key of an entity’s asymmetric key
by the verifier itself or by a Trusted Third Party.
pair which can be made public.
public key certificate: the public key information of
4 General Discussion on Time-stamping
an entity signed by the certification authority and
thereby rendered unforgeable. The use of digital data that may be provided on easily
modifiable media raises the issue of how to certify
sequence number: a time variant parameter whose
when these data were created or last changed. Digital
value is taken from a specified sequence which is non-
time-stamping shall provide help to achieve a proof of
repeating within a certain time period.
timeliness. Digital time-stamping must fulfil the
time-stamp: a time variant parameter which denotes a following requirements:
point in time with respect to a common time reference.
· A time variant parameter must be bound to the
time-variant parameter: a data item used by an data in a non-forgeable way to provide evidence
entity to verify that a message is not a replay, such as that the data existed prior to a certain point in
a random number, a sequence number, or a time time.
stamp.
· Data may be provided in a way that it is not
The following terms are used as defined in ISO/IEC disclosed.
11770-3:
The time-stamping methods in use solve these
digital signature: a data appended to, or a requirements by time-stamping the hash value of data,
cryptographic transformation of, a data unit that allows which allows for the control of integrity and
a recipient of the data unit to prove the origin and confidentiality. The data themselves are not exposed.
integrity of the data unit and protect the sender and The data’s hash will be cryptographically bound to the
the recipient of the data unit against forgery by third current time value by the TSA. This binding
parties and sender against forgery by the recipient. demonstrates the integrity and authenticity of the time-
stamp. A time-stamp token providing these elements
trusted third party (TTP): a security authority, or its
will be sent to the requester of the time-stamp.
agent, trusted by other entities with respect to security
related activities. Time-stamp tokens may also include information
relating to previously generated tokens. Here the
For the purposes of this standard, the following
data’s representation and additional information from
definitions apply.
data time-stamped prior to that time-stamp request are
3.1 data items’ representation: a data item or input parameters to the time-stamping process. The
some representation thereof such as a cryptographic TSA may in addition publish various data items
hash value. relating to the time-stamping process, for proof that
the data was available in a timely manner after the
3.2 time-stamping authority (TSA): a trusted third
other included data hash. The publication of the
party trusted to provide a time-stamping service.
consecutive hash gives evidence that the related data
3.3 time-stamping service: a service providing existed prior to the second published hash. This
evidence that a data item existed before a certain point approach allows the verifier to verify a time-stamp
in time. without involving another authority.
2 Ó ISO/IEC 2002 - All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 18014-1:2002(E)
4.1 Entities of the Time-Stamping Process A time-stamp re-issue may also be necessary when
the hash-function used to form the hash value from
The following entities may be involved when a time-
the original data is called into question. In this case,
stamp is requested:
both the old time-stamp token and the original data
An entity possesses data it wants to be time-stamped; must be included in the newly calculated hash value
e.g. to have evidence of their existence at a certain submitted for time-stamp reissue.
point in time. This time it acts as the requester of a
A time-stamping service may operate online and
time-stamp. An entity may also get a proof that the
offline (e.g. store-and-forward protocol); the distinction
time-stamped data received has a valid time-stamp
is made at the transport level of the communication
and acts as the verifier of a time-stamp.
protocols between the involved entities.
A time-stamping authority (TSA) offers a time-
stamping service. The nature of this service is highly 4.3 Use of Time-Stamps
sensitive for it helps to identify the validity of data and
A time-stamp does not present the exact time when
especially the validity of cryptographic elements
an electronic document was generated, altered or even
related to these data. The TSA offers evidence that
signed. The entity providing a document for time-
data existed at a certain point in time and guarantees
stamping may sign the document independently from
the correctness of the time parameter.
the TSA, while the TSA cryptographically binds a time
All the entities introduced communicate in a two-way value to the hash of the signed document.
handshake protocol. That means, an entity sends a
The only proof available is that a document existed
request to the TSA and gets a time-stamp (see details
prior to the included time-stamp.
in clause 5.1 and clause 5.2). The token contains
sufficient information to allow the entity to verify the Time-stamps also play an important role for the validity
token at a later point in time. of signed documents. There exist three different
possibilities in time when time-stamping and signing of
4.2 Time-Stamps data may occur. Data may be time-stamped before the
requester of the time-stamp signs it, after the provision
Time-stamps are used to give proof of the existence
of the signature of the document’s sender, and before
of data at a specific point in time. This may be done
and after the signature. This leads to different results
by cryptographically binding a time-stamp to a data
when examining the timely validity of the signature.
items representation.
Table 1 describes these possibilities.
Time-stamped data may be time-stamped again at a
Table 1 – Timely arrangement of signatures and
later time. This may be necessary for example for the
time-stamps
following reasons:
1. The cryptographic primitive used to bind the time
Case 1 t TSA generates a time-stamp
1
value to the data will be near its end of its
s Requester signs data together with the
operational life cycle (e.g.: the TSA’s signature
provided time-stamp
key is about to expire).
Case 2 s Requester signs data
2. The TSA may soon be replaced by another TSA.
t TSA time-stamps signed data
3. The requester’s hash algorithm may come into 2
question.
Case 3 t TSA generates a time-stamp
1
Therefore those data time-stamped by the respective
s Requester signs data together with the
TSA may get a time-stamp re-issue prior to reaching
provided time-stamp
any of the above conditions. This way the validity
period of an existing time-stamp is extended.
t TSA time-stamps signed data
2
Data may be re-time-stamped before a cryptographic
primitive used to bind the time, hash values and other
Case 1 (Signature includes time-stamp) does not
optional parameters together has reached the end of
exactly define the point in time when data was signed.
its operational lifetime. The time-stamp generated then
It states that the signature was provided after data was
is a new time-stamp that has no connection to former
time-stamped. Case 2 expresses that data was signed
time-stamps associated with the data and is called
prior to the stated point in time. Case 3 defines an
time-stamp re-issue.
interval during which the document was signed.
Ó ISO/IEC 2002 - All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC 18014-1:2002(E)
4.4 Verification of a Time-Stamp Token Only the first two parameters are mandatory, the
third value is optional.
When verifying a time-stamp token, first the time value
included in the time-stamp is evaluated, then the 2. The TSA checks the completeness of the received
validity of the Time-Stamp Token containing the time request.
parameter is verified. The validity of a time-stamp is
3. The TSA generates a time-stamp (Time-Stamp
verified by evaluating the correctness of the Time-
Token). The time-stamp itself is a data structure
Stamp Token. Alternately, the evaluation of the
containing
correctness of the Time-Stamp Token may be
· The time-parameter generated or received from
delegated to a trusted third party (TTP).
a reliable source,
4.5 Services involved in Time-stamping · The data delivered by the requester, and
· Data generated by the TSA to
There are two basic operations involved with time-
cryptographically bind the time value to the
stamping:
hash value, hash algorithm, and optionally, the
· A time-stamping process, which cryptographically
nonce.
binds time values to data values, and
If the cryptographic binding uses digital signatures
· a time-stamp verification process, which evaluates then the TSA may use cryptographic algorithms
the correctness of those cryptographic bindings. as provided in standards ISO/IEC FCD 14888-3:
Information technology – Security techniques -
The Time-Stamping Authority (TSA) provides the time-
Digital signatures with appendix – Part 3:
stamping services, whereas the time-stamp verification
Certificate-based mechanisms and ISO/IEC FCD
process may involve other trusted authorities.
15946-2: Information technology- Security
The time provided must fulfil the general requirement of techniques – Cryptographic techniques based on
being accurate; the service providing the time for the elliptic curves: Digital signatures.
TSA is outside the scope of this document.
4. The TSA returns the Time-Stamp Token to the
requesting entity.
5 Communications between entities involved
5. The entity may immediately check the
completeness and correctness of the received
The entities involved in the time-stamping process are
Time-Stamp Token, or allow the eventual relying
an entity, either requesting a time-stamp or verifying a
party to do so.
time-stamp on the one side and one or more TSA on
the other side. The transactions between these
entities will be introduced in the following clauses.
Figure 1 shows the communications between the
5.1 Time-Stamp Request Transaction requester and the TSA; the numbering refers to the text.
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
Figure 1 — Communications between Requester and
be time-stamped. For the hash generation
TSA
mechanisms as provided in ISO/IEC 10118-2: 1997
Information technology – Security techniques - Hash-
functions – Part 2: Hash functions using an n-bit
5.2 Time-Stamp Verification Transactions
block cipher algorithm, as provided in Part 3:
Dedicated hash-functions or as in Part 4: Hash
Verification of tokens produced using independent
functions using modular arithmetic may be used
token mechanisms makes use of information
contained in a single time-stamp token. The verifier
1. A time-stamp request message is sent to the
may be required to obtain additional information
TSA including the following data:
required by the mechanism in order to complete the
· Hash value,
verification operation; this may be done by the
· Hash algorithm used, and
requesting entity or on behalf of the entity by another
TTP.
· a nonce.
4 Ó ISO/IEC 2002 - All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 18014-1:2002(E)
Verification of tokens produced using linked token
mechanisms makes use of information contained in a
Data field Description
single time-stamp token and possibly other tokens
produced by the TSA. The verifier may be required to
version The syntax version number
obtain additional information required by the
mechanism in order to complete the verification
messageImprint The MessageImprint to which the service
operation; this may be done by the requesting entity or
provider is to bind a time value
on behalf of the entity by another TTP.
reqPolicy Service policy requested from the TSA
Additional information is provided in part 2 and part 3 of
issuing the Time-Stamp Token
this standard.
nonce Identifies the specific request; the purpose
of this value is to tie a specific request to
6 Message Formats
the respective reply.
There are two types of messages that are needed to
certReq Signals the TSA to provide certificate
generate the transactions introduced in Clause 5: information, if present.
Messages between time-stamping requester/verifier
extensions Contains and extensions required to
and TSA, and messages between TSA and
properly fulfill the requested time-stamping
requester/verifier. All messages will be described in
operation.
the ASN.1 notation. A complete ASN.1 module is
provided in annex A. Messages will be distinguished
according to the service they represent.
Type MessageImprint is used to encapsulate the
6.1 Time-stamp request
message imprint data along with an indicator of the
algorithm used to generate the message imprint.
TimeStampReq messages are used by entities to
request time-stamping services from time-stamping
authorities. A TimeStampReq message is formed as
MessageImprint ::= SEQUENCE {
follows:
hashAlgorithm DigestAlgorithmIdentifier,
TimeStampReq ::= SEQUENCE {
hashedMessage OCTET STRING
version Version,
}
messageImprint MessageImprint,
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
Data field Description
certReq BOOLEAN DEFAULT FALSE,
hashAlgorithm Hash Algorithm Identifier and parameter
extensions [0] Extensions OPTIONAL
value
}
hashedMessage The corresponding hash value of a message
to be time-stamped, as calculated with the
The following table explains the variables and their
hash-function specified in the
values.
hashAlgorithm data field.
The hash-function must be a collision-resistant hash-
function.
TSAPolicyId is defined as follows:
TSAPolicyId ::= POLICY.&id({TSAPolicies})
6.2 Time-stamp response
The answer to a time-stamp request is a
TimeStampResp data structure. It has the following
form:
TimeStampResp ::= SEQUENCE {
Ó ISO/IEC 2002 - All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC 18014-1:2002(E)
status PKIStatusInfo,
structure, the eContentType field contains the following
object identifier:
timeStampToken TimeStampToken OPTIONAL
id-ct-TSTInfoOBJECT IDENTIFIER ::= {
}
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
The TimeStampToken structure is defined as follows:
pkcs-9(9) smime(16) ct(1) 4
TimeStampToken ::= SEQUENCE {
}
contentType CONTENT.&id({Contents}),
In addition, the eContent field contains the TSTInfo
content [0]
structure, DER-encoded as an octet string.
EXPLICIT CONTENT.&Type ({Contents}{@contentType})
GeneralizedTime is a combination of the basic format
}
for calendar dates in complete representation and the
This structure is used to encapsulate a TSTInfo basic format for the coordinated universal time
structure. The TSTInfo structure is defined as follows: according to ISO 8601: Data elements and
interchange formats – information interchange –
TSTInfo ::= SEQUENCE {
Representation of dates and times. This format has
version Version,
the following form:
policy TSAPolicyId,
C C Y Y M M D D h h m m s s [ . f f ] Z
messageImprint MessageImprint,
Where each of the characters with the exception of the
serialNumber SerialNumber,
last is a substitute for a single digit:
genTime GeneralizedTime,
CC represents the centuries (19-99),
accuracy Accuracy OPTIONAL,
YY represents the years (00-99),
ordering BOOLEAN DEFAULT FALSE,
MM represents the actual month (01-12),
nonce Nonce OPTIONAL,
tsa [0] EXPLICIT GeneralName DD represents the actual day of the month (01-31),
OPTIONAL,
hh represents the actual hour of the day (00-23),
extensions [1] Extensions OPTIONAL
mm stands for the minutes of the hour (00-59), and
}
ss represents the seconds of the minute (00-59).
The following table describes those data fields that are
ff is an abbreviation for fractions of a second without
yet not defined.
trailing 0.
The Character Z (Zulu Time) stands for Universal Time
Data field Description
Coordinated (UTC).
Accuracy ::= SEQUENCE {
accuracy The accuracy of the genTime field as
seconds INTEGER OPTIONAL,
compared with UTC.
millis [0] INTEGER (1.999) OPTIONAL,
genTime The time the TSA included in the Time-Stamp
Token
micros [1] INTEGER (1.999) OPTIONAL
serialNumber This field is an integer assigned by the TSA
}
to each TimeStampToken. It must be unique
(ALL EXCEPT ({- none; at least one component shall be present -
for each TimeStampToken issued by a given
}))
TSA.
6.3 Time-stamp verification
The TSTInfo structure is encapsulated in the
The verification protocol is similar to the time-stamp
TimeStampToken structure using th
...