ISO/IEC 13888-3:1997
(Main)Information technology — Security techniques — Non-repudiation — Part 3: Mechanisms using asymmetric techniques
Information technology — Security techniques — Non-repudiation — Part 3: Mechanisms using asymmetric techniques
Technologies de l'information — Techniques de sécurité — Non-répudiation — Partie 3: Mécanismes utilisant des techniques asymétriques
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISOAEC
STANDARD
13888-3
First edition
1997-12-01
Information technology - Security
techniques - Non-repudiation -
Part 3:
Mechanisms using asymmetric techniques
Technologies de /‘in forma tion - de skcuritk - Non-
Techniques
rbpudia tion -
Partie 3: Mkcanismes utilisant des techniques asymetriques
Reference number
ISO/IEC 13888-3:1997(E)
---------------------- Page: 1 ----------------------
ISOAEC 13888-3:1997 (E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechni-
cal 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 patt in the work.
In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circu-
lated to national bodies for voting. Publication as an International Standard requires approval by
at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 13888-3 was prepared by Joint Technical Committee ISO/IEC
JTC 1, Information technology, Subcommittee SC 27, IT Security techniques.
lSO/IEC 13888 consists of the following Parts, under the general title Information technology -
Security techniques - Non-repudia tion:
- Part 1: General
- Part 2: Mechanisms using symmetric techniques
- Part 3: Mechanisms using asymmetric techniques
Annex A of this part of ISO/IEC 13888 is for information only.
0 ISO/1 EC 1997
All rights reserved. Unfess otherwise specified, no patt of this publication may be reproduced or utilized in any
form or by any means, electronie or mechanical, including photocopying and microfilm, without Permission in
writing from the publisher,
ISOAEC Copyright Office l Case postale 56 l CH-l 211 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
~~
INTERNATIONAL STANDARD 0 ISO/IEC ISO/IEC 13888-3: 1997 (E)
Information technology - Security techniques - Non-repudiation -
Part 3: Mechanisms using asymmetric techniques
ISO 7498-2:1989, Information processing Systems - Open
Systems Interconnection - Basic ßeference Model, Part 2:
1 Scope
Security Architecture.
The goal of the Non-repudiation Service is to generate,
ISO/1 EC 9594-8: 1995, Information technology - Open
collect, maintain, make available and validate evidente
Systems Interconnection - The Directory: Authentication
concerning a claimed event or action in Order to resolve
framework.
disputes about the occurrence or non occurrence of the
ISO/IEC 9796 (all Parts), Information technology - Security
event or action. This patt of ISO/IEC 13888 specifies
techniques - Digital signature schemes giving message
mechanisms for the Provision of some specific, communi-
cation related non-repudiation Services using asymmetric recovery.
techniques.
ISO/IEC 10181-1 :1996, Information technology - Open Sy-
Non-repudiation mechanisms are specified to establish the
stems Interconnection - Security frameworks for open
following non-repudiation Services:
Systems: Overview.
I SO/I EC IO 18 1-4: 1997, Information technology - Open
- non-repudiation of origin,
- Security frameworks for open
Systems Interconnection
- non-repudiation of delivery,
Systems - Parf 4: Non-repudiation framework.
- non-repudiation of Submission,
ISO/IEC 13888-1: 1997, Information technology - Security
- non-repudiation of transport.
techniques - Non-repudiation - Parf 1: General.
Non-repudiation mechanisms involve the exchange of non- ISO/IEC 14888 (all Parts), Information technology -
repudiation tokens specific for each non-repudiation Security techniques - Digital signatures with appendix.
Service. Non-repudiation tokens consist of digital signatures
and additionat data. Non-repudiation tokens shall be stored
3 Definitions
as non-repudiation information that may be used
subsequently in case of disputes.
For the purposes of this part of ISO/IEC 13888, the
Depending on the non-repudiation policy in effect for a definitions and notation described in ISO/IEC 13888-1
specific application, and the legal environment within which
aPPlY*
the application operates, additional Information may be re-
quired Po complete the non-repudiation information, e.g.,
4 Symbols and abbreviations
- evidente including a trusted time stamp provided by
a Time Stamping Authority,
the distinguishing identifier of the message
A
originator A.
- evidente provided by a notary which provides as-
surance about the action or event performed by one
B the distinguishing identifier of the message
or more entities.
recipient B.
Non-repudiation tan onty be provided within the context of a
DA Delivery Authority, a trusted third Party.
clearly defined security policy for a particular application
a data item (flag) indicating the kind of non-repu-
and its legal environment. Non-repudiation policies are f/
diation Service in effect.
described in the multipart Standard of Security Frameworks
for open Systems - Part 4: Non-repudiation Framework,
the imprint of the data y, consisting of data y or
Imp(Y)
lSO/IEC 10181-4.
the hash-code of y.
m the message which is sent from entity A to entity
B in respect of which non-repudiation Services
2 Normative references
are provided.
The following Standards contain provisions which, through
NRD Non-repudiation of Delivery.
reference in this text, constitute provisions of this part of
ISO/IEC 13888. At the time of publication, the editions indi-
NRDT Non-repudiation of Delivery Token.
cated were valid. All Standards are subject to revision, and
NR0 Non-repudiation of Origin.
Parties to agreements based on this part of ISO/IEC 13888
NROT Non-repudiation of Origin Token.
are encouraged to investigate the possibility of applying the
most recent editions of the Standards indicated below.
NRS Non-repudiation of Submission.
Members 0% REC and ISO maintain registers of currently
NRST
Non-repudiation of Submission Token.
valid lnternational Standards
NRT Non-repudiation of Transport-
1
---------------------- Page: 3 ----------------------
ISOAEC 13888-3: 1997 (E) 0 ISOAEC
NRT-T Non-repudiation of Transport Token. to guarantee the authenticity of the public verification
keys, as described in, e.g., ISO 9594-8.
$01 the distinguishing identifier of the non-repudiation
The non-repudiation policy in forte may require that the
policy (or policies) which apply to the evidente.
evidente be generated partly or totally by a trusted third
Q an optional data item that may contain additional
Party.
information, e.g., the distinguishing identifiers of
A Time Stamp Authority (TSA) may be involved to
the message m, signature mechanism, or hash-
provide trusted time stamping. TSA may also be used to
function.
ensure that a non-repudiation token remains valid even
the signature Operation using a signature algo-
SX
after the key used to sign the token has been
rithm and the private key of entity X.
compromised or revoked.
date and time the event or action took place.
A Notary Authority may be involved to certify the entities
Ti
involved, to certify the data communicated and to
date and time the evidente was generated.
Ts
extend the life of an existing token beyond its expity or
text an optional data item that may contain additional
beyond subsequent revocation.
information, e.g., key identifier and/or the
An Evidente Recording Authority may be involved to
message identifier.
record evidente that tan later be retrieved in case of
TSA Time Stamp Authority.
dispute.
TST Time Stamp Token.
Trusted third Parties may be involved to differing degrees in
Z the result of the concatenation of y and z in that
yll the phases of non-repudiation. When exchanging evidente,
Order.
the Parties must either have the knowledge, or be informed,
or agree which non-repudiation policy is to be applicable to
the evidente.
5 Requirements
Depending on the basic mechanism used for generating
7 Digital signatures
non-repudiation tokens, and independent of the non-
repudiation Service supported by the non-repudiation mech-
Non-repudiation tokens are created by using digital signa-
anisms, the following requirements hold for the entities
tures. There are two types of digital signatures specified by
involved in a non-repudiation exchange in this part of
ISO / IEC 9796 and ISO/IEC 14888, namely,
lSQ/I EC 13888:
l signature giving message recovery, where the
5.1 The entities of a non-repudiation exchange shall
verification process reveals the message together with
trust the same trusted third Party (TTP), which may be
its specific redundancy,
composed of several independent TTPs bound by non-
repudiation agreements.
0
signature with appendix, where the verification process
requires the message as patt of the input.
be
5.2 The signature key belonging to an entity must
kept secret by that entity.
The choice of the signature mechanism is specified by the
5.3 The digital signature mechanism used shall satisfy
policy applied and is beyond the scope of this Standard.
the security requirements specified by the policy.
Signature algorithms and keys may have a pre-defined
5.4 Prior to the generation of evidente, the evidente
lifetime that is stated in the key ’s certificate issued by the
generator must know which non-repudiation policies the
certification authority. Therefore, the tokens defined in this
evidente shall be generated in accordance with, what type
Standard may also have a definite lifetime specified by non-
of evidente is to be generated, and which mechanisms are
repudiation policy. The mechanisms described in A.2 tan
to be used to verify the evidente.
be used to extend the lifetime of a token.
5.5 The mechanisms for generating or verifying evi-
dence must be available to the entities of the particular non-
8 Non-repudiation tokens
repudiation exchange, or a trusted authority must be avai-
lable to provide the mechanisms.
The usage of each non-repudiation token is depicted in
The evidente a fier may
5.6 generator nd veri need ac- Figure 1.
cess to a trusted time stamping or notary facility.
Non-repudiation of origin (NRO) token
8.1
6 Trusted third Party involvement
An NR0 token is used to provide protection against the
originator ’s false denial of having originated the message.
Trusted third Parties may be involved in the provision of
The NR0 token is
non-repudiation Services, depending on the mechanisms
used and the non-repudiation policy in forte. A Single
l generated by the originator A of the message m (or
trusted third Party may act in one or more of these roles,
authority C),
namely:
l sent by A to the recipient B,
l A Delivety Authority (DA) is trusted to deliver the
0
stored by the recipient B after verification.
message to the intended recipient and to provide the
non-repudiation of Submission or transgort token.
The structure of the NR0 token isa
l The use of asymmetric cryptographic techniques may
NR0 token = fexfl ID zj Il Sbq(zJ, with
require the invotvement of at least a trusted third Party
---------------------- Page: 4 ----------------------
0 ISOAEC ISOAEC 13888-3: 1997 (E)
then this data item is mandatoty and the signature
z, = Pol I I f, I I A I I B I I C I I Tg I I T, I I Q I I /mp(m).
SB[Z& in the NR0 token should be replaced by
token consists of wq 7
The information zI necessaty for an NR0
the following data items:
the date and time, according to the token generator,
at which the token was generated,
identifier of the non- repudiatio n
Poß the di stinguishing
to the evi dence,
policy (or policies) which apply
the date and time, according to the recipi ent, at
Tz
m was received (o ptiona
which the message
I>Y
a flag indicating non-repudiation of origin,
fl
8 an optional data item that may contain additional
A the distinguishing identifier of the originator of the
information, e.g., the distinguishing identifiers of
message m,
the message m, signature mechanism or hash-
B the distinguishing identifier(s) of the intended reci-
function, and information regarding certificates and
pient(s) of the message m (optional),
validity of public keys,
C the distinguishing identifier of the authority involved
consisting of mes-
the imp rint of the message m,
Imp(m)
(optional); if the token is generated by authority C
sage m or the hash-code of m.
then this data item is mandatory and the signature
SA(Z,) in the NR0 token should be replaced by
8.3 Non-repudiation of Submission (NRS) token
the date and time, according to the token
G An NRS token is created by a delivery authority. The evi-
generator, at wh ich the token was generated,
dence generator in this case is the delivety authority DA.
The originator A or a preceding delivery authority X has
the date and time, according to the o ri ginator ‘, at
Tl
sent a message m to the delivery authority DA. Delivery
which the message m was sent (optiona
1)
authority DA receives the message m and sends the NRS
Q an optional data item that may contain additional
token to A or the preceding transfer agent X, thus providing
the distinguishing identifiers of
information, e.g.,
evidente that the message has been submitted for onward
the message m, signature mechanism or hash-
delivety.
function, and information regarding certificates and
The NRS token is
validity of public keys,
0
generated by the delivery authority DA,
the imprint of the message m, consisting of mes-
Imp(m)
hash-code of m.
sage m or the
l sent by DA to the message originator A or a preceding
delivety authority X,
8.2 Non-repudiation of delivery (NRD) token
e
stored by A or X after verification.
An NRD token is used to provide protection against the The structure of an NRS token is:
recipient ’s false denial of having received and recognised
NRS token
= text, II z3 II SDA(Z~ with
the content of the message m.
The NRD token is z3 = Pol II f3 I I A II B I I C II D II E II Tg II T3 I I Q I I /mp(m).
0
generated by the recipient B (or authority C),
The information z3 necessaty for an NRS token consists of
the following data items:
0
sent by B to one or m ore entities including the message
originator if known,
4 the non-
Pol the distin guishing identifier of repudiation
policy (or policies) which apply to the evi dence,
0
stored by these entities after verification.
f3 a flag indicating non-repudiation of Submission,
The structure of an NRD token is:
A the distinguishing identifier of the originator of the
NRD token = text, Il z2 II AB with
message m (optional), where the validity of the
identifier A may or may not have been verified by
z2 = Pol II f2 II A II B I I C II Tg I I T2 II Q II /mp(m).
DA,
The information z2 necessaty for an NRD token consists of
ntended recipient
B the distinguishing identifier of the i
the following data items:
of the message m,
identifier of the non-repudiation
Pol the distinguishing
C the distinguishin
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.