Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)

Échange de données informatisé pour l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (Numéro de version de syntaxe: 4) — Partie 5: Règles de sécurité pour EDI par lots (authenticité, intégrité et non-répudiation de l'origine)

General Information

Status
Withdrawn
Publication Date
24-Mar-1999
Withdrawal Date
24-Mar-1999
Current Stage
9599 - Withdrawal of International Standard
Completion Date
01-Aug-2002
Ref Project

Relations

Buy Standard

Standard
ISO 9735-5:1999 - Electronic data interchange for administration, commerce and transport (EDIFACT) -- Application level syntax rules (Syntax version number: 4)
English language
50 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 9735-5:1999 - Échange de données informatisé pour l'administration, le commerce et le transport (EDIFACT) -- Regles de syntaxe au niveau de l'application (Numéro de version de syntaxe: 4)
French language
63 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 9735-5
First edition
1999-04-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Application level syntax rules
(Syntax version number: 4) —
Part 5:
Security rules for batch EDI (authenticity,
integrity and non-repudiation of origin)
Échange de données informatisées pour l’administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe au niveau de l’application
(Numéro de version de syntaxe: 4) —
Partie 5: Règles de sécurité pour EDI par lots (authenticité, intégrité et
non-répudiation de l’origine)
A
Reference number
ISO 9735-5:1999(E)

---------------------- Page: 1 ----------------------
ISO 9735-5:1999(E)
Page
Contents
1 Scope 1
2 Conformance 1
3 Normative references 1
4 Definitions 2
5 Rules for the use of security header and trailer segment groups
for batch EDI 2
6 Rules for the use of interchange and group security header and
trailer segment groups for batch EDI 9
Annex A: Definitions 12
Annex B: Syntax service directories (segments, composite data
elements and simple data elements) 13
Annex C: EDIFACT security threats and solutions 29
Annex D: How to protect an EDIFACT structure 32
Annex E: Message protection examples 34
Annex F: Filter functions for UN/EDIFACT character set repertoires
A and C 41
Annex G: Service code directory 43
Annex H: Security services and algorithms 44
Annex I: Bibliography 50
©  ISO 1999
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.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
©
ISO ISO 9735-5:1999(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national standards bodies (ISO member bodies). The work of
preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented
on that committee. International organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. ISO collabo-
rates closely with the International Electrotechnical Commission (IEC) on
all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
This part of ISO 9735 was prepared by the UN/ECE Trade Division (as
UN/EDIFACT) and was adopted, under a special "fast-track procedure", by
Technical Committee ISO/TC 154, Documents and data elements in
administration, commerce and industry.
Whereas this part supersedes the earlier publications, and shall use a
version number of “4” in the mandatory data element 0002 (Syntax version
number) in the segment UNB (Interchange header), interchanges
continuing to use the syntax defined in the earlier published versions shall
use the following Syntax version numbers, in order to differentiate them
from each other and from this part:
ISO 9735:1988 — Syntax version number: 1
ISO 9735:1988 (amended and reprinted in 1990) — Syntax version
number: 2
ISO 9735:1988 (amended and reprinted in 1990) plus
Amendment 1:1992 — Syntax version number: 3
ISO 9735 consists of the following parts, under the general title Electronic
data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4) :
— Part 1: Syntax rules common to all parts, together with the syntax
service directories for each of the parts
— Part 2: Syntax rules specific to batch EDI
— Part 3: Syntax rules specific to interactive EDI
— Part 4: Syntax and service report message for batch EDI (message
type - CONTRL)
— Part 5: Security rules for batch EDI (authenticity, integrity and non-
repudiation of origin)
iii

---------------------- Page: 3 ----------------------
©
ISO 9735-5:1999(E) ISO
— Part 6: Secure authentication and acknowledgement message
(message type - AUTACK)
— Part 7: Security rules for batch EDI (confidentiality)
— Part 8: Associated data in EDI
— Part 9: Security key and certificate management message (message
type - KEYMAN)
Further parts may be added in the future.
Annexes A and B form an integral part of this part of 9735. Annexes C to I
are for information only.
iv

---------------------- Page: 4 ----------------------
©
ISO ISO 9735-5:1999(E)
Introduction
This part of ISO 9735 includes the rules at the application level for the
structuring of data in the interchange of electronic messages in an open
environment, based on the requirements of either batch or interactive
processing. These rules have been agreed by the United Nations
Economic Commission for Europe (UN/ECE) as syntax rules for Electronic
Data Interchange for Administration, Commerce and Transport (EDIFACT)
and are part of the United Nations Trade Data Interchange Directory
(UNTDID) which also includes both batch and interactive Message Design
Guidelines.
Communications specifications and protocols are outside the scope of this
part of ISO 9735.
This is a new part, which has been added to ISO 9735. It provides an
optional capability of securing batch EDIFACT structures i.e. messages,
packages, groups or interchange.
v

---------------------- Page: 5 ----------------------
©
INTERNATIONAL STANDARD  ISO ISO 9735-5:1999(E)
Electronic data interchange for administration, commerce and
transport (EDIFACT) — Application level syntax rules — (Syntax
version number: 4)
Part 5:
Security rules for batch EDI (authenticity, integrity and non-repudiation
of origin)
1 Scope
This part of ISO 9735 specifies syntax rules for EDIFACT security. It provides a method to address
message/package level, group level and interchange level security for authenticity, integrity and non-repudiation of
origin, in accordance with established security mechanisms.
2 Conformance
Conformance to a standard means that all of its requirements, including all options, are supported. If all options are
not supported, any claim of conformance shall include a statement which identifies those options to which
conformance is claimed.
Data that is interchanged is in conformance if the structure and representation of the data conform to the syntax
rules specified in this part of ISO 9735.
Devices supporting this part of ISO 9735 are in conformance when they are capable of creating and/or interpreting
the data structured and represented in conformance with this part of ISO 9735.
Conformance to part of ISO 9735 shall include conformance to Part 1, Part 2 and Part 8 of ISO 9735.
When identified in this part of ISO 9735, provisions defined in related standards shall form part of the conformance
criteria.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of
ISO 9735. At the time of publication, the editions indicated were valid. All standards are subject to revision, and
parties to agreements based on this part of ISO 9735 are encouraged to investigate the possibility of applying the
most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently
valid International Standards.
Information processing systems — Open Systems Interconnection — Basic Reference Model —
ISO 7498-2:1989,
Part 2: Security architecture.
ISO/IEC 9594-8:1995, Information technology — Open Systems Interconnection — The Directory: Authentication
framework.
1

---------------------- Page: 6 ----------------------
©
ISO
ISO 9735-5:1999(E)
ISO 9735-1:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 1: Syntax rules common to all parts, together with syntax
directories for each of the parts.
ISO 9735-2:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 2: Syntax rules specific to batch EDI.
Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
ISO 9735-6:1998,
level syntax rules (Syntax version number: 4) — Part 6: Secure authentication and acknowledgement message
(message type — AUTACK).
1)
ISO 9735-7:— , Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 7: Security rules for batch EDI (confidentiality).
Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
ISO 9735-8:1998,
level syntax rules (Syntax version number: 4) — Part 8: Associated data in EDI.
Information technology — Open Systems Interconnection — Security frameworks for open
ISO/IEC 10181-2:1996,
systems: Authentication framework.
ISO/IEC 10181-4:1997, Information technology — Open Systems Interconnection — Security frameworks for open
systems: Non-repudiation framework.
Information technology — Open Systems Interconnection — Security frameworks for open
ISO/IEC 10181-6:1996,
systems: Integrity framework.
4 Definitions
For the purposes of this part of ISO 9735, the definitions in ISO 9735-1:1998, annex A apply.
5 Rules for the use of security header and trailer segment groups for batch EDI
5.1 Message/package level security - integrated message/package security
The security threats relevant to message/package transmission and the security services which address them are
described in annexes C and D.
This section describes the structure of EDIFACT message/package level security.
Security services addressed in this part of ISO 9735 shall be provided by the inclusion of security header and trailer
segment groups after the UNH and before the UNT, in a way which shall be applied to any existing message, or
after the UNO and before the UNP, for any existing package.
________________
1)  To be published.
2

---------------------- Page: 7 ----------------------
©
ISO
ISO 9735-5:1999(E)
5.1.1 Security header and trailer segment groups
Figure 1 describes an interchange showing security at message level.
INTERCHANGE
Either :  Only Or :  Only
UN A UN B UNZ
      GR OU P(S)    M ESS AG E(S)/
    PA CK AG E(S)
M essage M essage
UNG MESSAGE UNE
Security Security
header tra iler
UN H M ESS AG E BO DY UN T
seg m ent seg m ent
group (s) group (s)
Figure 1 - Interchange showing security at message level (schematic)
Figure 2 describes an interchange showing security at package level.
INTERCHANGE
Either :  Only Or :  Only
UNA UNB UNZ
      G R O U P(S)    M ESS A G E(S)/
    PACKA G E(S)
PACKAGE Package
UNG Package UNE
Security Security
header trailer
UNO OBJECT UNP
segm ent segm ent
group(s) group(s)
Figure 2 - Interchange showing security at package level (schematic)
3

---------------------- Page: 8 ----------------------
©
ISO
ISO 9735-5:1999(E)
5.1.2 Security header and trailer segment groups structure
TAG Name S R
UNH Message Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+  I
USC Certificate M 1  I  I
USA Security Algorithm C 3  I  I
USR Security Result C 1 --------+
Message body
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1  I
USR Security Result C 1 ----+
UNT Message Trailer M 1
Table 1 - Security header and security trailer segment groups segment table (message level security)
TAG Name S R
UNO Object Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+  I
USC Certificate M 1  I  I
USA Security Algorithm C 3  I  I
USR Security Result C 1 --------+
Object
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1  I
USR Security Result C 1 ----+
UNP Object Trailer M 1
Table 2 - Security header and security trailer segment groups segment table (package level security)
Note: UNH message header, UNT message trailer, UNO object header and UNP object trailer are specified in
Part 1 of ISO 9735. They are not described further in this Part.
The complete directory specification of the segments and data elements may be found in annex B.
5.1.3 Data segment clarification
Segment Group 1: USH-USA-SG2 (security header group)
A group of segments identifying the security service and security mechanisms applied and containing the data
necessary to carry out the validation calculations.
There may be several different security header segment groups within the same message/package, if different
security services are applied to the message/package (e. g. integrity and non-repudiation of origin) or if the same
security service is applied by several parties.
USH, Security header
A segment specifying a security service applied to the message/package in which the segment is included.
The parties involved in the security service (security elements originator and security elements recipient), may be
identified in this segment, unless they are unambiguously identified by means of certificates (USC segment) when
asymmetric algorithms are used.
4

---------------------- Page: 9 ----------------------
©
ISO
ISO 9735-5:1999(E)
Security identification details composite data element (S500) shall be used in USH segment either:
- if symmetric algorithms are used, or
- if asymmetric algorithms are used and when two certificates are present, in order to distinguish between the
originator and the recipient certificates
In this latter case, the identification of the party in S500 (any of the data elements S500/0511, S500/0513,
S500/0515, S500/0586) shall be the same as the identification of the party, qualified as "certificate owner" in one
of the S500 present in the USC segment in segment group 2, and data element S500/0577 shall identify the
function (originator or recipient) of the party involved.
Data element key name in security identification details composite data element (S500/0538) may be used to
establish the key relationship between the sending and receiving parties.
This key relationship may also be established by using the data element identification of the key of the algorithm
parameter composite data element (S503/0554) in the USA segment of segment group 1.
S500/0538 in USH segment may be used if there is no need to convey a USA segment in segment group 1
(because the cryptographic mechanisms have been agreed previously between the partners).
Nevertheless, it is strongly recommended to use either S500/0538 in the USH segment, or S503/0554 with the
appropriate qualifier in the USA segment, but not both of them, within the same security header group.
USH segment may specify the filter function used for the binary fields of USA segment within segment group 1
and of the USR segment of the corresponding security trailer group.
USH segment may include a security sequence number, to provide sequence integrity, and the date of creation of
the security elements.
USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required. This shall be the algorithm applied directly on the message/package. This algorithm may be
either symmetric, a hash function or a compression algorithm. For example, for a digital signature, it indicates the
message-dependent hash function to be used.
Asymmetric algorithms shall not be referred to directly in this USA segment within segment group 1 but may
appear only within segment group 2, triggered by a USC segment.
Three occurrences of the USA segment are allowed. One occurrence shall be used for the symmetric algorithm or
the hash function required to provide the security service specified in the USH segment. The other two
occurrences are described in Part 7 of ISO 9735.
Indication of padding mechanism may be used when appropriate.
Segment Group 2: USC-USA-USR (certificate group)
A group of segments containing the data necessary to validate the security methods applied to the
message/package, when asymmetric algorithms are used. Certificate segment group shall be used when
asymmetric algorithms are used to identify the asymmetric key pair used, even if certificates are not used.
Either the full certificate segment group (including the USR segment), or the only data elements necessary to
identify unambiguously the asymmetric key pair used, shall be present in the USC segment. The presence of a full
certificate may be avoided if the certificate has already been exchanged by the two parties, or if it may be retrieved
from a database.
Where it is decided to refer to a non-EDIFACT certificate (such as X.509), the certificate syntax and version shall be
identified in data element 0545 of the USC segment. Such certificates may be conveyed in an EDIFACT package.
Two occurrences of this segment group are allowed, one being the message/package sender certificate (that the
message/package receiver will use to verify the sender's signature), the other being the message/package receiver
certificate (only referred to by certificate reference) in the case where the receiver public key is used by the sender
for confidentiality of symmetric keys.
If both are present within one security header segment group, the security identification details composite data
element (S500) together with the certificate reference data element (0536) allow them to be differentiated.
This segment group shall be omitted if no asymmetric algorithm is used.
5

---------------------- Page: 10 ----------------------
©
ISO
ISO 9735-5:1999(E)
USC, Certificate
A segment containing the credentials of the certificate owner and identifying the certification authority which has
generated the certificate. The data element filter function, coded (0505) shall identify the filter function used for the
binary fields of USA segments and USR segment within segment group 2.
USC certificate may contain two occurrences of S500: one for the certificate owner (identifying the party which
signs with the private key associated to the public key contained in this certificate), one for the certificate issuer
(certification authority or CA).
USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required. The three different occurrences of this USA segment in segment group 2 are identifying:
1 the algorithm used by the certificate issuer to compute the hash value of the certificate (hashing function)
2 the algorithm used by the certificate issuer to generate the certificate (i.e. to sign the result of the hash
function computed on the certificate content) (asymmetric algorithm)
3a - either the algorithm used by the sender to sign the message/package (i.e. to sign the result of the hash
function described in the USH segment, computed on the message/package content) (asymmetric
algorithm),
3b - or the receiver's asymmetric algorithm used by the sender to encrypt the key required by a symmetric
algorithm applied to the message/package content and referred to by the segment group 1 triggered by the
USH segment (asymmetric algorithm)
Indication of padding mechanism may be used when appropriate.
USR, Security result
A segment containing the result of the security functions applied to the certificate by the certification authority. This
result shall be the signature of the certificate computed by the certification authority by signing the hash result
computed on the data of the credentials.
For the certificate, the signature computation starts with the first character of the USC segment (namely the "U")
and ends with the last character of the last USA segment (including the separator following this USA segment).
Segment Group n: UST-USR (security trailer group)
A group of segments containing a link with security header segment group and the result of the security functions
applied to the message/package.
UST, Security trailer
A segment establishing a link between security header and security trailer segment groups, and stating the
number of security segments containedin these groups.
USR, Security result
A segment containing the result of the security functions applied to the message/package as specified in the
linked security header group. Depending on the security mechanisms specified in the linked security header
group, this result shall be either:
- computed directly on the message/package by the algorithm specified in the USA segment within segment
group 1 of the security header group, or
- computed by signing with an asymmetric algorithm specified in USA segment within segment group 2 of the
security header segment group a hash result computed on the message/package by the algorithm specified in
the USA segment within segment group 1 of the security header segment group
5.1.4 Scope of security application
There are two possibilities for the scope of security application:
1. The computation of each of the integrity and authentication values and of the digital signatures starts with and
includes the current security header segment group and the message body, or object, itself. In this case no
other security header or security trailer segment groups shall be encompassed within this scope.
The security header segment group shall be counted from the first character, namely a "U", to the separator
ending this security header segment group, both included, and the message body, or object, from the first
character following the separator ending the last security header segment group to the separator preceding
the first character of the first security trailer segment group, both included.
6

---------------------- Page: 11 ----------------------
©
ISO
ISO 9735-5:1999(E)
Thus the order in which security services integrated in this manner are performed, is not prescribed. They are
completely independent of each other.
Figure 3 illustrates this case (the scope of application of the security service defined in the security header 2
is represented by shaded boxes):
Security Security Security Security Security Security
UNH/ header header header MESSAGE BODY/ trailer trailer trailer UNT/
UNO segment segment segment OBJECT segment segment segment UNP
group 3 group 2 group 1 group 1 group 2 group 3
Figure 3 - Scope of application: security header segment group and message body/object only (schematic)
2. The computation starts with and includes the current security header segment group to the associated
security trailer segment group. In this case the current security header segment group, the message body, or
object, and all the other embedded security header and trailer segment groups shall be encompassed within
this scope.
The scope shall include every character from the first character, namely a "U", of the current security header
segment group, to the separator preceding the first character of the associated security trailer segment
group, both included.
Figure 4 illustrates this case (the scope of application of the security service defined in the security header 2
is represented by shaded boxes):
Security Security Security Security Security Security
UNH/ header header header MESSAGE BODY/ trailer trailer trailer UNT/
UNO segment segment segment OBJECT segment segment segment UNP
group 3 group 2 group 1 group 1 group 2 group 3
Figure 4 - Scope of application: from security header segment group to security trailer segment group
(schematic)
For each added security service, either of the two approaches may be chosen.
In both cases, the relation between the security header segment group and associated security trailer segment
group shall be provided by the data elements security reference number of the USH and of the UST segments.
5.2 Principles of usage
5.2.1 Choice of service
The security header segment group may include the following general information:
- Security service applied
- Identification of the parties involved
- Security mechanism used
- "Unique" value (sequence number and/or timestamp)
- Non-repudiation of receipt request
If more than one security service is required for the same EDIFACT structure, then the security header segment
group may be present several times. This shall be the case when several pairs of parties are involved. However, if
several services are required between the same two parties they may be included in a single pair of security header
and trailer segment groups, as certain services include others implicitly.
5.2.2 Authenticity
If origin authentication of a EDIFACT structure is required, it shall be provided in accordance to the principles
defined in ISO 10181-2, using an appropriate pair of security header and security trailer segment groups.
The security service of origin authentication shall be specified in the USH segment and the algorithm shall be
identified in the USA segment in segment group 1. It shall be a symmetric algorithm.
7

---------------------- Page: 12 ----------------------
©
ISO
ISO 9735-5:1999(E)
The party acting as security originator shall compute an authenticity value that shall be conveyed in the USR
segment of the security trailer segment group. The party acting as security recipient shall check the authenticity
value.
This service may include integrity service and may be obtained as a sub-product of non-repudiation of origin
service.
If an appropriate implementation of this "origin authentication" service, based on tamper resistant hardware or
trusted third parties, is used, it may be considered as an instance of "non repudiation of origin" service. Such a
practice shall be defined in the interchange agreement.
5.2.3 Integrity
If content integrity of a EDIFACT structure is required, it shall be provided in accordance to the principles defined in
ISO 10181-6, using an appropriate pair of security header and security trailer segment groups.
The security service of integrity shall be specified in the USH segment and the algorithm shall be identified in the
USA segment in segment group 1. It shall be hash function or a symmetric algorithm.
The party acting as security originator shall compute an integrity value that shall be conveyed in the USR segment
of the security trailer segment group. The party acting as security recipient shall check the integrity value.
This service may be obtained as a sub-product of origin authentication service or of non-repudiation of origin
service.
If sequence integrity is required, either a security sequence number or a security timestamp, or both, shall be
contained by the security header segment group and either content integrity service or origin authentication service
or non-repudiation of origin service shall be used.
5.2.4 Non-repudiation of origin
If non-repudiation of origin of a EDIFACT structure is required, it shall be provided in accordance to the principles
defined in ISO 10181-4, using an appropriate pair of security header and security trailer segment groups.
The security service of non-repudiation of origin shall be specified in the USH segment and the hashing algorithm
shall be identified in the USA segment in segment group 1, and the asymmetric algorithm used for signature in the
USA segments of segment group 2, if certificates are used.
If the certificate is not conveyed in the message/package, the asymmetric algorithm shall be implicitly known by the
receiving party. In this case the asymmetric algorithm shall be defined in the interchange agreement.
The party acting as security originator shall compute a digital signature that shall be conveyed in the USR segment
of the security trailer segment group. The party acting as security recipient shall verify the digital signature value.
This service provides also content integrity and origin authentication services.
5.3 Internal representation and filters for compliance with EDIFACT syntax
The use of mathematical algorithms to compute integrity values and digital signatures introduces two problems.
The first problem is that the result of the calculation depends on the internal representation of the character set.
Thus the computation of the digital signature by the sender and its verification by the recipient shall be executed
using the same character set encoding. Therefore the sender may indicate the representation used to produce the
original security validation result.
The second problem is that the result of the calculation is a seemingly random bit pattern. This may cause problems
during transmission and with interpretation software. To avoid these problems the bit pattern may be reversibly
mapped on to a particular representation of the character set used by means of a filtering function. For simplicity,
only one filtering function shall be used for each security service. Any appearance of an anomalous terminator in the
output of this mapping is dealt with by including an escape sequence.
8

---------------------- Page: 13 ----------------------
©
ISO
ISO 9735-5:1999(E)
6 Rules for the use of interchange and group security header and trailer segment
groups for batch EDI
6.1 Group and interchange level security - integrated message security
The security threats relevant to message/package transmission and the security services which address them, as
described in annexes C and D, are also valid at group and interchange level.
The techniques described in the previous section for applying security to messages/packages may also be applied
to interchanges and groups.
For group and interchange level security, the same header and trailer segmen
...

NORME ISO
INTERNATIONALE 9735-5
Première édition
1999-04-01
Échange de données informatisé pour
l'administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe
au niveau de l'application (numéro de
version de syntaxe: 4) —
Partie 5:
Règles de sécurité pour l'EDI par lots
(authentification, intégrité et
non-répudiation de l'origine)
Electronic data interchange for administration, commerce and transport
(EDIFACT) — Application level syntax rules (Syntax version number: 4) —
Part 5: Security rules for batch EDI (authenticity, integrity and
non-repudiation of origin)
Numéro de référence
ISO 9735-5:1999(F)
©
ISO 1999

---------------------- Page: 1 ----------------------
ISO 9735-5:1999(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifiéà moins que l'ordinateur employéà cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la créationduprésent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO 1999
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-aprèsouducomité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2000
Imprimé en Suisse
ii © ISO 1999 – Tous droits réservés

---------------------- Page: 2 ----------------------
ISO 9735-5:1999(F)
Sommaire Page
1 Domaine d'application.1
2 Conformité.1
3Références normatives .1
4Définitions .2
5Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité pour l’EDI par lots.2
6Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité au niveau de
l’échange et des groupes pour l’EDI par lots .10
Annexe A Addendum -—à ajouter à l’annexe A de la Partie 1 lorsqu’elle sera approuvée —
Définitions .14
Annexe B Addendum—à ajouter à l’annexeCdelaPartie1 lorsqu’elle sera approuvée —
Répertoires syntaxiques de service (segments, éléments de données composites et éléments
de données simples) .16
Annexe C Menaces à l’encontre de la sécurité EDIFACT et solutions pour s’en prémunir.34
Annexe D Façon de protéger une structure EDIFACT.38
Annexe E Exemples de protection d’un message.41
Annexe F Fonctions du filtre pour les répertoires des jeux de caractères A et C EDIFACT/ONU .51
Annexe G Addendum —à ajouter à l’annexe D le la Partie 1 une fois approuvée — Répertoire des
codes de service.54
Annexe H Services et algorithmes de sécurité.55
Annexe I Bibliographie.63
© ISO 1999 – Tous droits réservés iii

---------------------- Page: 3 ----------------------
ISO 9735-5:1999(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiéeaux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude aledroit de faire partie ducomité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 9735-5 a étéélaborée par la Division du commerce de la Commission Économique
pour l’Europe des Nations Unies (en tant qu’EDIFACT/ONU) et a été adoptée, selon une procédure spéciale par
«voie express»,par le comité technique ISO/TC 154, Documents et éléments de données dans l'administration, le
commerce et l'industrie.
Alors que la présente partie remplace les publications antérieures et qu’un numéro de version «4» doit être attribué
à l’élément de données obligatoire 0002 (numéro de version de la syntaxe) du segment UNB (en-tête de
l’échange), les échanges continuant à utiliser la syntaxe définie dans les versions publiées antérieurement doivent
reprendre les numéros suivants de version de syntaxe afin de se différencier tant les uns des autres que de la
présente partie:
ISO 9735:1988 — Numéro de version de syntaxe: 1
ISO 9735:1988 (modifiéeetréimprimée en 1990) — Numéro de version de syntaxe: 2
ISO 9735:1988 (modifiéeetréimprimée en 1990) plus Amendement 1:1992 — Numéro de version de
syntaxe: 3
L'ISO 9735 comprend les parties suivantes, présentées sous le titre général Échange de données informatisé pour
l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (numéro
de version de syntaxe: 4):
� Partie 1: Règles de syntaxe communes à l’ensemble des parties, accompagnées des répertoires de service
syntaxiques associés à chacune d'elles
� Partie 2: Règles de syntaxe spécifiques à l'EDI par lots
� Partie 3: Règles de syntaxe spécifiques à l'EDI interactif
� Partie 4: Message Compte rendu syntaxique et de service pour l'EDI par lots (type de message CONTRL)
� Partie 5: Règles de sécurité pour l'EDI par lots (authentification, intégrité et non-répudiation de l'origine)
� Partie 6: Message sécurisé Authentification et accusé de réception (type de message AUTACK)
� Partie 7: Règles de sécurité pour le lot EDI (confidentialité)
� Partie 8: Données associées en EDI
� Partie 9: Message Gestion de clés et de certificats de sécurité(typedemessage KEYMAN)
� Partie 10: Règles de sécurité pour l'EDI interactif
iv © ISO 1999 – Tous droits réservés

---------------------- Page: 4 ----------------------
ISO 9735-5:1999(F)
D'autres parties pourront être ajoutées ultérieurement.
Les annexes A et B constituent des éléments normatifs de la présente partie de l’ISO 9735. Les annexes C à Ine
sont données qu’à titre d’information.
© ISO 1999 – Tous droits réservés v

---------------------- Page: 5 ----------------------
ISO 9735-5:1999(F)
Introduction
La présente partie de l’ISO 9735 comprend les règles qui se situent au niveau de l'application pour la structuration
des données associées à l'échange de messages électroniques dans un environnement ouvert, fondées sur les
prescriptions du traitement ou par lots, ou interactif. Ces règles ont été adoptées par la Commission Économique
pour l'Europe des Nations Unies (CEE/ONU) comme règles de syntaxe pour l'échange de données informatisé
pour l'administration, le commerce et le transport (EDIFACT). Elles font partie du Répertoire d'Échange de
données commerciales des Nations Unies (UNTDID) qui comporte également les Directives pour la conception de
messages, tant par transmission par lots qu'en mode interactif.
Les spécifications des communications et les protocoles n'entrent pas dans le cadre de la présentepartiede
l’ISO 9735.
La présente partie est nouvelle. Elle a été ajoutée à l'ISO 9735. Elle offre la possibilité de sécuriser des structures
EDIFACT par lots, c’est à dire des messages, des paquets, des groupes ou un échange.
vi © ISO 1999 – Tous droits réservés

---------------------- Page: 6 ----------------------
NORME INTERNATIONALE ISO 9735-5:1999(F)
Échange de données informatisé pour l'administration, le
commerce et l'industrie (EDIFACT) — Règles de syntaxe au niveau
de l'application (numéro de version de syntaxe: 4) —
Partie 5:
Règles de sécurité pour l'EDI par lots (authentification, intégrité et
non-répudiation de l'origine)
1 Domaine d'application
La présente partie de l'ISO 9735 définit les règles de syntaxe régissant la sécurité EDIFACT. Elle décrit une
méthode traitant de la sécurité au niveau d’un message/paquet, d’un groupe et d’un échange permettant d’assurer
l’authenticité,l’intégrité et la non-répudiation de l’origine, conformément aux mécanismes reconnus de sécurité.
2 Conformité
La conformitéà une norme signifie que la totalité de ses prescriptions, y compris tous ses aspects, sont pris en
compte. Si tel n’est pas le cas, toute demande de conformité doit comporter une déclaration identifiant chacun des
aspects qui en fait l'objet.
Les données échangées sont en conformité si la structure et la représentation des données respectent les règles
de syntaxe définies dans la présente partie de l'ISO 9735.
Les dispositifs qui s'appuient sur la présente partie de l'ISO 9735 sont en conformité s'ils sont en mesure de créer
et/ou d'interpréter les données structurées et représentées conformément à la présente partie de l’ISO 9735.
La conformitéà la présentepartiel’ISO 9735 doit prendre en compte la conformité aux Parties 1, 2 et 8 de
l’ISO 9735.
Une fois identifiées dans la présente partie de l’ISO 9735, les dispositions définies dans les normes associées
doivent faire partie intégrante des critères de conformité.
3Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence qui y est faite,
constituent des dispositions valables pour la présente partie de l'ISO 9735. Pour les références datées, les
amendements ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes
aux accords fondés sur la présente partie de l'ISO 9735 sont invitées à rechercher la possibilité d'appliquer les
éditions les plus récentes des documents normatifs indiqués ci-après. Pour les références non datées, la dernière
édition du document normatif en référence s’applique. Les membres de l'ISO et de la CEI possèdent le registre des
Normes internationales en vigueur.
ISO 7498-2:1989, Systèmes de traitement de l’information — Interconnexion de systèmes ouverts — Modèle de
référence de base — Partie 2: Architecture de sécurité.
© ISO 1999 – Tous droits réservés 1

---------------------- Page: 7 ----------------------
ISO 9735-5:1999(F)
ISO/CEI 9594-8:1995, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — L’Annuaire:
Cadre d’authentification.
ISO 9735-1:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 1: Règles
de syntaxe communes à l'ensemble des parties, accompagnées des répertoires de service syntaxiques associés à
chacune d'elles.
ISO 9735-2:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 2: Règles
de syntaxe spécifiques à l'EDI par lots.
ISO 9735-6:1999, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 6:
Message sécurisé Authentification et accusé de réception (type de message AUTACK).
1)
ISO 9735-7:— , Échange de données informatisé pour l’administration, le commerce et le transport (EDIFACT) —
Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 7: Règles de sécurité
pour le lot EDI (confidentialité).
ISO 9735-8:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 8:
Données associées en EDI.
ISO/CEI 10181-2:1996, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre d’authentification.
ISO/CEI 10181-4:1997, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre de non-répudiation.
ISO/CEI 10181-6:1996, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre d’intégrité.
4Définitions
Pour les besoins de la présente partie de l’ISO 9735, les définitions données dans l'annexe A de l’ISO 9738-1:1998
s’appliquent.
5Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité pour
l’EDI par lots
5.1 Sécurité au niveau d’un message/paquet - sécurité intégrée à un message/paquet
Les risques pouvant menacer la sécurité de la transmission d’un message/paquet et les services de sécurité qui en
traitent sont décrits dans les annexes C et D.
Cette section décrit la structure de la sécurité au niveau d’un message/paquet EDIFACT.
Les services de sécurité traités dans la présente partie de l’ISO 9735 doivent être assuréspar l’inclusion de
groupes de segments d’en-tête et de findesécurité après le segment UNH et avant le segment UNT de façon à
s’appliquer à tout message existant, ou après le segment UNO et avant le segment UNP, pour tout paquet
existant.
1) À publier.
2 © ISO 1999 – Tous droits réservés

---------------------- Page: 8 ----------------------
ISO 9735-5:1999(F)
5.1.1 Groupes de segments d’en-tête et de fin de sécurité
La Figure 1 décrit un échange illustrant l’application de la sécurité au niveau d’un message.
ECHANGE
Soit : Seulement
Soit : Seulement
UNA UNB
UNZ
GROUPE(S) PAQUET(S)
Message UNE
UNG MESSAGE Message
Groupe(s) Groupe(s)
de segments
de segments
UNH CORPS DU MESSAGE UNT
de fin de
d'en-tête de
sécurité
sécurité
Figure 1—Échange illustrant l’application de la sécurité au niveau d’un message (schéma simplifié)
La Figure 2 décrit un échange illustrant l’application de la sécurité au niveau d’un paquet.
ECHANGE
Soit : Seulement
Soit : Seulement
UNA UNB
UNZ
GROUPE(S) PAQUET(S)
UNG Paquet PAQUET Paquet UNE
Groupe(s)
Groupe(s)
de segments
de segments
UNO OBJET UNP
de fin de
d'en-tête de
sécurité
sécurité
Figure 2—Échange illustrant l’application de la sécurité au niveau d’un paquet (schéma simplifié)
© ISO 1999 – Tous droits réservés 3

---------------------- Page: 9 ----------------------
ISO 9735-5:1999(F)
5.1.2 Structure de groupes de segments d’en-tête et de fin de sécurité
Tableau 1 — Table des segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau du message)
Etiquette Nom S R
UNH En-tête de message M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M 1 I
USA Algorithme de sécurité C 3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C 3 I I
USR Résultat de sécurité C 1 --------+
Corps du message
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M 1 I
USR Résultat de la sécurité C 1 ----+
UNT Fin de message M 1
Tableau 2 — Table des segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau du paquet)
Etiquette Nom S R
UNO En-tête d’objet M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M 1 I
USA Algorithme de sécurité C 3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C 3 I I
USR Résultat de la sécurité C 1 --------+
Objet
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M 1 I
USR Résultat de la sécurité C 1 ----+
UNP Fin d’objet M 1
NOTE L’en-tête UNH du message, la fin UNT du message, l’en-tête UNO d’objet et la fin UNP d’objet sont décrits dans la
Partie 1 de l’ISO 9735. Ils ne sont pas décritsplusloindanslaprésente partie.
Toutes les spécifications des segments et des éléments de données peuvent être consultées dans l’annexe B qui
contient les répertoires correspondants.
5.1.3 Précisions sur les segments de données
Groupe de segments 1: USH-USA-SG2 (groupe d’en-tête de sécurité)
Groupe de segments identifiant le service et les mécanismes de sécurité qui s’appliquent et contenant les données
nécessaires à l’exécution des calculs de validation.
Il peut y avoir plusieurs groupes de segments d’en-tête de sécurité dans le même message/paquet, si différents
services de sécurité s’appliquent au message/paquet (par exemple, intégrité et non-répudiation de l’origine) ou si le
mêmeservicedesécurité s’applique à plusieurs intervenants.
4 © ISO 1999 – Tous droits réservés

---------------------- Page: 10 ----------------------
ISO 9735-5:1999(F)
USH, En-tête de sécurité
Segment définissant un service de sécurité s’appliquant au message/paquet dans lequel ce segment est intégré.
Les intervenants impliquésdans le servicedesécurité (initiateur des éléments de sécurité et destinataire des
éléments de sécurité) peuvent être identifiés dans ce segment, à moins qu’ils soient identifiés sans ambiguïté par
des certificats (segment USC) lorsque des algorithmes asymétriques sont utilisés.
L’élément de données composite (S500) «Précisions concernant les informations détaillées sur l’identification» doit
être utilisé dans le segment USH, dans les cas suivants :
� si des algorithmes symétriques sont utilisés, ou
� si des algorithmes asymétriques sont utilisés et que deux certificats sont présents, afin d’opérer la distinction
entre les certificats de l’initiateur et du destinataire.
Dans ce dernier cas, «l’identification de l’intervenant» contenue dans l’élément de données composite S500 (l’un
ou l’autre des éléments de données S500/0511, S500/0513, S500/0515, S500/0586) doit êtrelamême que
l’identification de l’intervenant, qualifié de «propriétairedecertificat», contenue dans l’une des données de S500
présente dans le segment USC du groupe de segments 2 et l’élément de données S500/0577 doit identifier la
fonction (initiateur ou destinataire) de l’intervenant impliqué.
L’élément de données «Nom de la clé» contenu dans l’élément de données composite, «Informations détaillées
sur l’identification de l’intervenant» (S500/0538), peut servir àétablir la relation des clés entre l’émetteur et le
récepteur.
Cette relation peut également être établie en utilisant l’élément de données «Identification de la clé» contenu dans
l’élément de données composite «Paramètredel’algorithme» (S503/0554) contenu dans le segment USA du
groupe de segments 1.
L’élément de données composite S500/0538 contenu dans le segment USH peut être utilisé s’il n’est pas
nécessaire de véhiculer un segment USA dans le groupe de segments 1 (les mécanismes cryptographiques ayant
été convenus au préalable entre les partenaires).
Néanmoins, il est vivement recommandé d’utiliser soit S500/0538 du segment USH, ou S503/0554 avec le
qualifiant approprié du segment USA, mais non les deux, au sein du même groupe d’en-tête de sécurité.
Le segment USH peut indiquer la fonction du filtre utilisé pour les champs binaires du segment USA au sein du
groupe de segments 1 et du segment USR du groupe correspondant de fin de sécurité.
Le segment USH peut comprendre un numéro de séquence de sécurité pour indiquer l’intégrité d’une séquence et
la date de création des éléments de sécurité.
USA, Algorithme de sécurité
Segment identifiant un algorithme de sécurité,l’utilisation technique qui en est faite et contenant les paramètres
techniques requis. Il s’agiradel’algorithme s’appliquant directement au message/paquet. Cet algorithme peut être
soit symétrique, soit une fonction de hachage, soit un algorithme de compression. Il indique la fonction à utiliser par
exemple, pour une signature numérique. Il ne doit pas être fait référence aux algorithmes asymétriques
directement dans ce segment USA contenu dans le groupe de segments 1 car ces algorithmes ne peuvent
apparaître que dans le groupe de segments 2, déclenché par un segment USC.
Trois occurrences du segment USA sont autorisées. Une occurrence doit être utilisée pour l’algorithme ou la
fonction de hachage nécessaire à la fourniture du service de sécurité défini dans le segment USH segment. Les
deux autres occurrences sont décrites dans la Partie 7 de l’ISO 9735.
Un mécanisme de remplissage peut être indiqué aux endroits appropriés.
© ISO 1999 – Tous droits réservés 5

---------------------- Page: 11 ----------------------
ISO 9735-5:1999(F)
Groupe de segments 2: USC-USA-USR (certificat)
Groupe de segments contenant les données nécessaires à la validation des méthodes de sécurité s’appliquant au
message/paquet, lorsque des algorithmes asymétriques sont utilisés. Le groupe de segments du certificat doit être
utilisé lorsque des algorithmes asymétriques sont utilisés pour identifier la paire de clésasymétriques utilisée,
même si des certificats ne sont pas utilisés.
Soit l’ensemble du groupe de segments (comprenant le segment USR), soit les seuls éléments de données
nécessaires à l’identification non ambiguë de la paire de clésasymétriques utilisée, doivent être présents dans le
segment USC. La présence d’un certificat complet peut être évitéesi lecertificatadéjàétééchangé entre les deux
partenaires ou s’il peut être extrait d’une base de données.
S’il est décidé de faire référence à un certificat non EDIFACT (tel qu’à un X.509), la syntaxe et la version de ce
certificat doivent être identifiés dans l’élément de données 0545 du segment USC. Ces certificats peuvent être
véhiculés dans un paquet EDIFACT.
Deux occurrences de ce groupe de segments sont autorisées, l’une correspondant au certificat de l’émetteur du
message/paquet (qui servira au récepteur du message/paquet à vérifier la signature de l’émetteur), l’autre
correspondant au certificat du récepteur de ce message/paquet (auquel il n’est fait référence que par la référence
du certificat) au cas où la clé publique du récepteur est utilisée par l’émetteur pour des raisons de confidentialité de
cléssymétriques.
SI les deux sont présentes au sein d’un groupe de segments d’en-tête de sécurité,l’élément de données
composite «Informations détaillées sur l’identification de la sécurité» (S500) ainsi que l’élément de données
«Référence du certificat» (0536) permettront de les différencier.
Ce groupe de segments doit être omis si aucun algorithme asymétrique n’est utilisé.
USC, Certificat
Segment contenant les justificatifs d’identité du propriétaire du certificat et identifiant l’autorité de certification qui a
généré le certificat. L’élément de données «Fonction du filtre, en code», (0505) doit identifier la fonction du filtre
utilisé pour les champs binaires des segments USA et du segment USR au sein du groupe de segments 2.
Le certificat USC peut contenir deux occurrences de l’élément de données S500: l’une pour le propriétaire du
certificat (identifiant l’intervenant qui signe avec la clé privée associée à la clé publique contenue dans ce
certificat), l’autre pour l’émetteur du certificat (autorité de certification ou «CA»).
USA, Algorithme de sécurité
Segment identifiant un algorithme de sécurité,l’utilisation technique qui en est faite et contenant les paramètres
techniques requis. Les trois occurrences différentes de ce segment USA dans le groupe de segments 2 identifient
1l’algorithme utilisé pour l’émetteur pour calculer la valeur de hachage du certificat (fonction de hachage);
2l’algorithme utilisé par l’émetteur du certificat pour produire le certificat (c’est-à-direlerésultat de la fonction de
hachage calculéà partir du contenu du certificat) (algorithme asymétrique);
3a soit l’algorithme utilisé par l’émetteur pour signer le message/paquet (c’est-à-dire, pour signer le résultat de la
fonction de hachage décrite dans le segment USH, calculéà partir du contenu du message/paquet)
(algorithme asymétrique);
3b soit l’algorithme asymétrique du récepteur, utilisé par l’émetteur pour chiffrer la clé requise, par un algorithme
symétrique appliqué au contenu du message/paquet et auquel fait référence le groupe de segments 1
déclenché par le segment USH) (algorithme asymétrique).
L’indication du mécanisme de remplissage peut être utilisée.
6 © ISO 1999 – Tous droits réservés

---------------------- Page: 12 ----------------------
ISO 9735-5:1999(F)
USR, Résultat de sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au certificat par l’autorité de certification. Ce
résultat doit être constitué par la signature du certificat calculée par l’autorité de certification en signant le résultat
de hachage calculéà partir des données du justificatif d’identité.
Pour le certificat, le calcul de la signature commence au premier caractère du segment USC (à savoir le «U»)et se
termine au dernier caractère du dernier segment USA (qui comprend le séparateur qui suit ce segment USA).
Groupe de segments n: UST-USR (groupe de fin de sécurité)
Groupe de segments contenant un lien avec le groupe de segments d’en-tête de sécurité et le résultat des
fonctions de sécurité appliquées au message/paquet.
UST, Fin de sécurité
Segment établissant un lien entre le groupe de segments d’en-tête de sécurité et de fin de sécurité et indiquant le
nombre de segments de sécurité contenu dans ces groupes.
USR, Résultat de sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au message/paquet comme précisé dans le
groupe d’en-tête de sécurité subordonné. En fonction des mécanismes de sécurité définis dans le groupe d’en-tête
de sécurité subordonné,cerésultat doit être, soit
� directement calculéà partir du message/paquet par l’algorithme défini dans le segment USA au sein du
groupe de segments 1 du groupe d’en-tête de sécurité ou
� calculé en signant, avec un algorithme asymétrique défini dans le segment USA au sein du groupe de
segments 2 du groupe de segments d’en-tête de sécurité,un résultat de hachage calculéà partir du
message/paquet par l’algorithme défini dans le segment USA au sein du groupe de segments 1 du groupe de
segments d’en-tête de sécurité.
5.1.4 Domaine d’application de la sécurité
La sécurité peut s’appliquer dans deux domaines :
1. Le calcul de chacune des valeurs d’intégrité et d’authentification et des signatures numériques commence
par, et comprend, le groupe de segments d’en-tête de sécurité courant et le corps du message ou l’objet, lui-
même. Dans ce cas, aucun autre groupe de segments d’en-tête ou de fin de sécurité ne doit entrer dans ce
domaine.
Le décompte du groupe de segments d’en-tête de sécurité doit être effectuéà partir du premier caractère, à
savoir «U», jusqu’au séparateur terminant le groupe de segments d’en-tête de sécurité, les deux compris et
le corps du message, ou l’objet, à partir du premier caractère suivant le séparateur terminant le dernier
groupe de segments d’en-tête de sécurité jusqu’au séparateur précédant le premier caractère du premier
groupe de segments de fin de sécurité, les deux compris.
Ainsi l’ordre dans lequel les services de sécurité intégrés de cette façon sont exécutés, n’est pas imposé.Ils
sont totalement indépendants les uns des autres.
La Figure 3 illustre ce cas (le domaine d’application du service de sécurité défini dans l’en-tête 2 est
représenté par des cases en grisé).
© ISO 1999 – Tous droits réservés 7

---------------------- Page: 13 ----------------------
ISO 9735-5:1999(F)
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments CORPS DU
UNH/ segments segments segments de UNT/
d’en-tête d’en-tête d’en-tête MESSAGE/
UNO de fin de de fin de fin de UNP
de de de OBJET
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 3 — Domaine d’application: groupe de segments d’en-tête de sécurité et corps
du message/objet seulement (schéma simplifié)
2. Le calcul commence par, et comprend, le groupe courant de segments d’en-tête de sécurité jusqu’au groupe
de segments de fin de sécurité associé. Dans ce cas, le groupe courant de segments d’en-tête de sécuri
...

Questions, Comments and Discussion

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