ISO/IEC 13888-1:1997
(Main)Information technology — Security techniques — Non-repudiation — Part 1: General
Information technology — Security techniques — Non-repudiation — Part 1: General
Technologies de l'information — Techniques de sécurité — Non-répudiation — Partie 1: Généralités
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
STANDARD 13888-l
First edition
1997-l 2-01
Information technology - Security
techniques - Non-repudiation -
Part 1:
General
Technologies de /‘information - Techniques de skurit6 - Non-
rkpudia tion -
Parfie I: G&&alit&
---------------------- Page: 1 ----------------------
ISOAEC 13888~1:1997 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotech-
nical Commission) form the specialized system for worldwide standardization. National bodies
that are members of IS0 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. IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also
take part in the work.
In the field of information technology, IS0 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 ISOIIEC 138884 was prepared by Joint Technical Committee ISO/IEC
JTC 1, Information technology, Subcommittee SC 27, I-6 Security techniques.
ISO/IEC 13888 consists of the following parts, under the general title Information technology -
Security techniques - Non-rep&a tion:
- Pati I: 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 ISOAEC 1997
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 @o’tocopying and microfilm, without permission in
writing from the publisher.
ISOAEC Copyright Office l Case postale 56 l Cl-l-1 21 I Gen&ve 20 l Switzerland
Printed in Switzerland
---------------------- Page: 2 ----------------------
INTERNATIONAL STANDARD 0 ISO/IEC lSO/IEC 13888-l : 1997 (E)
Information technology - Security techniques - Non-repudiation
Part I:
Generall
-
evidence provided by a notary which provides as-
surance about data created or the action or event
1 Scope
performed by one or more entities.
Non-repudiation can only be provided within the context of a
The goal of the Non-repudiation service is to generate,
clearly defined security policy for a particular application
collect, maintain, make available and validate evidence
and its legal environment. Non-repudiation policies are
concerning a claimed event or action in order to resolve
described in ISO/IEC 10181-4.
disputes about the occurrence or non occurrence of the
event or action. This part of ISO/IEC 13888 describes a This part of ISO/IEC 13888 serves as a general model for
model for non-repudiation mechanisms providing evidence subsequent parts specifying non-repudiation mechanisms
based on cryptographic techniques. Non-repudiation using cryptographic techniques. ISO/I EC 13888 provides
mechanisms generic to the various non-repudiation non-repudiation mechanisms for the following phases of
services are first described and then applied to a selection non-repudiation:
of specific non-repudiation services such as:
-
evidence generation,
-
non-repudiation of origin,
-
evidence transfer, storage and retrieval, and
-
non-repudiation of delivery,
-
evidence verification.
-
non-repudiation of submission,
Dispute arbitration is outside the scope of ISO/IEC 13888.
-
non-repudiation of transport.
Non-repudiation services establish evidence: evidence
2 Normative references
establishes accountability regarding a particular event or
The following standards contain provisions which, through
action. The entity responsible for the action, or associated
reference in this text, constitute provisions of this part of
with the event, with regard to which evidence is generated,
ISO/IEC 13888. At the time of publication, the editions indi-
is known as the evidence subject. There are two main types
cated were valid. All standards are subject to revision, and
of evidence the nature of which depends on cryptographic
parties to agreements based on this part of ISO/IEC 13888
techniques employed:
are encouraged to investigate the possibility of applying the
- Secure Envelopes generated by an evidence
most recent editions of the standards indicated below.
generating authority using symmetric cryptographic
Members of IEC and IS0 maintain registers of currently
techniques,
valid International Standards.
-
Digital signatures generated by an evidence
IS0 7498-2:1989, Information processing systems - Open
generator or an evidence generating authority using
Systems Interconnection - Basic Reference Model - Part 2:
asymmetric cryptographic techniques.
Security Architecture.
Non-repudiation mechanisms provide protocols for the
ISO/I EC 9594-8: 1995, Information technology - Open
exchange of non-repudiation tokens specific to each non-
Systems Interconnection - The Directory: Authentication
repudiation service. Non-repudiation tokens consist of
framework.
Secure Envelopes and/or digital signatures and, optionally,
of additional data. Non-repudiation tokens may be stored as ISO/IEC 9796 (all parts), information technology - Security
non-repudiation information that may be used subsequently techniques - Digital signature schemes giving message
by disputing parties or by an adjudicator to arbitrate in
recovery.
disputes.
ISO/I EC 9797: 1994, Information technology - Security
Depending on the non-repudiation policy in effect for a
techniques - Data integrity mechanism using a
specific application, and the legal environment within which
cryptographic check function employing a block cipher
the application operates, additional information may be re-
algorithm.
quired to complete the non-repudiation information, e.g.,
I SO/I EC 10118- 1: 1994, Information technology - Security
-
evidence including a trusted time stamp provided by
techniques - Hash-functions - Part I: General.
a Time Stamping Authority,
IlSOfIEC 10181-1 :I 996, Information technol’ogy - Open Sy-
---------------------- Page: 3 ----------------------
ISOAEC 13888-l :1997 (E)
0 ISOIIEC
stems tnterconnection - Security frameworks for open sys- activities.
tems - Part 1: Overview.
Definitions from lSO/lEC 10181-4
3.5
ISOEC IO1 81-4:1997, information technology - Open
-
evidence generator: an entity that produces non-repu-
Security frameworks for open
Systems interconnection -
dia tion evidence.
systems - Part 4: Non-repudiation framework.
-
evidence subject: an entity whose involvement in an
lSO/IEC 14888-I 1 ) lnformation technology - Security tech-
event or action is established by evidence.
niques - Digital signatures with appendix - Part I: General.
-
evidence user: an entity that uses non-repudiation evi-
lSO/IEC 11770&) Information technology - Security tech-
dence.
niques - Key management - Part 3: Mechanisms using
-
evidence verifier : an entity that verifies non-repudiation
asymmetric techniques.
evidence.
-
non-repudiation service requester: an entity that re-
Definitions quests that non-repudiation evidence be generated for
a particular event or action.
Definitions from IS0 7498-2
36 . Definitions from ISO/iEC 11770-3
accountability: The property that ensures that the actb
-
key: A sequence of symbols that controls the operations
ons of an entity may be traced unique/y to the entity
of a cryptographic transformation (e.g., encipherment,
data integrity: The property that data has not been alte-
decipherment, cryptographic check-function computa-
red or destroyed in an unauthorised manner.
tion, signature calculation, or signature verification.
data origin authentication: The corroboration that the
source of data received is as claimed.
3.7 Definitions unique to this Standard on Non-
digital signature: Data appended to, or a cryptographic
repudiation
transformation of, a data unit that allows the recipient of
For the use of this multipart standard the following definiti-
the data unit to prove the source and integrity of the
ons apply:
data unit and protect against forgery e.g. by the recipi-
ent. 3.7.1 Certificate: An entity’s data rendered unforge-
able with the private or secret key of a certification authority.
security policy: The set of criteria for the provision of
security services.
3.7.2 Data storage: A means for storing information
from which data is submitted for delivery, or into which data
Definitions from ISO/lEC 9594-8
is put by the delivery authority.
certification authority: An authority trusted by one or
3.7.3 Delivery authority: An authority trusted by the
more users to create and assign certificates. Optionally
sender to deliver the data from the sender to the receiver,
the certification authority may create the users‘ keys.
and to provide the sender with evidence on the submission
and transport of data upon request.
Definitions from lSO/lEC 10118-l
3.7.4 Distinguishing identifier: Information which un-
hash-code: The string of bits that is the output of a
ambiguously distinguishes an entity in the non-repudiation
hash-function.
process.
hash-function: A function which maps strings of bits to
Evidence: Information that either by itself or
3.7.5
fixed-length strings of bits, satisfying the following two
when used in conjunction with other information is used to
properties:
establish proof about an event or action.
-
it is computational/y infeasible to find for a given out-
put an input which maps to this output, NOTE - Evidence does not necessarily prove truth or existence
of something (see proof) but contributes to establish proof.
-
it is computationafiy infeasible to find for a given
input a second input which maps to the same output. 3.7.6 Evidence requester: An entity requesting evi-
dence to be generated either bv another entity or by a
a
Definitions from lSO/lEC 10181-I
trusted third party.
security certificate: a set of security relevant data issued
Evidence subject: the entity responsible for the
3.7.7
by a security authority or trusted third party, together
action, or associated with the event, with regard to which
with security information which is used to provide the
evidence is generated.
integrity and data origin authentication.
3.7.8 Imprint: A string of bits, either the hash-code of
security token: a set of security relevant data that is
a data string or the data string itself.
protected by integrity and data origin authentication
3.7.9 Message Authentication Code: A data item
from a source which is not considered a security aut-
derived from a message using symmetric cryptographic
hority.
techniques and a secret key. It is used to check the integrity
trust: a relationship between two elements, a set of ac-
and origin of a message by any entity holding the secret
tivities and a security policy in which element x trusts
key.
element y if and only if x has confidence that y will be-
have in a well defined way (with respect to the activi- 3.7.10 Monitor (Monitoring Authority): A trusted third
ties) that does not violate the given security policy. party monitoring the actions and events and is trusted to
provide evidence about what was monitored.
trusted third party: a security authority or its agent, tru-
sted by other entities with respect to security-related
3.7.11 Non-repudiation exchange: A sequence of one
or more transfers of non-repudiation information (NRI) for
the purpose of non-repudiation.
I) To be published.
2
---------------------- Page: 4 ----------------------
0 ISOIIEC lSO/lEC 13888-l :1997 (E)
3.7.12 Non-repudiation information: A set of informa-
tion that may consist of the information about an event or
action for which evidence is to be generated and validated,
the evidence itself, and the non-repudiation policy in effect.
3.7.30 Originator: The entity that sends a message to
the recipient or makes available a message for which non-
3.7.13
Non-repudiation of Creation: This service is
repudiation services are to be provided.
intended to protect against an entity’s false denial of having
created the content of a message (i.e., being responsible for
3.7.31 Private key: That key of an entity’s asymmetric
the content of a message).
key pair which is usable only by that entity. In the case of an
asymmetric signature system, the private key and the as-
3.7.14 Non-repudiation of Delivery: This service is
sociated algorithms define the signature transformation.
intended to protect against a recipient’s false denial of hav-
ing received the message and recognised the content of a
3.7.32 Proof: The corroboration that evidence is valid in
message.
accordance with the non-repudiation policy in force.
3.7.15 Non-repudiation of Knowledge: This service is
NOTE - Proof is evidence that serves to prove truth or exis-
tence of something.
intended to protect against a recipient’s false denial of hav-
ing taken notice of the content of a received message.
Public key: That key of an entity’s asymmetric
3.7.33
3.7.16 Non-repudiation of Origin: This service is in- key pair which can be made public. In the case of an
tended to protect against the originator’s false denial of asymmetric signature system, the public key and the asso-
having created the content of a message and of having sent ciated algorithms define the verification transformation.
a message.
3.7.34 Public key certificate: A security certificate
3.7.17 Non-repudiation of Receipt: This service is in- which binds unforgeably the public key of an entity to the
entity’s distinguishing identifier, and which indicates the va-
tended to protect against a recipient’s false denial of having
lidity of the corresponding private key.
received a message.
3.7.18 Non-repudiation of Sending: This service is
intended to protect against the sender’s false denial of hav-
ing sent a message.
3.7.19 Non-repudiation of Submission: This service is 3.7.36 Redundancy: Any information that is known and
intended to provide evidence that a delivery authority has can be checked.
accepted the message for transmission.
3.7.37 Secret key: A key usable with symmetric crypto-
3.7.20 Non-repudiation of Transport: This service is graphic techniques and usable only by a set of specified
intended to provide evidence for the message originator that entities.
a delivery authority has delivered the message to the in-
3.7.38 Secure Envelope (SENV): A set of data items
tended recipient.
which is constructed by an entity in such a way that any
3.7.21 Non-repudiation policy: A set of criteria for the entity holding the secret key can verify their integrity and
provision of non-repudiation services. More specifically, a origin. For the purpose of generating evidence, the SENV is
set of rules to be applied for the generation and verification constructed and verified by a TTP with a secret key known
only to the TTP.
of evidence and for adjudication.
Signer: The entity generating a digital signature.
3.7.22 Non-repudiation token: A special type of secu- 3.7.39
rity token as defined in ISO/lEC 10181-I consisting of evi-
3.7‘40 Trusted third party: A security authority, or its
dence, and, optionally, of additional data.
agent, trusted by other entities with respect to security rela-
3.7.23 Notarization: The provision of evidence by a ted activities. In the context of this multipart standard, a
notary about the properties of the entities involved in an trusted third party is trusted by the originator, the recipient,
action or event, and of the data stored or communicated. and/or the delivery authority for the purposes of non-repu-
diation, and by another party such as an adjudicator.
3.7.24 Notarization token: A non-repudiation token
Trusted time stamp: A data item with time and
generated by a notary. 3.7.41
date information assured by a trusted time stamping aut-
3.7.25 Notary (notary authority): a trusted third party
hority.
trusted to provide evidence about the properties of the en-
3.7.42 Trusted time stamping authority: A trusted
tities involved and of the data stored or communicated, or to
extend the lifetime of an existing token beyond its expiry or third party trusted to provide evidence which includes the
time when the trusted time stamp is generated.
beyond subsequent revocation.
Verification key: A value required to verify a
3.7.26 NRD token: Non-repudiation of delivery token. A 3.7.43
cryptographic check value.
data item which allows the originator to establish non-re-
pudiation of delivery for a message.
3.7.44 Verifier: An entity that verifies an evidence.
3.7.27 NRO token: Non-repudiation of origin token. A
data item which allows recipients to establish non-repudia-
4 Notation and Abbreviations
tion of origin for a message.
A the distinguishing identifier of entity A.
NRS token: Non-repudiation of submission to-
3.7.28
ken. A data item which allows either the originator (sender) B the distinguishing identifier of entity B.
or the delivery authority to establish non-repudiation of
Certification Authority.
CA
submission for a message having been submitted for trans-
CHKx(y) the cryptographic check value computed on the
mission.
data yusing the key of entity X.
3.7.29 NRT token: Non-repudiation of transport token.
3
---------------------- Page: 5 ----------------------
0 ISOAEC
ISO/IEC 13888-l A997 (E)
generator has to know which non-repudiation policy is ac-
DA the distinguishing identifier of the delivery author-
ceptable to the verifier(s), the kind of evidence that is re-
ity.
quired and the set of mechanisms that are acceptable to the
a data item (flag) indicating the kind of non-repu-
fi
verifier(s).
diation service in effect.
5.3 The mechanisms for generating or verifying evidence
GNRT
Generic Non-repudiation Token.
have to be either available to the entities of the particular
the hash-code of data string y.
WY)
non-repudiation exchange, or a trusted authority has to be
available to provide the mechanisms and perform the nec-
the imprint of the data string y, either (I) the
mNYJ
hash-code of data string y, or (2) the data string essary functions on behalf of the evidence requester.
Y
5.4 Keys appropriate to the mechanisms being used
m a message for which evidence is generated.
(i.e., private keys for asymmetric techniques, and secret
keys for symmetric techniques) are possessed (and, where
MAC Message Authentication Code.
necessary, shared) by the relevant entities.
NA Notary Authority.
5.5
The evidence user and the adjudicator are required
NRDT Non-repudiation of delivery token.
to be able to verify evidence.
NRI Non-repudiation Information.
5.6 The time information required in an evidence con-
NROT
Non-repudiation of origin token.
sists of both the time the event took place and of the time
NRST Non-repudiation of submission token.
the evidence was generated.
NR7-T Non-repudiation of transport token.
5.7 If a trusted time is required or the clock provided by
the party generating an evidence cannot be trusted, then a
NT Notarization token.
time stamping authority shall be accessible by the evidence
OS/ Open Systems Interconnection
generator or the evidence verifier.
PO1 the distinguishing identifier of the non-repudiation
policy (or policies) which apply to evidence.
smv Secure Envelope.
6 Organisation of the Standard
SIG the digital signature obtained by applying a digital
Non-repudiation services are modelled by first describing (in
signature operation to a message.
clause 7) the roles of the entities involved in the provision
the signature operation using a signature algo-
and verification of evidence. The involvement of trusted third
SX
rithm and the private key of entity X. parties in the various phases of non-repudiation, in particu-
lar in the provision and verification of evidence, is described
text a data item forming a part of the token that may
in clause 8. Evidence generation and verification mecha-
contain additional information, e.g., key identifier
nisms are described in Clause 9, involving the generation of
and/or the message identifier.
Secure Envelopes and digital signatures based on symmet-
date and time the evidence was generated.
G
ric and asymmetric cryptographic techniques respectively.
date and time the event or action took place.
Cryptographic check functions common to both basic mech-
fi
anisms are derived in order to better represent non-repudia-
TSA the distinguishing identifier of the Trusted Time
tion tokens. In clause IO three kinds of tokens are defined,
Stamping Authority.
firstly, the generic non-repudiation token suitable for many
TST Time Stamping Token generated by the TSA.
non-repudiation services, secondly, the time stamping token
the distinguishing identifier of the Trusted Third
77P generated by a trusted time stamping authority and, thirdly,
Party. the notarization token generated by a notary to provide evi-
dence about the properties of the entities involved and of
Verification operation applied to a Secure Enve-
VX
the data stored or communicated. Specific non-repudiation
lope or a digital signature by applying a verifica-
services and non-repudiation tokens are described in clause
tion algorithm using the verification key of entity
11. An example of using specific non-repudiation tokens in a
X.
messaging environment is given in clause 12.
denotes the result of the concatenation of yand z
w
in that order.
7 Generic Non-repudiation Service
5 Requirements
Entities involved in the provision and
7.1
Depending on the derivation of the cryptographic check verification of evidence
value used for generating Secure Envelopes and digital sig-
A number of distinct entities may be involved in the provi-
natures, and independent of the non-repudiation service
sion of a non-repudiation service.
supported by the non-repudiation mechanisms, the following
Three entities are involved in the evidence generation
requirements hold for the entities involved in a non-repudia-
phase:
tion exchange:
-
the evidence requester that wants to obtain evidence,
The entities of a non-repudiation exchange shall trust
5.1
-
the evidence subject that performs an action or is invol-
a trusted third party (TTP).
ved with an event,
NOTE - When using symmetric cryptographic algorithms a TTP
-_
the evidence generator that generates evidence.
is always required. When using asymmetric cryptographic
algorithms a public key certificate has to be generated by an
Two entities are involved in the evidence verification phase:
off-line TTP. A public key certificate is not necessarily required
-
if the digital signature is generated by a ITP
the evidence user who wants to verify evidence but
cannot do it directly,
5.2 Prior to the generation of evidence, the evidence
4
---------------------- Page: 6 ----------------------
0 ISOAEC lSO/lEC 13888~1:1997 (E)
- the evidence verifier that is able to verify evidence upon
token generation, or delivery roles), as dictated by the non-
request from the evidence users
repudiation policy. A single trusted third party may act in
one or more of these roles.
In the evidence generation phase, the event or action is rel-
ated to an evidence subject. The evidence may be provided
81 . Evidence Generation Phase
upon request from the evidence requester or by the evi-
dence subject itself. Evidence is information that can be used to resolve disputes
and is generated by an evidence generator on behalf of an
If neither the evidence subject nor the evidence requester is
evidence subject, a trusted third party, or upon request of an
able to provide evidence directiy, evidence is produced by
evidence requester.
an evidence generator. Evidence is then returned or made
-
As an on-line authority actively involved in every in-
available to the evidence requester. Evidence may then be
stance of the non-repudiation service, the trusted third
transferred or made available to other entities.
party generates evidence alone on behalf of the evi-
In the evidence verification phase, an evidence user wishes
dence subject. On-line generation of cryptographic
to verify that the evidence is correct. If the evidence user is
check values and non-repudiation tokens may be re-
unable to verify the evidence directly! the evidence is veri-
quired when symmetric cryptographic techniques are
fied by an evidence verifier upon request from the evidence
used for the provision of evidence, i.e., to generate
user.
Secure Envelopes as defined in part 2 of lSO/iEC
13888.
7.2 Non-repudiation Services
- As an in-line evidence generation authority, the trusted
This general model applies to the following six fundamental
third party generates the evidence by itself, e.g., as de-
non-repudiation services: non-repudiation of creation, non-
livery authority.
repudiation of sending, non-repudiation of receipt, and non-
-
As an off-line authority which is not involved in every
repudiation of knowledge, non-repudiation of submission,
instance of a non-repudiation service, the trusted third
and non-repudiation of transport. Other non-repudiation
party provides off-line pubtic key certificates related to
services may be provided by grouping some of these fun-
entities generating evidence based on signatures.
damental services. Non-repudiation of origin can be pro-
-
As a token generation authority, the trusted third party
vided by combining non-repudiation of creation and non-re-
constructs any type of non-repudiation token composed
pudiation of sending, non-repudiation of delivery can be pro-
of one or more non-repudiation tokens provided by the
vided by combining non-repudiation of receipt and non-re-
evidence subject or by one or more trusted authorities.
pudiation of knowledge.
-
As a digital signature generating authority, the trusted
third party generates digital signatures on behalf of the
8 Trusted Third Party Involvement
evidence subject or an evidence requester.
-
As a time stamping authority, the trusted third party is
Trusted third parties may be involved in the provision of
trusted to provide evidence which includes the time
non-repudiation services, depending on the mechanisms
when the time stamping token was generated.
used and the non-repudiation policy in force. The use of
-
As a notary authority (notary), the trusted third party is
asymmetric cryptographic techniques requires the involve-
trusted to provide evidence about the properties of the
ment of an off-line trusted third party to guarantee the gen-
entities involved and of the data stored or communi-
uineness of the keys. The trusted third party may be part of
cated between the entities. The notary is trusted to ex-
a chain of TTPs provided that they are bound by agree-
tend the lifetime of an existing token beyond its expiry
ments on non-repudiation services. The use of symmetric
or beyond subsequent revocation.
cryptographic techniques requires the involvement of an on-
-
line trusted third party to generate and validate Secure
As a monitoring authority, the trusted third party moni-
Envelopes (SEA/V). The non-repudiation policy in force may
tors the actions and events and is trusted to provide
require evidence to be generated partly or totally by a evidence about what was monitored.
trusted third party.
8.2 Evidence Transfer, Storage and Retrieval
The non-repudiation policy in force may also require that:
Phase
-
a trusted time stamp be provided by a trusted time
stamping authority, or During this phase, evidence is transferred between parties,
or to and from storage. Depending on the non-repudiation
- a notary be involved to certify the properties of the enti-
policy in effect, the activities of this phase may not always
ties involved and of data stored or communicated, or to
occur in all cases of a non-repudiation service. The activities
extend the lifetime of an existing token beyond its expiry
of this phase may be performed by trusted third parties.
or beyond subsequent revocation, or
-
When acting as a delivery authority, the trusted third
-
a monitoring authority be involved to provide evidence
party will be in-line for non-repudiation of submission
about the properties of the entities involved and of the
and non-repudiation of transport.
data stored or communicated.
-
When acting as an evidence record keeping authority,
Trusted third parties may be involved to differing degrees in
the trusted third party records evidence that can later be
the phases of non-repudiation. When exchanging evidence,
retrieved by an evidence user or an adjudicator.
the parties shall either know, be informed, or agree as to
which non-repudiation policy is to be applicable to the evi-
8.3 Evidence Verification Phase
dence.
When acting as an evidence verification authority, the tru-
There may be a number of trusted third parties involved ac-
sted third party acts as an on-line authority which is trusted
ting in various roles (e.g., notary, time stamping, monitoring,
by the evidence user to verify each kind of non-repudiation
key certification, signature generation, signature verification,
information provided in the non-repudiation token. When
Secure Envelope generation, Secure Envelope verification,
evidence is generated using symmetric cryptographic tech-
5
---------------------- Page: 7 --------------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.