ISO/IEC 10181-4:1997

Information technology - Open Systems Interconnection - Security frameworks for open systems: Non-repudiation framework - Part 4:

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Cadres de sécurité dans les systèmes ouverts: Cadre de non-répudiation — Partie 4:

General Information

• Status: Published
• Publication Date: 09-Apr-1997
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 20-Dec-2007
• Completion Date: 30-Oct-2025

Overview

ISO/IEC 10181-4:1997 - Information technology - Open Systems Interconnection - Security frameworks for open systems: Non-repudiation framework - defines a general framework for providing non-repudiation services in open systems. The standard explains the purpose and scope of non-repudiation (collecting, maintaining and validating irrefutable evidence so events or actions cannot be denied), describes forms of service (notably proof of origin and proof of delivery), identifies classes of mechanisms, and sets out management considerations. It is conceptual - it does not prescribe protocol exchanges or specific cryptographic algorithms.

Key topics and technical requirements

• Core concepts: evidence generation, storage, validation and use for dispute resolution; roles of Trusted Third Parties (TTPs) and adjudicators.
• Service forms: non-repudiation with proof of origin and proof of delivery; additional application-specific forms (e.g., MHS/EDI services).
• Mechanism classes (described, not mandated):
  • TTP security tokens (secure envelopes)
  • Security tokens with tamper-resistant modules
  • Digital signatures and time-stamping
  • In-line TTPs and notarization
• Evidence lifecycle & management: collection, retention, recovery and handling of compromised evidence; interaction with security policies.
• Threats and assurances: identification of threats to non-repudiation and relationship to other security services - authentication, access control, confidentiality, integrity, and audit.
• Interoperability guidance: how frameworks map into OSI/Basic Reference Model contexts; recommendations for use by other standards without mandating algorithms (cryptographic algorithm choice is left open).

Practical applications

• Legal and compliance scenarios requiring provable proof of sending or receiving data (e.g., contract exchanges, financial transactions).
• Secure messaging and value transfer systems (MHS, EDI, email and message handling systems).
• Distributed databases, archival systems and audit/logging services where evidence must be preserved and verifiable.
• PKI and security product design where digital signatures, time stamping, and TTP integration are required.

Who should use this standard

• Security architects and system designers implementing non-repudiation requirements.
• PKI implementers, vendors of secure messaging, notarization and time-stamping services.
• Standards developers and compliance officers aligning policies to interoperable non-repudiation frameworks.
• Legal and risk teams specifying evidentiary requirements for digital transactions.

Related standards

• ISO/IEC 7498 (OSI Basic Reference Model) and CCITT/ITU-T X.800 (security architecture) - foundational references.
• ISO/IEC 10181 series (parts 1–7) - other security framework components (authentication, access control, confidentiality, integrity, audit).
• ITU-T Recommendation X.813 - related non-repudiation guidance.

Keywords: ISO/IEC 10181-4, non-repudiation framework, Open Systems Interconnection, digital signature, trusted third party, time stamping, security services, proof of origin, proof of delivery, PKI.

Standards Content (Sample)

INTERNATIONAL
ISO/lEC
STANDARD
10181-4
First edition
1997-04-O 1
Information technology - Open Systems
Interconnection - Security frameworks for
open systems: Non-repudiation framework
Technologies de /‘information -
lnterconnexion de syst&mes owe&
(OS/‘) - Cadres de s&wit6 pour /es systemes ouverts: Cadre de
non-rkpudia tion
Reference number
ISO/IEC 10181=4:1997(E)
Contents
Page
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Identical Recommendations 1 International Standards
. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Paired Recommendations 1 International Standards equivalent in technical content
3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Basic Reference Model definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Security Architecture definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Security Frameworks Overview definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Additional definitions
4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..........................................................................................................
5 General discussion of Non-repudiation
.....................................................................................................
5.1 Basic concepts of Non-repudiation
Roles of a Trusted Third Party .
5.2
..................................................................................................................
5.3 Phases of Non-repudiation
............................................................................................
5.4 Some forms of Non-repudiation services
......................................................................................
5.5 Examples of OS1 Non-repudiation evidence
................................................................................................................................
6 Non-repudiation policies
Information and facilities .
.........................................................................................................................................
7.1 Information
...................................................................................................................
Non-repudiation facilities
7.2
.........................................................................................................................
8 Non-repudiation mechanisms
.........................................................
8.1 Non-repudiation using a TTP security token (secure envelope)
................................................
Non-repudiation using security tokens and tamper-resistant modules
8.2
...........................................................................................
8.3 Non-repudiation using a digital signature
...............................................................................................
8.4 Non-repudiation using Time Stamping
Non-repudiation using an in-line Trusted Third Party .
8.5
..........................................................................................................
8.6 Non-repudiation using a Notary
.................................................................................................................
8.7 Threats to Non-repudiation
0 ISO/IEC 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 photocopying and
microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CI-I-1211 Gen&ve 20 l Switzerland
Printed in Switzerland
ii
0 ISO/IEC ISO/IEC 10181-4:1997(E)
.............................................................................
9 Interactions with other security services and mechanisms
.....................................................................................................................................
9.1 Authentication
9.2 Access Control .
Confidentiality .
9.3
9.4 Integrity .
...................................................................................................................................................
9.5 Audit
....................................................................................
Annex A - Non-repudiation in OS1 Basic Reference Model
..........................................................................................................
Annex B - Non-repudiation Facilities Outline
.......................................................................................
Annex C - Non-repudiation in store and forward systems
...................................................................................................
Annex D - Recovery in a Non-repudiation service
.................................................................................................................
Annex E - Interaction with the Directory
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex F - Bibliography
. . .
ISO/IEC 10181=4:1997(E) 0 ISO/IEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical 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, ISOLIEC JTC 1. 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.
International Standard ISO/IEC 10181-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 21, Open systems interconnection, data management and open distributed processing, in
collaboration with ITU-T. The identical text is published as ITU-T Recommendation X.8 13.
ISO/IEC 10181 consists of the following parts, under the general title Information technology - Open Systems
Interconnection - Security frameworks for open systems:
Part 1: Overwiew
Part 2: Authentication framework
Part 3: Access control framework
Part 4: Non-repudiation framework
- Part 5: Confidentiality framework
Part 6: Integrity framework
Part 7: Security audit and alarms framework
Annexes A to F of this part of ISO/IEC 1018 1 are for information only.
iv
0 ISOLIEC ISO/IEC 10181=4:1997(E)
Introduction
The goal of the Non-repudiation service is to collect, maintain, make available and validate irrefutable evidence
concerning a claimed event or action in order to resolve disputes about the occurrence or non-occurrence of the event or
action. The Non-repudiation service can be applied in a number of different contexts and situations. The service can
apply to the generation of data, the storage of data, or the transmission of data. Non-repudiation involves the generation
of evidence that can be used to prove that some kind of event or action has taken place, so that this event or action
cannot be repudiated later.
In an OS1 environment (see CCITT Rec. X.800 and IS0 7498-2) the Non-repudiation service has two forms:
-
Non-repudiation with proof of origin which is used to counter false denial by a sender that the data or its
contents has been sent.
-
counter false denial by a recipient that the data or
Non-repudiation with proof of delivery which is used to
its contents (i.e. the information that the data represents) has been received.
Applications which make use of OS1 protocols may require other forms of the Non-repudiation service which are
specific to particular classes of applications. For example, MHS (ITU-T Rec. X.402 1 IS0 10021-2) defines the
Non-repudiation of submission service, while the ED1 Messaging System (see Recommendation X.435) defines the
Non-repudiation of retrieval and Non-repudiation of transfer services.
not limited to OS1 communications but may be interpreted more broadly to include
The concepts in this framework are
such uses as creation and storage of data for later use.
This Recommendation 1 International Standard defines a general framework for the provision of a Non-repudiation
service.
This framework:
-
expands upon the concepts of Non-repudiation services described in CCITT Rec. X.800 and IS0 7498-2
and describes how they may be applied to Open Systems;
-
describes alternatives for the provision of these services; and
-
explains the relationship of these services to other security services.
Non-repudiation services may require:
-
adjudicators who will arbitrate disputes that may arise as a result of repudiated events or actions; and
-
Trusted Third Parties who will assure the authenticity and integrity of the data to be used for the
verification of evidence.
This page intentionally left blank

ISO/IEC 10181-4 : 1997 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
SECURITY FRAMEWORKS FOR OPEN SYSTEMS:
NON-REPUDIATION FRAMEWORK
1 Scope
This Recommendation 1 International Standard addresses the application of security services in an Open Systems
environment, where the term “Open Systems” is taken to include areas such as Database, Distributed Applications, Open
Distributed Processing and OSI. The Security Frameworks are concerned with defining the means of providing
protection for systems and objects within systems, and with the interactions between systems. The Security Frameworks
are not concerned with the methodology for constructing systems or mechanisms.
The Security Frameworks address both data elements and sequences of operations (but not protocol elements) which are
used to obtain specific security services. These security services may apply to the communicating entities of systems as
well as to data exchanged between systems, and to data managed by systems.
This Recommendation 1 International Standard:
-
defines the basic concepts of Non-repudiation;
defines general Non-repudiation services;
-
identifies possible mechanisms to provide the Non-repudiation services;
-
identifies general management requirements for Non-repudiation services and mechanisms.
As with other security services, Non-repudiation can only be provided within the context of a defined security policy for
a particular application. The definitions of security policies are outside the scope of this Recommendation 1 International
Standard.
The scope of this Recommendation 1 International Standard does not include specification of details of the protocol
exchanges which need to be performed in order to achieve Non-repudiation.
This Recommendation I International Standard does not describe in detail the particular mechanisms that can be used to
support the Non-repudiation services nor does it give details of the supporting security management services and
protocols.
Some of the procedures described in this framework achieve security by the application of cryptographic techniques.
This framework is not dependent on the use of a particular cryptographic or other algorithm or on particular
cryptographic techniques (i.e. symmetric or asymmetric) although certain classes of Non-repudiation mechanisms may
depend on particular algorithm properties. Indeed it is likely, in practice, that a number of different algorithms will be
used. Two entities wishing to use cryptographically-protected data must support the same cryptographic algorithm.
[ 1 NOTE - Although IS0 does not standardize cryptographic algorithms, it does standardize the procedures used to register
them in ISO/IEC 9979.1
A number of different types of standard can use this framework including:
standards that incorporate the concept of Non-repudiation;
1)
standards that specify abstract services that include Non-repudiation;
2)
standards that specify uses of a Non-repudiation service;
3)
standards that specify the means of providing Non-repudiation within an open system architecture; and
4)
mechanisms.
standard s that specify Non-repudiation
5)
ITU-T Rec. X.813 (1996 E) 1
ISO/IEC 10181-4 : 1997 (E)
Such standards can use this framework as follows:
- standards of type l), 2), 3), 4) or 5) can use the terminology of this framework;
-
standards of type 2), 3), 4) or 5) can use the facilities defined in clause 7; and
-
standards of type 5) can be based upon the classes of mechanism defined in clause 8.
2 Normative references
The following Recommendations and International Standards contain provisions, which through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
21 . Identical Recommendations 1 International Standards
-
ITU-T Recommendation X.200 (1994) I ISO/IEC 7498-l : 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.509 (1993) I ISO/IEC 9594~8:1995, Information technology - Open Systems
Interconnection - The Directory: AuthenticationjLFamework.
-
ITU-T Recommendation X.8 10 (1995) I ISO/IEC 10 18 l- 1: 1996, Information technology - Open Systems
Interconnection - SecurityJi-ameworks for open systems: Overview.
22 . Paired Recommendations 1 International Standards equivalent in technical content
-
CCITT Recommendation X.800 (1991), S ecurity architecture for Open Systems Interconnection for
CCITT applications.
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2: Security Architecture.
3 Definitions
31 . Basic Reference Model definitions
This Recommendation I International Standard builds on concepts developed in ITU-T Rec. X.200 I ISO/IEC 7498-l and
makes use of the following term defined in it:
(N)-entity.
32 . Security Architecture definitions
This Recommendation I International Standard builds on the concepts developed in CCITT Rec. X.800 and IS0 7498-2
and makes use of the following terms defined in it:
-
access control;
-
audit (also security audit);
-
authentication;
-
channel;
-
cryptographic checkvalue;
-
~rypt~gqhy;
-
data integrity (also integrity);
data origin authentication;
-
decipherment;
2 ITU-T Rec. X.813 (1996 E)
ISO/IEC 10181-4 : 1997 (E)
-
digital signature (also signature);
-
encipherment;
-
k%
-
key management;
-
notarization;
-
repudiation;
-
security audit trail (also audit trail, log);
-
threat.
33 . Security Frameworks Overview definitions
This Recommendation I International Standard builds on the concepts developed in ITU-T Rec. X.810 I
ISO/IEC 10 18 1- 1 and makes use of the following terms defined in it:
-
certification authority;
-
digital fingerprint;
-
hash function;
-
one-way function;
-
private key;
-
public key;
-
revocation list certificate;
-
seal;
-
secret key;
-
security certificate;
-
security domain;
-
security token;
trusted third party.
. Additional definitions
For the purposes of this Recommendation 1 International Standard, the following definitions apply:
3.4.1 compromised evidence: Evidence that was, at one time, satisfactory but which no longer has the confidence
of the Trusted Third Party or adjudicator.
3.4.2 counter-signature: A digital signature appended to a data unit which has already been signed by a different
entity (e.g. a TTP).
evidence: Information that, either by itself or when used in conjunction with other information, may be used to
3.4.3
resolve a dispute.
3.4.4 evidence generator: An entity that produces Non-repudiation evidence.
NOTE - This entity may be the Non-repudiation service requester, the originator, the recipient or multiple parties wcnking
in conjunction (e.g. a signer and co-signer).
3.4.5 evidence subject: The entity whose involvement in an event or action is established by evidence.
3.4.6 evidence user: An entity that uses Non-repudiation evidence.
3.4.7 evidence verifier: An entity that verifies Non-repudiation evidence.
message authentication code: A cryptographic checkvalue that is used to provide data origin authentication
3.4.8
and data integrity.
ITU-T Rec. X.813 (1996 E) 3
ISO/IEC 10181-4 : 1997 (E)
requester: An entity that be generated for a
3.4.9 Non-repudiation service requests that Non-repudiation evidence
particular event or action.
Trusted Third Party with whom data is registered so that later assurance of the accuracy of the
3.4.10 notary: A
characteristics of the data can be provided.
3.4.11 originator: In the context of data transfer, an entity that originates the data in an action that is subject to a
Non-repudiation service.
3.4.12 recipient: In the context of data transfer, an entity that receives the data in an action that is subject to a
Non-repudiation service.
NOTE - In the logical model of Non-repudiation, other entities may be considered. E.g. the owner is the entity that makes
an original message and a transfer agent is the entity that transfers the message; in this context, entities are modeled as originators or
recipients.
4 Abbreviations
Open Systems Interconnection
OS1
CA Certification Authority
TTP Trusted Third Party
Message Authentication Code
MAC
5 General discussion of Non-repudiation
51 . Basic concepts of Non-repudiation
The Non-repudiation service involves the generation, verification and recording of evidence, and the subsequent
retrieval and re-verification of this evidence in order to resolve disputes. Disputes cannot be resolved unless the evidence
has been previously recorded.
The purpose of the Non-repudiation service described in this framework is to provide evidence about a particular event
or action. Non-repudiation services may be requested by entities other than those involved in the event or action.
Examples of actions which may be protected with a Non-repudiation service are:
-
sending an X.400 message;
-
inserting a record in a database; and
-
invoking a remote operation.
When messages are involved, to provide proof of origin, the identity of the originator and the integrity of the data must
be confirmed. To provide proof of delivery, the identity of the recipient, and the integrity of the data must be confirmed.
In some cases, evidence concerning the context (e.g. date, time, location of the originator/recipient) may also be
required.
The service provides the following facilities which can be used in the event of an attempted repudiation:
-
verification of generated evidence;
-
retrieval and re-verification of the evidence.
Disputes may be settled between parties directly through inspection of the evidence. However, a dispute may have to be
resolved by an adjudicator who evaluates the evidence and determines whether or not the disputed action or event
occurred. Adjudication can only be provided effectively if the parties to the dispute accept the authority of the
adjudicator. For the evidence provided to be accepted by the adjudicator, it must usually be assured by one or more
Trusted Third Parties. The adjudicator can optionally be the Trusted Third Party that assures the evidence.
Non-repudiation mechanisms use a number of types of Trusted Third Parties and forms of evidence.
4 ITU-T Rec. X.813 (1996 E)
ISO/IEC 10181-4 : 1997 (E)
.
52 Roles of a Trusted Third Party
One or more Trusted Third Parties may be involved in the Non-repudiation service.
Trusted Third Parties which support Non-repudiation without being actively involved in each use of the service are
known as Off-line Trusted Third Parties. A TTP which is actively involved in the generation or verification of evidence
is known as an On-line TTP. An On-line TTP which acts as an intermediary in all interactions is known as an
In-line TTP.
A Trusted Third Party may be required to record and/or gather evidence as well as being required to vouch for the
validity of the evidence. There may be a number of Trusted Third Parties involved acting in various roles (e.g. Notary,
Time Stamping, Monitoring, Key Certification, Signature Generation, Signature Verification, and Delivery Authority
roles). A single Trusted Third Party may act in one or more of these roles.
In an Evidence Generation role, a TTP cooperates with a Non-repudiation service requester to generate evidence.
In an Evidence Recording role, a TTP records evidence that can later be retrieved by an evidence user or an adjudicator.
In a Time Stamping role, a TTP is trusted to provide evidence which includes the time when the time stamping request
was received.
the action or the event and is trusted to what was
In a Monitoring role, a TTP monitors provide evidence about
monitored.
In a Key Certification role, a TTP provides Non-repudiation certificates related to an evidence generator in order to
assure the validity of a public key to be used for Non-repudiation purposes.
In a Key Distribution role, a TTP provides keys to the evidence generators and/or the evidence verifiers. It may also
place constraints on the use of the keys, in particular when symmetrical techniques are used.
In a Signature Generation role, a TTP is trusted to provide evidence in the form of a digital signature on behalf of the
evidence subject.
In an Evidence Verification role, a TTP verifies evidence at the request of an entity.
In a Signature Verification role, a TTP is trusted by the evidence user to verify evidence in the form of a digital
signature.
NOTE - The Signature Generation role is a particular case of the Evidence Generation role. The Signature verification role
is a particular case of the evidence verification role.
of the data (such as its integrity, origin, time or
In a Notary role, a TTP provides assurance about the properties
that have been previously registered with the TTP.
destination) that are communicated between two or more entities and
In a Delivery Authority role, a TTP interacts with the intended recipient of data and attempts to release the data to the
recipient. It then provides evidence that the data was delivered, that the data was not delivered, or that delivery was
attempted but that no confirmation of receipt was received In the last case, the evidence user cannot determine whether
the data was received by the intended recipient or not.
53 Phases of Non-repudiation
.
Non-repudiation is composed of four distinct phases:
-
evidence generation;
-
evidence transfer, storage and retrieval;
-
evidence verification; and
-
dispute resolution.
Figure 1 illustrates the first three phases; Figure 2 illustrates the fourth phase.
ITU-T Rec. X.813 (1996 E) 5
ISO/IEC 10181-4 : 1997 (E)
Non-repudiation security policy
Information
I about
I
Evidence Evidence
Evidence Evidence
generation generation
subject user
requester requester
I
I
Requests verification
\\obsewation / Request generation
Yes / No
Evidence Evidence *
Evidence
Evidence
generator
verifier
other information
I
Trusted third party
TIS07760-96/dOl
NOTE - This figure is illustrative, not definitive.
Figure 1 - Entities involved in the generation, transfer, storage/retrieval and verification phases
Non-repudiation
policy
TIS07770-96/d02
NOTE - This figure is illustrative, not definitive.
Figure 2 - Dispute Resolution phase of a Non-repudiation process
6 ITU-T Rec. X.813 (1996 E)
ISO/IEC 10181-4 : 1997 (E)
5.3.1 Evidence Generation
In this phase, the Evidence Generation Requestor requests the Evidence Generator to generate evidence for an event or
action. An entity whose involvement in the event or action is established by the evidence is known as an Evidence
Subject. Different groupings of these entities are possible: an Evidence Subject and an Evidence Generator may be the
same entity as may the Evidence Subject, the Evidence Generation Requestor and the Evidence Generator; the Evidence
Generation Requestor and the Trusted Third Party; the Evidence Generator and Trusted Third party; and the Evidence
Generation Requestor, the Evidence Generator and Trusted Third party. Depending on the type of Non-repudiation
service, the evidence may be generated by the evidence subject, perhaps in conjunction with the services of a Trusted
Third Party, or by a Trusted Third Party alone.
NOTE - Depending on the context of the Non-repudiation service, relevant evidence will typically include the identities of
the entities involved, the data, and the time and date. Additional information such as mode of transfer (e.g. OS1 communication;
database storage and retrieval); location of entities involved; distinguishing identifier; and the “owner”/ereator oftbe data, could also
be included.
Evidence Transfer, Storage and Retrieval
5.3.2
During this phase, evidence is transferred between entities or to or from storage (see Figure 1).
5.3.3 Evidence Verification
In this phase, the evidence is verified by an evidence verifier at the request of an evidence user. The purpose of this
phase is for an evidence user to gain confidence that the supplied evidence will indeed be adequate in the event of a
dispute arising. Trusted Third Party services may additionally be involved for providing information to verify the
evidence. The evidence user and the evidence verifier may be the same entity.
5.3.4 Dispute Resolution
an adjudicator has the responsibility of reso living disputes betw ‘een parties. The di sputing
In the dispute resolution phase,
the plaintiff and the defendant. The dispute resolution phase is depicted in Figure 2.
parties are sometimes known as
When the adjudicator resolves disputes, it collects evidence from the disputing parties and/or the Trusted Third Parties.
The process used by an adjudicator to resolve disputes is outside the scope of this Recommendation 1 International
Standard.
This phase is not always needed. If all interested parties agree that an event or action occurred (or agree that it didn’t
occur) then there is no dispute to resolve. Furthermore, even if a dispute arises, it can sometimes be resolved directly
between the parties without the need for an adjudicator. For example, if one of the parties to the dispute is honest but
mistaken, then they may realize that they are wrong when they are shown the other party’s evidence.
needed for every instance of the Non-repudiation service, all Non-repudiation
Although this phase is not always
resoluti .on phase. That is, they must enable disputes to be resolved if they occur.
mechanisms must support the dispute
54 . Some forms of Non-repudiation services
the many forms, the Non-repudiation service associated with
There are many forms of Non-repudiation services. Among
the transfer of data is one that is frequently considered.
two entities, namely the originator and the recipient. Potential disputes
The transfer of a message involves at least
concerning the event include the following:
-
involvement in the event
disputes in which the originator’s is disputed e.g. the alleged originator claims
by the recipient or forged by a masquerading attacker.
that the message was either forged
-
disputes in which the recipient’s involvement in the event is disputed e.g. the alleged recipient claims the
message was either not sent, lost in transit, or only received by a masquerading attacker.
For messaging, Non-repudiation services may be classified according to the kind of dispute they can help resolve.
The transfer of messages from an originator to a recipient may be regarded as being a sequence of separate events:
-
the transmission of the message from the originator to a transfer agent;
-
the transmission of the message between transfer agents (if more than one transfer agent is involved); and
the transmission of the message from a transfer agent to the recipient.
ITU-T Rec. X.813 (1996 E)
ISO/IEC lOlt31-4 : 1997 (E)
which concerning that event.
For each of these events there are forms of the Non-repudiation service provide evidence
Accordingly, the following additional Non-repudiation services are identi fied:
-
the Non-repudiation with proof of submission service is used to protect against a transfer agent’s false
denial of having accepted a message for transmission (either from the originator or from another transfer
agent).
-
the Non-repudiation with proof of transport service is used to protect against a transfer agent’s false
denial of having transmitted a message (either to the recipient or to another transfer agent).
NOTE - The Non-repudiation with proof of submission and Non-repudiation with proof of transport services do not
provide evidence that an entity is responsible for the message or has understood the information that the message contains.
55 . Examples of OS1 Non-repudiation evidence
Depending on the OS1 Non-repudiation services invoked, particular forms of evidence are needed for each type of event
or action as illustrated below.
5.5.1 For Non-repudiation of origin
The ev idence must include the following (which can be either signed or notarized):
-
originator;
the distinguishing identifier of the
-
the data sent, or a digital fingerprint of the data.
The evidence may also include the following:
the distinguishing identifier of the recipient;
-
the date and time that the data was sent.
5.5.2 For Non-repudiation of delivery
The evidence must include the following (which can be either signed or notarized):
-
the distinguishing identifier of the recipient;
-
the data received, or a digital fingerprint of the data.
The evidence may also include the following:
-
the distinguishing identifier of the originator;
-
the date and time when the data was received.
When a Delivery Authority is used, the evidence may also include the following (which can be either signed or
notarized):
-
the distinguishing identifier of the Delivery Authority;
-
the date and time when the delivery was first attempted by the Delivery Authority;
-
the date and time when a ready to receive was obtained from the recipient;
-
the date and time when the delivery was performed by the Delivery Authority;
-
Delivery Authority was unable to perform the delivery;
the date and time when the
-
the probable cause of the non-delivery conditions (e.g. communications channel broken);
-
an indication of the handling requirements that were met when delivering the message.
6 Non-repudiation policies
A Non-repudiation policy may include the following:
-
Rules for the generation of evidence e.g. specifications of the classes of activity for which
Non-repudiation evidence should be generated; specifications of the TTPs to be used to generate
evidence; the roles in which those TTPs may act; the procedures that entities must follow when
generating evidence.
-
Rules for the verification of evidence e.g. specifications of the TTPs whose evidence is acceptable; for
each TTP, the forms of evidence that will be accepted from that TTP.
-
Rules for the storage of evidence e.g. the means to be used to ensure the integrity of stored evidence.
ITU-T Rec. X.813 (1996 E)
ISO/IEC 10181-4 : 1997 (E)
-
e.g. specification of th .e purposes for which evi dence may be used.
Rules for the use of evidence
it may be difficult to prevent unauthorized use of evidence.
NOTE - With some Non-repudiation mechanisms
-
Rules for adjudication e.g. specification of the agreed adjudicator(s) that may settle a dispute.
Each of these sets of rules may be defined by a different authority. For example, the rules for generation of evidence
could be defined by the owner of a system, while the rules for adjudication could be defined by the law of the country in
which the system exists.
are inconsistent, then the Non-repudiation service may fail to operate correctly e.g. by
If different parts of the policy
fact occur to be successfully denied during the dispute resolution phase.
allowing an event which did in
The Non-repudiation policy itself may be used by the adjudicator when resolving a dispute. For example, the adjudicator
might refer to the Non-repudiation policy to determine whether the rules for generation of evidence have been complied
with.
Security policies can be explicitly stated, or implicitly defined by implementations. An explicit statement of the Non-
repudiation policy (e.g. a natural language document) can help detect conflicts between different parts of the policy and
can also aid the adjudicator.
in which evidence has been compromised or in which the keys used to
Non-repudiation policies also deal with cases
revoked.
generate the evidence have been compromised or
Non-repudiation policies for interactions between security domains may result from agreements between independent
security domains or may be imposed by a super-domain.
7 Information and facilities
71 . Information
Information that can be used to resolve a dispute is known as evidence. Evidence may be stored locally by an evidence
user or may be stored by a Trusted Third Party. Particular forms of evidence are digital signatures, secure envelopes and
security tokens. Digital signatures are used with public key techniques while secure envelopes and security tokens are
used with secret key techniques. Examples of information that can constitute evidence include:
-
An identifier of the Non-repudiation security policy.
-
The distinguishing identifier of the originator.
-
The distinguishing identifier of the recipient.
A digital signature or Secure Envelope.
-
The distinguishing identifier of the evidence generator.
-
The distinguishing identifier of the evidence generation requestor.
-
The message, or a digital fingerprint of the message.
NOTE - When the digital fingerprint is used in place of the message, an indicator is required to identify the
method used in the derivation.
-
The message identifier.
-
key needed to validate the security token.
An indication of the secret
-
An identification of the particular public key needed to validate the digital signature (e.g. the
distinguishing identifier of the Certification Authority and certificate serial number).
-
The distinguishing identifier of the notary, time stamping TTP, In-line TTP, etc.
-
A unique identifier for the evidence.
-
The date and time that the evidence was deposited or recorded.
The date and time the digital signature or security token was generated.
ITU-T Rec. X.813 (1996 E) 9
ISO/IEC 10181-4 : 1997 (E)
72 . Non-repudiation facilities
This subclause identifies a number of Non-repudiation facilities that may be used to generate, send and validate evidence
or to deposit evidence with a TTP.
7.2.1 Management-related facilities
Non-repudiation management-related activities may involve distribution of information, passwords or keys (using key
This may involve use of a protocol between
management) to entities required to perform Non-repudiation.
communicating entities and other entities providing Non-repudiation services. Non-repudiation management may also
involve the revocation of the keys used to produce evidence.
The Non-repudiation management facilities allow a user to obtain, modify and delete information which is necessary for
the provision of Non-repudiation. In broad terms these facilities are:
-
install management information;
-
modify management information;
-
delete management information;
-
list management information.
The following management-related actions may be required in support of Non-repudiation services:
-
recording the event in the audit trail;
-
recording of the results of dispute arbitration;
-
local reporting of the event;
-
remote reporting of the event.
The specific action to be taken for each event is dependent on the security policy in operation.
7.2.2 Operation-related facilities
7.2.2.1 Generate Evidence
This facility is used to generate evidence. Evidence may be generated directly by the evidence subject (without involving
a TTP), by one or more TTPs acting on behalf of the evidence subject, or by the evidence subject and one or more TTPs
acting together.
Candidate inputs include:
-
the Non-repudiation policy;
-
the distinguishing identifier of the evidence subject;
-
the distinguishing identifier of the Non-repudiation service requester;
-
the data, or a digital fingerprint of the data;
-
the distinguishing identifier of the TTP that will be used to generate the digital signature, the security
token, or other evidence.
Candidate outputs include:
-
evidence (e.g. a digital signature or a security token);
-
the distinguishing identifier of the TTP that generated the digital signature, the security token, or other
evidence.
7.2.2.2 Generate Time Stamp
This facility is used to generate time stamps.
Candidate inputs include:
-
the distinguishing identifier of the entity requesting the time stamp;
-
the distinguishing identifier of the TTP in the Time Stamping role;
-
the data (e.g. signed message; acknowledgment;) or a digital signature or a digital fingerprint of the data.
10 ITU-T Rec. X.813 (1996 E)
ISO/IEC 10181-4 : 1997 (E)
Candidate outputs include:
-
counter-signature computed by the TTP;
-
an identification of the method and/or cryptographic algorithm used to generate the counter-signature
(which secondarily indicates if the data or a digital fingerprint of the data is used);
-
the distinguishing identifier of the Time Stamping Service;
-
the date and time when the time stamping request was received;
the date and time when the counter-signature was generated;
-
a signed message which includes a time stamp and a digital fingerprint of the input data.
7.2.2.3 Generate Notarized Evidence
This facility is used to deposit evidence with the TTP.
Candidate inputs include:
-
the distinguishing identifier of the evidence generation requestor;
-
the evidence (e.g. a digital signature or security token);
-
the distinguishing identifier of the evidence generator;
-
the distinguishing identifier of the Non-repudiation policy.
Candidate outputs include:
-
the recording number of the evidence;
-
the date and time of evidence recording.
7.2.2.4 Validate Evidence
This facility is used to validate evidence.
Candidate inputs include:
-
evidence;
-
the distinguishing identifier of the evidence subject;
-
the distinguishing identifier of the evidence user;
-
the identifier of the key to be used for evidence verification;
-
an indication of the intended use of the evidence (so that an assessment can be made to determine if the
ate for this use under the Non-repudiation policy).
evi dence is appropri
Candidate outputs include:
-
the result of the verification (i.e. valid or invalid);
-
the distinguishing identifier of the evidence subject;
-
the distinguishing identifier of the evidence generator;
-
the distinguishing identifier of the evidence verification requestor;
-
the distinguishing identifier of the TTP that verified the digital signature or security token;
-
the data or the digital fingerprint of the data.
7.2.2.5 Generate evidence for data transfers via an in-line TTP
Instead of sending data and/or acknowledgements between an originator and a recipient directly, data may be transferred
through a TTP, so that Non-repudiation evidence may be assured by the TTP. This facility may also be used when it is
suspected that a recipient could claim communication channel failure to deny delivery of the data.
To use this facility the following must be presented to the In-line TTP:
-
the data;
-
the distinguishing identifier of the recipient,
ITU-T Rec. X.813 (1996 E) 11
ISO/IEC 10181-4 : 1997 (E)
In addition, the following may be presented:
-
a digital fingerprint of the data;
-
the distinguishing identifier of the originator;
-
a digital signature;
-
the distinguishing identifier of the In-line TTP;
-
the non-repudiation policy.
Candidate outputs from the In-line Trusted Third Party include:
-
the distinguishing identifier of the In-line Trusted Third Party;
-
the distinguishing
...

NORME ISO/CEI
INTERNATIONALE 10181-4
Premikre kdition
1997-04-01
Technologies de I’information -
lnterconnexion de systemes ouverts
(03) - Cadres de s6curit6 dans les
syst&mes ouverts: Non-rbpudiation
lnforma tion technology - Open Sys terns Interconnection - Security
frame works for open systems: Non-repudiation frame work
Numkro de refkrence
ISO/CEI 10181-4:1997(F)
ISOKEI 10181-4 : 1997 (F)
Sommaire
Page
Domaine d’ application .
...................................................................................................................................
2 References normatives
......................................................................
Recommandations I Normes internationales identiques
2.1
....... 2
2.2 Paires de Recommandations I Normes internationales equivalentes par leur contenu technique
......................................................................................................................................................
3 Definitions
.........................................................................
3.1 Definitions relatives au modele de reference de base
Definitions relatives a l’architecture de securite .
3.2
............................................................
3.3 Definitions relatives a l’aperqu general des cadres de securite
Definitions supplementaires .
3.4
4 Abreviations .
............................................................................................
Considerations g&r&ales sur la non-repudiation
..............................................................................................
5.1 Concepts de base de la non-repudiation
5.2 Roles d’un tiers de confiance .
Phases de la non-repudiation .
5.3
................................................................................................
5.4 Formes du service de non-repudiation
.....................................................................................
5.5 Exemples de preuve OS1 de non-repudiation
........................................................................................................................
6 Politiques de non-repudiation
.......................................................................................................................
7 Informations et fonctionnalites
7.1 Informations .
7.2 Fonctionnalites de non-repudiation .
.....................................................................................................................
8 Mecanismes de non-repudiation
......... 12
8.1 Non-repudiation au moyen d’un jeton de securite de tiers de confiance (enveloppe securisee)
.......................................
8.2 Non-repudiation au moyen de jetons de securite et de modules inviolables
......................................................................
8.3 Non-repudiation au moyen d’une signature numerique
............................................................................
8.4 Non-repudiation au moyen de pointages temporels
...............................................................
8.5 Non-repudiation au moyen d’un tiers de confiance en ligne
..............................................................................................
8.6 Non-repudiation au moyen d’un notaire
.....................................................................................
8.7 Menaces pouvant affecter la non-repudiation
.......................................................................
Interactions avec d’autres services et mecanismes de securite
Authentification .
9.1
9.2 Controle d’acces .
..................................................................................................................................... 16
9.3 Confidentialite
Integrite .
9.4
9.5 Audit .
Gestion des cl& .
9.6
0 ISO/CEI 1997
Droits de reproduction reserves. Sauf prescription differente, aucune partie de cette publication ne
peut etre reproduite ni utilisee sous quelque forme que ce soit et par aucun procede, electronique ou
mecanique, y compris la photocopie et les microfilms, sans l’accord ecrit de l’editeur.
ISO/CEI Copyright Office l Case postale 56 l CH- 1211 Geneve 20 l Suisse
Version franCaise tiree en 1998
Imprime en Suisse
ii
ISOKEI 10181-4 : 1997 (F)
0 ISO/CEI
................................................................... 18
Annexe A - Non-repudiation dans le modele de reference de base OS1
A. 1 Non-repudiation avec preuve d’origine . 18
.............................................................................................. 18
A.2 Non-repudiation avec preuve de remise
Annexe B - Description des fonctionnalites de non-repudiation . 19
............................................................................. 20
Annexe C - Non-repudiation dans les systemes en mode differe
Annexe D - Reprise dans un service de non-repudiation .
Annexe E - Interaction avec 1’Annuaire . 23
Annexe F - Bibliographie .
iii
ISOKEI 10181-4 : 1997 (F) 0 ISO/CEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CEI (Commission
electrotechnique internationale) forment ensemble un systeme consacre a la
normalisation internationale consideree comme un tout. Les organismes nationaux
membres de I’ISO ou de la CEI participent au developpement de Normes
internationales par l’intermediaire des comites techniques trees par l’organisation
concernee afin de soccuper des differents domaines particuliers de l’activite
technique. Les comites techniques de I’ISO et de la CEI collaborent dans des
domaines d’interet commun. D’autres organisations internationales, gouverne-
mentales et non gouvernementales, en liaison avec I’ISO et la CEI participent
egalement aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CEI ont tree un
comite technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adopt& par le comite technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvees conformement aux procedures qui requierent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISO/CEI 1018 l-4 a ete elaboree par le comite technique
mixte ISOKEI JTC 1, Technologies de Z’information, sous-comite SC 21,
Interconnexion des systemes ouverts, gestion des don&es et traitement distribue
ouvert, en collaboration avec I’UIT-T. Le texte identique est publie en tant que
Recommandation UIT-T X.81 3.
L’ISOKEI 1018 1 comprend les parties suivantes, presentees sous le titre general
Technologies de 1 ‘information - Interconnexion de systemes ouverts (OSI) -
Cadres de se’curite’ dans les systemes ouverts:
Partie I: Presentation
- Partie 2: Cadre general d’authentification
- Partie 3: Controle d’acces
- Partie 4: Non-repudiation
- Partie 5: Confidentialite
- Partie 6: Integrite’
Partie 7: Audit de securite et alarme
Les annexes A a F de la presente partie de l’ISO/CEI 1018 1 sent donnees unique-
ment a titre d’information.
iv
0 ISOKEI ISOKEI 10181-4 : 1997 (F)
Introduction
Le service de non-repudiation a pour objet de collecter, de conserver, de diffuser et de valider des preuves irrefutables
concernant un evenement ou une action revendique afin de resoudre des litiges concernant la realite ou la non-realite de
cet evenement ou de cette action. Le service de non-repudiation peut etre applique dans un certain nombre de contextes
et de situations differents. Ce service peut s’appliquer a la production de donnees, a la conservation de donnees ou a la
transmission de donnees. La non-repudiation implique la production de preuves qui peuvent etre utilisees pour prouver
qu’un certain type d’evenement ou d’action a eu lieu, de man&e que cet evenement ou cette action ne puisse etre repudie
ulterieurement.
Dans un environnement d’interconnexion OS1 (voir la Rec. X.800 du CCITT et I’ISO 7498-2), le service de
non-repudiation a deux formes:
-
non-repudiation avec preuve d’origi ne, qui est utilisee pour contrer un faux deni d’envoi des donnees ou
ur expedi teur;
de leur contenu par le
-
non-repud iation avec preuve de remise, q ui est util .isee pour con trer un faux deni de recepti on des donnees
contenu (c’est-a-dire ce que les donn 6es representent) leur destinataire.
ou de leur
Par
Les applications qui font usage des protocoles OS1 peuvent necessiter d’autres formes du service de non-repudiation qui
soient specifiques de classes d’application particulieres. Par exemple, la messagerie MHS (Rec. UIT-T X.402 I
IS0 1002 l-2) definit la non-repudiation du service de soumission, tandis que le systeme de messagerie ED1 (voir la
Recommandation X.435) definit la non-repudiation des services de consultation et des services de transfert.
I mai s peuvent etre interpret&
Les concepts contenus dans le present cadre ne sont pas limi tes aux communications OS
plus largement afin d’inclure des usages tels que la creation et la conservation des donnees pour usage ulterieur.
La presente Recommandation I Norme internationale definit un cadre general pour la fourniture d’un service de
non-repudiation.
Ce cadre:
-
developpe les concepts des services de non-repudiation qui sont decrits dans la Rec. X.800 du CCITT et
I’ISO 7498-2; il decrit la faGon dont ces concepts peuvent etre appliques aux systemes ouverts;
-
decrit les variantes de fourniture de ces services;
-
explique la relation de ces services avec d’autres services de securite.
Les services de non-repudiation peuvent necessiter:
-
des arbitres qui regleront les litiges qui peuvent apparaitre a la suite d’evenements ou d’actions repudies;
-
des tiers de confiance qui garantiront l’authenticite et l’integrite des donnees a utiliser pour la verification
des preuves.
This page intentionally left blank

ISO/CEI 10181-4 : 1997 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE
SYSTkMES OUVERTS (OSI) - CADRES DE SIkURITk DANS LES
SYSThMES OUVERTS: NON-RhPUDIATION
1 Domaine d’application
La presente Recommandation I Norme internationale traite de l’application des services de securite dans un
environnement de systemes ouverts, ou le terme les bases de donnees, les applications &parties, le traitement reparti ouvert et l’interconnexion OSI. Les cadres de
securite concernent la definition des moyens d’assurer la protection des systemes et des objets contenus dans ces
systemes. 11s concernent egalement les interactions entre ces systemes. Les cadres de securite ne concernent pas la
methode de construction des systemes ou des mecanismes.
Les cadres de securite traitent aussi bien des elements de donnees et des sequences d’operations (mais non des elements
de protocoles) qui sont utilises pour obtenir des services de securite specifiques. Ces services de securite peuvent
s’appliquer aux entites communicantes des systemes ainsi qu’aux donnees echangees entre systemes et aux donnees
g&es par les systemes.
La presente Recommandation I Nor-me internationale:
definit les concepts fondamentaux de la non-repudiation;
-
definit les services generaux de non-repudiation;
-
identifie les mecanismes permettant de fournir les services de non-repudiation;
-
identifie les prescriptions g&k-ales de gestion pour services et mecanismes de non-repudiation.
Comme avec d’autres services de securite, la non-repudiation ne peut etre fournie que dans le cadre d’une politique de
securite definie pour une application particuliere. Les definitions des politiques de securite sont hors du domaine
d’application de la presente Recommandation I Norme internationale.
Le domaine d ‘application de la presente Recommandation I Norme internationale ne comprend pas la specification des
details relati fs aux echanges protocolaires qui doivent etre e ffectues afin d’utiliser le service de non-repudiation.
La presente Recommandation I Nor-me internationale ne decrit pas en detail les mecanismes particuliers que l’on peut
utiliser pour prendre en charge le service de non-repudiation; elle ne donne pas non plus de details concernant les
services et protocoles de gestion de securite qui sont utilises a l’appui du service de non-repudiation.
Certaines des procedures d&rites dans le present cadre realisent la securite en appliquant des techniques
cryptographiques. Ce cadre ne depend pas de l’utilisation d’un algorithme cryptographique ou non cryptographique
particulier, ni de techniques cryptographiques particulieres (c’est-a-dire symetriques ou asymetriques) bien que certaines
classes de mecanismes de non-repudiation puissent dependre de proprietes algorithmiques particulieres. En fait, il est
probable qu’en pratique un certain nombre d’algorithmes differents seront utilises. Deux entites souhaitant utiliser des
donnees protegees par cryptographic doivent toujours prendre en charge le meme algorithme cryptographique.
[NOTE - Bien que I’ISO ne normalise pas les algorithmes cryptographiques, cette organisation normalise, dans
l’ISO/CEI 9979, les proc6dures utiliskes pour les enregistrer.]
Un certain nombre de types de norme differents peuvent utiliser ce cadre, a savoir:
les nor-rues qui integrent le concept de non-repudiation;
1)
les normes qui specifient des services abstraits comportant la non-repudiation;
2)
les normes qui specifient les utilisateurs d’un service de non-repudiation;
3)
4) les normes qui specifient les moyens de fournir le service de non-repudiation dans une architecture de
systeme ouvert;
les normes qui specifient des mecanismes de non-repudiation.
5)
Rec. UIT-T X.813 (1996 F)
ISO/CEI 10181-4 : 1997 (F)
De telles normes peuvent utiliser ce cadre comme suit:
-
les normes de type l), 2), 3), 4) ou 5) peuvent utiliser la terminologie de ce cadre;
-
les normes de type 2), 3), 4) ou 5) peuvent utiliser les fonctionnalites definies dans l’article 7 de ce cadre;
-
les normes de type 5) peuvent etre fondles sur les classes de mecanisme definies dans l’article 8 de ce
cadre.
2 Rbfbrences normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la reference
qui y est faite, constituent des dispositions valables pour la presente Recommandation I Norme internationale. Au
moment de la publication, les editions indiquees etaient en vigueur. Toutes Recommandations et Normes sont sujettes a
revision et les parties prenantes aux accords fond& sur la presente Recommandation I Nor-me internationale sont invitees
a rechercher la possibilite d’appliquer les editions les plus recentes des Recommandations et Normes indiquees ci-apres.
Les membres de la CEI et de I’ISO possedent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des telecommunications de 1’UIT tient a jour une liste des Recommandations UIT-T en vigueur.
21 . Recommandations 1 Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISO/CEI 7498-l: 1994, Technologies de Z’infirmation -
Interconnexion des syskmes ouverts - ModtYe de r&&ence de base: Ze modGZe de r&%ence de base.
-
Recommandation UIT-T X.509 (1993) I ISOKEI 9594-8: 1995, Technologies de Z’information -
- L ‘annuaire: cadre d’authent@cation.
Interconnexion des systGmes ouverts
-
Recommandation UIT-T X.810 (1995) I ISO/CEI 1018 l- 1: 1996, Technologies de Z’infirmation -
Interconnexion des systkmes ouverts - Cadres de skuritkpour Zes systsmes ouverts: aperCu g&&al.
22 . Paires de Recommandations 1 Normes internationales kquivalentes par leur contenu technique
-
Recommandation X.800 du CCITT (199 l), Architecture de se’curite’ pour Z’interconnexion en systgmes
ouverts d’applications du CCITT.
-
IS0 7498-2: 1989, Systkmes de traitement de Z’information - Interconnexion de systkmes ouverts - A4odkZe
de rkfkrence de base - Partie 2: Architecture de skuritk.
3 Dkfinitions
Dbfinitions relatives au modhle de Gf&ence de base
31 .
La presente Recommandation I Nor-me internationale est fondle sur les concepts developpes dans la Rec. UIT-T X.200 I
ISOKEI 7498-l et fait usage du terme suivant, qui y est defini:
entite (N).
32 . Dkfinitions relatives A l’architecture de skuritk
La presente Recommandation I Nor-me internationale est fondle sur les concepts developpes dans la Rec. X.800
du CCITT et ITS0 7498-2 et fait usage des termes suivants, qui y sont definis:
controle d’acces;
audit (de securite);
-
authentification;
-
voie;
-
valeur de controle cryptographique;
-
cryptographic;
-
integrite (des donnees);
-
authentification de l’origine des donnees;
-
dechiffrement;
2 Rec. UIT-T X.813 (1996 F)
ISO/CEI 10181-4 : 1997 (F)
-
signature (numerique);
-
chiffrement;
-
cl&
-
gestion de cl&;
notarisation;
-
repudiation;
-
journal d’audit de securite; journal d’audit; journal;
-
menace.
33 . Dbfinitions relatives A l’aperqu ghhal des cadres de skurit6
La presente Recommandation I Norme internationale est fondle sur les concepts developpes clans la Rec. UIT-T X.810 I
ISO/CEI 1018 1- 1 et fait usage des termes suivants, qui y sont definis:
-
autorite de certification;
-
empreinte numerique;
-
fonction d’adressage disperse;
-
fonction a sens unique;
-
cle privee;
-
cle publique;
-
certificat de liste de revocation;
-
cachet;
-
cachet&
-
cle secrete;
-
certificat de securite;
-
domaine de securite;
-
jeton de securite;
-
tiers de confiance.
34 . Dbfinitions supplkmentaires
Pour les besoins de la presente Recommandation I Nor-me internationale, les definitions suivantes s’appliquent.
3.4.1 preuve compromise: preuve, qui avait ete satisfaisante a un moment don@ mais en laquelle le tiers de
confiance ou l’arbitre n’a plus confiance.
contresignature: signature numerique ajoutee a une unite de differente
3.4.2 donnees deja signee par une entite
(par
exemple un tiers habilite).
3.4.3 preuve: information qui, par elle-meme ou par association avec d’autres informations, peut etre utilisee pour
resoudre un litige.
3.4.4 ghhateur de preuve: entite qui produit une preuve de non-repudiation.
NOTE - Cette entite peut Etre le demandeur du service de non-rkpudiation, l’expkditeur, le destinataire ou des parties
multiples travaillant de concert (par exemple un signataire et un cosignataire).
3.4.5 sujet de preuve: entite dont l’implication dans un evenement ou une action est demontree par une preuve.
utilisateur de preuve: entite qui utilise une preuve de non-repudiation.
3.4.6
3.4.7 vb-ificateur de preuve: entite qui verifie une preuve de non-repudiation.
code d’authentification de message: valeur de controle cryptographique utilisee pour assurer l’integrite des
3.4.8
donnees et l’authentification de leur origine.
Rec. UIT-T X.813 (1996 F) 3
ISO/CEI 10181-4 : 1997 (F)
non-repudiation: entite qui demande qu’une preuve de non-repudiation soit
3.4.9 demandeur du service de
ou pour une action particuliere.
produite pour un evenement particulier
3.4. 10 notaire: tiers de confiance chez qui les donnees sont enregistrees afin de pouvoir garantir plus tard l’exactitude
des caracteristiques de ces donnees.
du transfer-t de donnees, entite qui expedie les donnees par une action qui est
3.4.11 expbditeur: dans le contexte
non-repudiation.
sujette B un service de
destinataire: dans le contexte du transfert de donnees, entite qui reqoit les donnees par une action qui est
3.4.12
sujette a un service de non-repudiation.
NOTE - Dans le modkle logique de non-repudiation, d’autres entitks peuvent intervenir. Par exemple, le propriktaire est
l’entite qui formule un message original et un agent de transfert est l’entit6 qui transfkre le message; dans ce contexte, les entitk seront
assimilees h des entith exp6ditrices ou destinataires.
4 Abrhiations
CA Autorite de certification (certzjkation authority)
MAC Code d’authentification de message (message authentication code)
OS1 Interconnexion des systemes ouverts (open systems interconnection)
TTP Tiers de confiance (trusted thirdparty)
5 Considhations ghkkales sur la non-repudiation
51 . Concepts de base de la non-rkpudiation
Le service de non-repudiation implique la production, la verification et l’enregistrement de preuves, ainsi que la
consultation et la reverification ulterieures de ces preuves, en cas de besoin. Les litiges ne peuvent etre resolus que si les
preuves ont ete enregistrees au prealable.
L’objet du service de non-repudiation decrit dans ce cadre est de fournir une preuve au sujet d’un evenement particulier
ou d’une action particuliere. Le service de non-repudiation peut etre demande par des entites autres que celles qui
participent a l’evenement ou a l’action. Exemples d’action pouvant etre protegee par un service de non-repudiation:
-
expedition d’un message X.400;
-
insertion d’un article dans une base de donnees;
invocation d’une operation distante.
Lorsqu’il s’agit de messages, l’identite de l’expediteur et l’integrite des donnees doivent etre confirmees pour prouver
l’origine des messages. Pour apporter la preuve d’une remise des donnees, il faut confirmer l’identite du destinataire et
l’integrite des donnees remises. Dans certains cas, des preuves peuvent egalement etre requises concernant le contexte
(par exemple, la date, l’heure, l’emplacement de l’expediteur/destinataire).
Ce service offre les options supplementaires suivantes, qui peuvent etre utilisees en cas de tentative de repudiation:
-
production de preuve;
enregistrement de preuve;
verification de la preuve produite;
consultation et reverification de la preuve.
Les litiges peuvent etre regles directement entre parties prenantes, par examen des preuves. Un litige peut parfois devoir
etre regle par un arbitre, qui evalue les preuves et determine si l’action ou l’evenement litigieux a eu lieu. L’arbitrage ne
peut etre assure efficacement que si les parties au litige acceptent l’autorite de l’arbitre. Pour que les preuves fournies
soient acceptees par l’arbitre, il faut generalement qu’elles soient confirmees par un ou par plusieurs tiers de confiance.
En option, l’arbitre peut etre le tiers de confiance qui confirme la preuve. Les mecanismes de non-repudiation font appel
a un certain nombre de types de tiers de confiance et de formes de preuve.
4 Rec. UIT-T X.813 (1996 F)
ISOKEI 10181-4 : 1997 (F)
52 . R6les d’un tiers de confiance
Un ou plusieurs tiers de confiance peuvent etre impliques dans le service de non-repudiation.
Les tiers de confiance qui assurent la non-repudiation sans etre activement impliques dans chaque utilisation du service
sont appeles < dans la verification de preuves est appele < d’intermediaire dans toutes les interactions est appele < Un tiers de confiance peut etre appele a enregistrer et/au a recueillir des preuves; il peut egalement etre appele a attester
la validite des preuves. Un certain nombre de tiers de confiance peuvent etre impliques dans divers roles (par exemple
les roles de notaire, de pointeur temporel, de surveillant, de certificateur de cle, de producteur de signature, de
verificateur de signature et d’autorite de remise). Un meme tiers de confiance peut agir au titre d’un ou de plusieurs de
ces roles.
Dans le role de producteur de preuve, un tiers de confiance coop&e avec un demandeur de service de non-repudiation
pour produire des preuves.
Dans le role d’enregistreur de preuve, un tiers de confiance enregistre des preuves qui pourront etre consultees
ulterieurement par un utilisateur de preuve ou par un arbitre.
Dans le role de pointeur temporel, un tiers de confiance est tense apporter une preuve telle que le moment ou la
demande de pointage temporel a ete recue.
Dans le role de surveillant, un tiers de confiance controle l’action ou l’evenement et est tense donner la preuve de ce qui
a ete surveille.
de certificateur de cle, un tiers de confiance fournit des certificats de non-repudiation associes a un
Dans le role
generateur de preuve afin de garantir la validite d’une cle publique a utiliser pour des fins de non-repudiation.
Dans le role de distributeur de cl&, un tiers de confiance fournit des cl& aux generateurs de preuve et/au aux
verificateurs de preuve. 11 peut aussi imposer des contraintes a l’utilisation des cl&, en particulier lorsque des techniques
symetriques sont utilisees.
de un tiers de confiance est tense fournir une preuve sous la for-me d’une signature
Dans le r-61 e de producteur signature,
numerique au nom du sujet de preuve.
Dans le role de verificateur de preuve, un tiers de confiance verifie la preuve a la demande d’une autre entite.
Dans le role de verificateur de signature, un tiers de confiance est tense verifier une preuve, pour le compte d’un
utilisateur de preuve, sous la forme d’une signature numerique.
NOTE - Le r6le de producteur de signature est un cas particulier du r6le de producteur de preuve. Le r6le de vh-ificateur
de signature est un cas particulier du r61e de v&ificateur de preuve.
fournit une assura nce au sujet des proprietes des donnees communiquees
Dans le role de notaire, un tiers de confiance
deux ou pl us de deux entites, telles que 1 ‘integrite, l’origine, l’heure ou la des tination des donnees.
entre
Dans le role d’autorite de remise, un tiers de confiance entre en interaction avec le destinataire p&vu des donnees et
essaye de les lui remettre. 11 fournit ensuite la preuve que les donnees ont ete remises, qu’elles n’ont pas ete remises ou
que la remise a ete tentee mais qu’aucune confirmation de reception n’a ete recue. Dans ce dernier cas, l’utilisateur de la
preuve ne peut pas determiner si les donnees ont ete reGues par le destinataire prevu ou non.
Phases de la non&pudiation
53 .
La non-repudiation se compose de quatre phases distinctes:
la production des preuves;
-
le transfer-t, la conservation et la consultation des preuves;
-
la verification des preuves;
-
la resolution des litiges.
La Figure 1 montre les trois premieres phases. La Figure 2 montre la quatrieme phase.
Rec. UIT-T X.813 (1996 F) 5
ISOKEI 10181-4 : 1997 (F)
Politique de skurit6 de non-rkpudiation
.
,
-, Infor;;tions ,
I I-
Demandeur de Demandeur de
Sujet de preuve
Utilisateur de
production de
production de
preuve
preuves preuves
Vbrification des demandes
ction des demandes
Oui / Non
Transfert
3’.
Preuve Preuve
et
-b
conservation/
consultation
Vhificateur des preuves
I
et autres
Preuves et autres
informations
Tiers de confiance
TI S07760-96/dO 1
NOTE - Cette figure, donn6e 2 titre d’illustration, n’est pas dkfinitive.
Figure 1 - Entitbs impliquees dans les phases de production, de transfer& de consultation/conservation et de
vkrification des preuves
Politique de
non-repudiation
TI SO7770-96/d02
I VOTE - Cette figure, donrke h titre d’illustration, n’est pas definitive.
Figure 2 - Phase de rksolution des litiges lors d’un processus de non-rkpudiation
Rec. UIT-T X.813 (1996 F)
ISO/CEI 10181-4 : 1997 (F)
5.3.1 Production des preuves
Dans cette phase, le demandeur de production de preuve demande au generateur de preuve de produire la preuve d’un
evenement ou d’une action. Une entite dont la participation a cet evenement ou a cette action est etablie par la preuve est
appelee ccsujet de preuve>>. Differents groupages de ces entites sont possibles: un sujet de preuve et un producteur de
preuve peuvent etre la meme entite, de meme que le sujet de preuve, le demandeur de production de preuve et le
generateur de preuve; le demandeur de production de preuve et le tiers de confiance; le generateur de preuve et le tiers
de confiance; et le demandeur de production de preuve, le generateur de preuve et le tiers de confiance. Selon le type de
service de non-repudiation, la preuve peut etre produite par le sujet de preuve, eventuellement en conjonction avec les
services d’un tiers de confiance, ou par celui-ci uniquement.
NOTE - En fonction du contexte du service de non-repudiation, les preuves applicables comprendront normalement
l’identite des entites mises en jeu, les donnees, l’heure et la date. D’autres informations pourront etre ajoutees, telles que: le mode de
transfert (par exemple communication OSI, conservation et consultation d’une base de don&es); l’emplacement des entites en cause;
l’identificateur distinctif; et le < 5.3.2 Transfer& conservation et consultation des preuves
Dans cette phase, la preuve est transferee d’une entite a une autre ou a destination/en provenance d’une memoire (voir
la Figure 1).
5.3.3 Wrification des preuves
Dans cette phase, la preuve est controlee par un verificateur de preuve a la demande d’un utilisateur de preuve. L’objet de
cette phase est de donner a un utilisateur de preuve l’assurance que la preuve fournie sera vraiment suffisante en cas
d’apparition d’un litige. Des services de tiers de confiance peuvent y etre ajoutes afin de donner des informations
permettant de verifier la preuve. Une meme entite peut assumer les roles d’utilisateur de preuve et de verificateur de
preuve.
5.3.4 Rksolution des litiges
Dans la phase de resolution des litiges, un arbitre a la responsabilite de resoudre les litiges entre parties Les parties en
litige sont parfois designees par les termes de @aignant>> et de <~dkj?mdeurx La phase de resolution des litiges est
d&rite dans la Figure 2.
Lorsque l’arbitre r&out des litiges, il recueille des preuves aupres des parties en litige et/au des tiers de confiance. Le
procede utilise par un arbitre pour resoudre des litiges est hors du domaine d’application de la presente Recommandation
I Nor-me internationale.
Cette phase n’est pas toujours necessaire. Si toutes les parties interessees conviennent qu’un evenement ou une action
s’est produit (ou ne s’est pas produit), il n’y a aucun litige a resoudre. Par ailleurs, meme si un litige s’est produit, il peut
parfois etre resolu directement entre les parties sans devoir faire appel a un arbitre. Par exemple, si l’une des parties au
litige est honnete mais s’est trompee, elle peut se rendre compte de son erreur lorsqu’on lui montre la preuve de l’autre
par-tie.
Bien que cette phase ne soit pas toujours necessaire dans chaque instance du service de non-repudiation, tous les
mecanismes de non-repudiation doivent prendre en charge la phase de resolution des litiges. En d’autres termes, ils
doivent permettre la resolution des litiges lorsque ceux-ci se produisent.
Formes du service de non-rkpudiation
54 l
11 existe de nombreuses formes du service de non-repudiation, parmi lesquelles on releve frequemment celle du service
de non-repudiation associe au transfer-t de donnees.
‘eventuel s litiges
Le transfert d’un message implique au moins deux entites, a savoir l’expediteur et le destinataire. D
concernant 1 ‘evenement sont par exempl e les su ivants
-
litiges dans lesquels la participation de l’expediteur a l’evenement est contestee; par exemple, l’expediteur
suppose fait valoir que le message a ete fabrique de toutes pieces par le destinataire ou par un usurpateur
d’identite malveillant;
-
litiges dans lesquels la participation du destinataire a l’evenement est contestee; par exemple, le
destinataire suppose fait valoir soit que le message n’a pas ete envoy& soit qu’il a ete perdu en transit ou
qu’il n’a ete recu que par un usurpateur d’identite malveillant.
Pour la messagerie, les services de non-repudiation peuvent etre classes selon le type de litige qu’ils peuvent contribuer a
resoudre.
Rec. UIT-T X.813 (1996 F)
ISOKEI 10181-4 : 1997 (F)
Le transfert de messages d’un expediteur & un destinataire peut etre consid& comme 6tant une skquence d’Mnements
distincts:
-
la transmission du message de l’expkditeur A un agent de transfert;
-
la transmission du message d’un agent de transfert A un autre (si plusieurs agents de transfert sont
impliquks);
-
la transmission du message d’un agent de transfert au destinataire.
formes du service de non-rkpudiation qui apportent des preuves concernant
Pour chacun de ces Mnements, il existe des
non-rkpudiation ci-aprk sont done rkpertoriks:
ces Wnements. Les services additionnels de
-
le service de non-repudiation avec preuve de soumission est utilisk pour s’assurer contre un faux d&i, par
un agent de transfert, de l’acceptation d’un message 2 transmettre (en provenance de l’expkditeur ou d’un
autre agent de transfert);
-
le service de non-repudiation avec preuve de transport est utilis6 pour s’assurer contre un faux d&i, par un
agent de transfert, de la transmission d’un message (soit au destinataire soit a un autre agent de transfert).
NOTE - Les services de non-repudiation avec preuve de soumission et de non-repudiation avec preuve de transport
n’apportent pas de preuve qu’une entit6 est responsable du message ou a compris l’information contenue dans le message.
55 . Exemples de preuve OS1 de non-rbpudiation
Selon les services OS1 de non-repudiation invoquks, des formes particulikres de preuve sont requises pour chaque
type
dessous.
d’Mnement ou d’action, comme illustrk ci-
5.5.1 Non-rkpudiation d’origine
La preuve doit comprendre les Mments suivants (dont chacun peut &re sign6 ou notarie):
-
l’identificateur distinctif de l’expediteur;
-
les donkes envoykes, ou une empreinte numkique de ces donnkes.
La preuve peut kgalement comprendre les Gments suivants:
-
l’identificateur distinctif du destinataire;
-
la date et l’heure de l’envoi des donnkes.
5.5.2 Non-repudiation de remise
La preuve doit comprendre les 616ments suivants (dont chacun peut &re sign6 ou notarik):
-
l’identificateur distinctif du destinataire;
-
les donnees envoykes, ou une empreinte
numkrique de ces donnees.
La preuve peut egalement comprendre les Wments suivants:
-
l’identificateur distinctif de l’expediteur;
-
la date et l’heure de la rkception des donnkes.
Lorsqu’une autorite de remise est utiliske, la preuve peut kgalement comprendre les Wments suivants (dont chacun peut
&re sign6 ou notarik):
-
l’identificateur distinctif de l’autorite de remise;
-
la date et l’heure de la premikre tentative de remise par l’autorite de remise;
-
la date et l’heure d’obtention du signal ccprst & recevoir>> en provenance du destinataire;
-
la date et l’heure d’exkution de la remise par l’autoritk de remise;
-
la date et l’heure auxquelles l’autoritk de remise n’a pas 6t6 en mesure d’effectuer la remise;
-
la cause probable des conditions de non-remise (par exemple rupture de la voie de communication);
-
une indication des prescriptions de traitement qui ont &6 satisfaites lors de la remise du message.
Politiques de non-rbpudiation
Une politique de non-rkpudiation peut comprendre les r2gles suivantes:
-
rkgles pour la production de preuves, par exemple spkcifications des classes d’activite pour lesquelles une
preuve de non-repudiation doit 2tre produite; spkifications des tiers de confiance B utiliser pour produire
la preuve; les r8les que ces tiers de confiance peuvent jouer; les prockdures que les entites doivent suivre
lors de la production des preuves;
-
rkgles pour la vkrification des preuves, par exemple spkcifications des tiers de confiance dont les preuves
sont acceptables; formes de preuve qui seront acceptges de la part de chaque tiers de confiance;
Rec. UIT-T X.813 (1996 F)
ISO/CEP 10181-4 : 1997 (F)
-
l’integrite
regles pour la conser vation des preuves, par exemple les moyens a utiliser pour assurer des
preuve
s conser v6es;
-
regles pour l’utilisation des preuves, par exemple specification des fins auxquelles les preuves peuvent
etre utilisees;
NOTE - Avec certains mkanismes de non-rkpudiation, il est parfois difficile d’empkher un usage non autorise
des preuves.
-
regles pour l’arbitrage, par exemple la specification d’arbitre(s) agree(s) pouvant regler un litige.
Chacun de ces ensembles de regles peut etre defini par une autorite differente. Par exemple, les regles de production de
preuves peuvent etre definies par le proprietaire d’un systeme, alors que les regles d’arbitrage peuvent etre definies par la
loi du pays dans lequel le systeme existe.
Si differentes parties de la politique ne sont pas coherentes, le service de non-repudiation peut ne pas fonctionner
correctement, par exemple en autorisant, au tours de la phase de resolution des litiges, la reussite du deni d’un
evenement qui s’est reellement produit.
Les politiques de securite peuvent etre explicitement d&lakes, ou e.tre definies implicitement par les implementations.
Une declaration explicite de la politique de non-repudiation (par exemple un document en langage naturel) peut aider a
detecter des conflits entre differentes parties de la politique. Elle peut egalement aider l’arbitre.
Les politiques de non-repudiation traitent egalement des cas dans lesquels la preuve a fait l’objet d’une divulgation for&e
ou dans lesquels les cles utilisees pour produire la preuve ont fait l’objet d’une divulgation for&e ou d’une revocation.
Les politiques de non-repu diation pour j nteractions entre dornaines de securite peuvent etre le resultat d’accords conclus
entre domaines de securite independants ou peuvent etre i mposees p ar un super-domaine.
7 Informations et fonctionnalit6s
71 . Informations
Les informations qui peuvent etre utilisees pour resoudre un litige sont appelees preuves. Une preuve peut etre conservee
localement par un utilisateur de preuve ou etre conservee par un tiers de confiance. Formes particulieres de preuve:
signatures numeriques, enveloppes securisees et jetons de securite. Les signatures numeriques sont utilisees avec les
techniques de cle publique tandis que les enveloppes securisees et les jetons de securite sont utilises avec les techniques
de cle privee. Exemples d’informations pouvant constituer une preuve:
identificateur de la politique de securite de non-repudiation;
-
identificateur distinctif de l’expediteur;
-
identificateur distinctif du destinataire;
-
signature numerique ou enveloppe securisee;
-
identificateur distinctif du generateur de preuve;
-
identificateur distinctif du demandeur de production de preuve;
-
message ou empreinte numerique du message;
NOTE - Lorsque l’empreinte numkique est utilike g la place du message, un indicateur est requis pour
identifier la methode utilisee pour la description.
-
identificateur du message;
-
indication de la cle secrete necessaire pour valider le jeton de securite;
-
identification de la cle publique particuliere qui est necessaire pour valider la signature numerique (par
exemple l’identificateur de l’autorite de certification et le numero de serie du certificat);
-
identificateur distinctif du notaire, du tiers de confiance de pointage temporel, du tiers de confiance en
ligne, etc.;
-
identificateur unique pour la preuve;
-
date et heure du depot ou de l’enregistrement de la preuve;
date et heure de la production de la signature numerique ou du jeton de securite.
Rec. UIT-T X.813 (1996 F) 9
ISO/CEI 10181-4 : 1997 (F)
72 . Fonctionnalitbs de non-rkpudiation
Ce paragraphe identifie un certain nombre de fonctionnalites de non-repudiation qui peuvent etre utilisees pour produire,
envoyer et valider des preuves ou pour les deposer aupres d’un tiers de confiance.
7.2.1 Fonctionnalitks associkes B la gestion de non-rbpudiation
Les activites associees a la gestion de la non-repudiation peuvent impliquer la distribution d’informations, de mots de
passe ou de cles (au moyen de la gestion des cl&), a des entites appelees a effectuer une non-repudiation. Ces activites
peuvent impliquer l’utilisation d’un protocole entre entites communicantes et entre autres entites fournissant des services
de non-repudiation. La gestion de non-repudiation peut aussi impliquer la revocation des cl& utilisees pour produire les
preuves.
Les fonctionnalites de gestion de non-repudiation permettent a un utilisateur d’obtenir, de modifier et de supprimer des
informations qui sont necessaires pour la fourniture du service de non-repudiation. En termes generaux, ces
fonctionnalites sont les suivantes:
-
installation d’informations de gestion;
-
modification d’informations de gestion;
-
suppression d’informations de gestion;
-
enumeration d’i nformations de gestion.
Les actions suivantes, associees a la gestion de non-repudiation, peuvent etre requises a l’appui du service de
non-repudiation:
-
enregistrement de l’evenement dans le journal d’audit;
-
enregistrement des resultats de l’arbitrage en cas de litige;
-
signalisation locale de l’evenement;
-
signalisation distante de l’evenement.
L’action specifique qui doit faire suite a chaque evenement depend de la politique de securite mise en ceuvre.
7.2.2 Fonctionnalitbs associbes aux opbations
7.2.2.1 Production des preuves
Cette fonctionnalite est utilisee pour produire des preuves. Ces preuves peuvent etre generees directement par le sujet de
preuve (sans faire intervenir un tiers de confiance), par un ou plusieurs tiers de confiance agissant pour le compte du
sujet de preuve, ou par le sujet de preuve de concert avec un ou plusieurs tiers de confiance.
Les elements susceptibles d’etre introduits sont les suivants:
-
la politique de non-repudiation;
-
l’identificateur distinctif du sujet de preuve;
-
l’identificateur distinctif du demandeur du service de non-repudiation;
-
les don&e
...