ISO 9735-6:1999
(Main)Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK)
É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)
General Information
Relations
Frequently Asked Questions
ISO 9735-6:1999 is a standard published by the International Organization for Standardization (ISO). Its full title is "Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK)". This standard covers: Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK)
ISO 9735-6:1999 is classified under the following ICS (International Classification for Standards) categories: 35.240.60 - IT applications in transport; 35.240.63 - IT applications in trade. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 9735-6:1999 has the following relationships with other standards: It is inter standard links to PSIST ISO 9735:1996, OSIST ISO 9735-6:2004, ISO 9735:1988/Amd 1:1992, ISO 9735:1988, ISO 9735-6:2002. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 9735-6:1999 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 9735-6
First edition
1999-04-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Application level syntax rules
(Syntax version number: 4) —
Part 6:
Secure authentication and acknowledgement
message (message type - AUTACK)
É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 6: Message de sécurité pour l’authentification et la connaissance
(type de message AUTACK)
A
Reference number
Page
Contents
1 Scope 1
2 Conformance 1
3 Normative references 1
4 Definitions 2
5 Rules for the use of the secure authentication and
acknowledgement message 2
Annex A: Syntax service directories (segments, composite data
elements and simple data elements) 7
Annex B: Service code directory 12
Annex C: AUTACK message examples 13
Annex D: Security services and algorithms 23
Annex E: Bibliography 30
© 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
©
ISO ISO 9735-6: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
©
— 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.
Annex A forms an integral part of this part of ISO 9735. Annexes B to E are
for information only.
iv
©
ISO ISO 9735-6: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 interchanges, by means of a secure authentication
and acknowledgement message.
v
©
INTERNATIONAL STANDARD ISO ISO 9735-6:1999(E)
Electronic data interchange for administration, commerce and
transport (EDIFACT) — Application level syntax rules — (Syntax
version number: 4) —
Part 6:
Secure authentication and acknowledgement message (message
type - AUTACK)
1 Scope
This part of ISO 9735 for EDIFACT security defines the secure authentication and acknowledgement message
AUTACK.
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 this part of ISO 9735 shall include conformance to Part 1, Part 2 and Part 5 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.
ISO 9735-1:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules — 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.
©
ISO
ISO 9735-5:1998, 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).
4 Definitions
For the purposes of this part of ISO 9735, the definitions in ISO 9735-1:1988, annex A and in ISO 9735-5:1998,
annex A apply.
5 Rules for the use of the secure authentication and acknowledgement message
5.1 Functional definition
AUTACK is a message authenticating sent, or providing secure acknowledgement of received interchanges,
groups, messages or packages.
A secure authentication and acknowledgement message can be used to:
a) give secure authentication, integrity or non-repudiation of origin to messages, packages, groups or interchanges.
b) give secure acknowledgement or non-repudiation of receipt to secured messages, packages, groups or
interchanges.
5.2 Field of application
The secure authentication and acknowledgement message (AUTACK) may be used for both national and
international trade. It is based on universal practice related to administration, commerce and transport, and is not
dependent on the type of business or industry.
5.3 Principles
The applied security procedures shall be agreed to by trading partners and specified in an interchange agreement.
The secure authentication and acknowledgement message (AUTACK) applies security services to other EDIFACT
structures (messages, packages, groups or interchanges) and provides secure acknowledgement to secured
EDIFACT structures. It can be applied to combinations of EDIFACT structures that need to be secured between two
parties.
The security services are provided by cryptographic mechanisms applied to the content of the original EDIFACT
structures. The results of these mechanisms form the body of the AUTACK message, supplemented by relevant
data such as references of the cryptographic methods used, the reference numbers for the EDIFACT structures
and the date and time of the original structures.
The AUTACK message shall use the standard security header and trailer groups.
The AUTACK message can apply to one or more messages, packages or groups from one or more interchanges,
or to one or more interchanges.
5.3.1 Use of AUTACK for the authentication function
An AUTACK message used as an authentication message shall be sent by the originator of one or more other
EDIFACT structures, or by a party having authority to act on behalf of the originator. Its purpose is to facilitate the
security services defined in Part 5 of ISO 9735, i.e. authenticity, integrity, and non-repudiation of origin of its
associated EDIFACT structures.
An AUTACK authentication message can be implemented in two ways. The first method conveys the hashed
values of the referenced EDIFACT structures secured by the AUTACK itself; the second uses the AUTACK only to
convey digital signatures of the referenced EDIFACT structures.
©
ISO
5.3.1.1 Authentication using hash values of the referenced EDIFACT structures
The secured EDIFACT structure shall be referenced in an occurrence of the USX (security references) segment.
For each USX there shall be at least one corresponding USY (security on references) segment which contains the
security result, for example the hash value, of the security function performed on the referenced EDIFACT
structure.
Details about the security function performed shall be contained in the AUTACK security header group. The USY
and USH segments for the referenced EDIFACT structure shall be linked using security reference number data
elements in both segments.
As a final step, all the information conveyed in the AUTACK shall be secured using at least one pair of security
header and security trailer groups.
Note:
AUTACK uses the USX segment to reference one or more messages, packages or groups in one or more
interchanges, or to reference an entire interchange. For each USX segment a corresponding USY segment
contains the result of the hashing, authentication or non-repudiation method applied to the referenced
EDIFACT structure.
5.3.1.2 Authentication using digital signatures of the referenced EDIFACT structures
The secured EDIFACT structure shall be referenced in an occurrence of the USX (security references) segment.
For each USX at least one corresponding USY (security on references) segment, which contains the digital
signature of the referenced EDIFACT structure, shall be present. Details about the security function performed shall
be contained in the AUTACK security header group. Because a single referenced EDIFACT structure may be
secured more than once, the related USY and security header group shall be linked using security reference
number data elements in both segments.
If the digital signature of the referenced EDIFACT structure is contained in AUTACK (rather than just a hash value),
the AUTACK does not itself require to be secured.
5.3.2 The use of AUTACK for the acknowledgement function
An AUTACK message used as an acknowledgement message shall be sent by the recipient of one or more
previously received secured EDIFACT structures, or by a party having authority to act on behalf of the recipient. Its
purpose is to facilitate confirmation of receipt, validation of integrity of content, validation of completeness and/or
non-repudiation of receipt of its associated EDIFACT structures.
The acknowledgement function shall be applied only to secured EDIFACT structures. The secured EDIFACT
structure shall be referenced in an occurrence of the USX (security references) segment. For each USX there shall
be at least one corresponding USY (security on references) segment which contains either the hash value or the
digital signature of the referenced EDIFACT structure. The USY shall be linked to a security header group of the
referenced EDIFACT structure, or of an AUTACK message securing it, by using security reference number data
element. The corresponding security header related to the referenced EDIFACT structure contains the details of the
security function performed on the referenced EDIFACT structure by the sender of the original message.
As a final step in generation of the acknowledgement message, all the information conveyed in the AUTACK shall
be secured using at least one pair of security header and security trailer groups.
AUTACK may also be used for non-acknowledgement in case of problems with the verification of the security
results.
Note :
Secure acknowledgement is only meaningful for secured EDIFACT structures. Securing EDIFACT
structures is accomplished by the use of either integrated security segments (see Part 5 of ISO 9735) or
AUTACK authentication.
To prevent endless loops, an AUTACK used for the acknowledgement function shall not require its recipient to send
back an AUTACK acknowledgement message.
©
ISO
5.4 Message definition
5.4.1 Data segment clarification
0010 UNH, Message header
A service segment starting and uniquely identifying a message.
The message type code for the secure authentication and acknowledgement message is AUTACK.
The data element message type sub-function identification shall be used to indicate the usage of the
AUTACK function as either authentication, acknowledgement or refusal of acknowledgement.
Note: messages conforming to this document must contain the following data in segment UNH, composite
S009:
Data element 0065 AUTACK
0052 4
0054 1
0051 UN
0020 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 (as defined in Part 5 of ISO 9735).
This segment group shall specify the security service and algorithm(s) applied to the AUTACK message or
applied to the referenced EDIFACT structure.
Each security header group shall be linked to a security trailer group, and some may be linked additionally to
USY segments.
0030 USH, Security header
A segment specifying a security service applied to the message/package in which the segment is included,
or to the referenced EDIFACT structure (as defined in Part 5 of ISO 9735).
The security service data element shall specify the security function applied to the AUTACK message or the
referenced EDIFACT structure:
- the security services: message origin authentication and non-repudiation of origin shall only be used for the
AUTACK message itself.
- the security services: referenced EDIFACT structure integrity, referenced EDIFACT structure origin
authentication and referenced EDIFACT structure non-repudiation of origin shall only be used by the sender
to secure the AUTACK referenced EDIFACT structures.
- the security services: receipt authentication and non-repudiation of receipt shall only be used by the receiver
of secured EDIFACT structures to secure the acknowledgement.
The scope of security application of the security service shall be specified, as defined in Part 5 of ISO 9735.
In an AUTACK message, there are four possible scopes of security application:
- the first two scopes are as defined in Part 5 of ISO 9735 section 5.
- the third scope includes the whole EDIFACT structure, in which the scope of the security application is from
the first character of the referenced message, package, group or interchange (namely a "U") to the last
character of the message, package, group or interchange, inclusive.
- the fourth scope is user defined, in which scope the security application is defined in an agreement between
sender and receiver.
0040 USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required (as defined in Part 5 of ISO 9735).
0050 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 (as defined in Part 5 of ISO 9735).
0060 USC, Certificate
A segment containing the credentials of the certificate owner and identifying the certification authority which
has generated the certificate (as defined in Part 5 of ISO 9735).
0070 USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required (as defined in Part 5 of ISO 9735).
©
ISO
0080 USR, Security result
A segment containing the result of the security functions applied to the certificate by the certification authority
(as defined in Part 5 of ISO 9735).
0090 USB, Secured data identification
This segment shall contain identification of the interchange sender and interchange recipient, a security
related timestamp of the AUTACK and it shall specify whether a secure acknowledgement from the AUTACK
message recipient is required or not. If one is required, the message sender will expect an AUTACK
acknowledgement message to be sent back by the message recipient.
The interchange sender and interchange recipient in USB shall refer to the sender and the recipient of the
interchange in which the AUTACK is present, in order to secure this information.
0100 Segment group 3: USX-USY
This segment group shall be used to identify a party in the security process and to give security information
on the referenced EDIFACT structure.
0110 USX, Security references
This segment shall contain references to the party involved in the security process.
The composite data element security date and time may contain the original generation date and time of the
referenced EDIFACT structure.
If data element 0020 is present and none of: 0048, 0062 and 0800 are present, the whole interchange is
referenced.
If data elements 0020 and 0048 are present and none of: 0062 and 0800 are present, the group is
referenced.
0120 USY, Security on references
A segment containing a link to a security header group and the result of the security services applied to the
referenced EDIFACT structure as specified in this linked security header group.
When the referenced EDIFACT structures are secured by the same security service, with the same related
security parameters many USY segments may be linked to the same security header group. In this case the
link value between the security header group and the related USYs shall be the same.
When AUTACK is used for the acknowledgement function the corresponding security header group shall be
either one of the referenced EDIFACT structure or of an AUTACK message that is used to provide the
referenced EDIFACT structure with the authentication function.
In a USY segment the value of data element 0534 shall be identical to the value in 0534 in the corresponding
USH segment of either:
- the current AUTACK, if the authentication function is used (security services: referenced EDIFACT structure
origin authenticity, referenced EDIFACT structure integrity or referenced EDIFACT structure non-
repudiation of origin)
- the referenced EDIFACT structure itself, or an AUTACK message providing the referenced EDIFACT
structure with the authentication function, if the acknowledgement function is used (security services: non-
repudiation of receipt or receipt authentication)
0130 Segment Group 4: 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 (as defined in Part 5 of ISO 9735).
USR segment may be omitted if the security trailer group is linked to a security header group related to a
referenced EDIFACT structure. In this case the corresponding results of the security function shall be found
in the USY segments which are linked to the relevant security header group.
0140 UST, Security trailer
A segment establishing a link between security header and security trailer segment group and stating the
number of security segments contained in these groups (as defined in Part 5 of ISO 9735).
0150 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 (as defined in Part 5 of ISO 9735). The security result in this segment shall be
applied to the AUTACK message itself.
0160 UNT, Message trailer
A service segment ending a message, giving the total number of segments and the control reference number
of the message.
©
ISO
5.4.2 Message structure
5.4.2.1 Segment table
POS TAG Name S R Notes
0010 UNH Message header M 1
0020 ---- Segment group 1 ------------- M 99 -------+
0030 USH Security header M 1 |
0040 USA Security algorithm C 3 |
|
0050 ----- Segment group 2 ------------- C 2 ----+ |
0060 USC Certificate M 1 | |
0070 USA Security algorithm C 3 | |
0080 USR Security result C 1 ----+--+
0090 USB Secured data identification M 1
0100 ----- Segment group 3 ------------- M 9999 ----+
0110 USX Security references M 1 |
0120 USY Security on references M 9 ----+
0130 ----- Segment group 4 ------------- M 99 ----+
0140 UST Security trailer M 1 |
0150 USR Security result C 1 ----+
0160 UNT Message trailer M 1
Note: The message body of the AUTACK message comprises the USB segment and segment group 3.
©
ISO
Annex A
(normative)
Addendum — to be added to Part 1 annex C when approved
Syntax service directories
(segments, composite data elements and simple data elements)
A.1 Segment directory
A.1.1 Segment specification legend:
Function The function of the segment
POS The sequential position number of the stand-alone data element or composite data element in the
segment table
TAG The tags for all service segments contained in the segment directory start with the letter “U”. The tags
of all service composite data elements start with the letter "S", and the tags of all service simple data
elements start with the figure "0"
Name Name of a COMPOSITE DATA ELEMENT in capital letters
Name of a STAND-ALONE DATA ELEMENT in capital letters
Name of a component data element in small letters
S The status of the stand-alone data element or composite data element in the segment, or of the
components in the composite (where M = Mandatory and C = Conditional)
R The maximum number of occurrences of a stand-alone data element or composite data element in the
segment
Repr. Data value representation of the stand-alone data element or component data elements in the
composite.
a alphabetic characters
n numeric characters
an alphanumeric characters
a3 3 alphabetic characters, fixed length
n3 3 numeric characters, fixed length
an3 3 alphanumeric characters, fixed length
a.3 up to 3 alphabetic characters
n.3 up to 3 numeric characters
an.3 up to 3 alphanumeric characters
A.1.2 Dependency note identifiers
Code Name
D1 One and only one
D2 All or none
D3 One or more
D4 One or none
D5 If first, then all
D6 If first, then at least one more
D7 If first, then none of the others
See clause 11.5 in ISO 9735-1:1998 for the definition of the dependency note identifiers.
©
ISO
A.1.3 Index of segments by tag
TAG Name
UNH Message header
UNT Message trailer
USA Security algorithm
USB Secured data identification
USC Certificate
USH Security header
USR Security result
UST Security trailer
USX Security references
USY Security on references
A.1.4 Index of segments by name
TAG Name
USC Certificate
UNH Message header
UNT Message trailer
USB Secured data identification
USA Security algorithm
USH Security header
USY Security on references
USX Security references
USR Security result
UST Security trailer
A.1.5 Segment specifications
Note:
Only segments not defined in other parts of ISO 9735 are included here.
---------------------------------------------------------------------------
USB SECURED DATA IDENTIFICATION
Function: To contain details related to the AUTACK.
POS TAG Name S R Repr. Notes
010 0503 RESPONSE TYPE, CODED M 1 an.3
020 S501 SECURITY DATE AND TIME C 1
0517 Date and time qualifier M an.3
0338 Event date C n.8
0314 Event time C an.15
0336 Time offset C n4
030 S002 INTERCHANGE SENDER M 1
0004 Interchange sender identification M an.35
0007 Identification code qualifier C an.4
0008 Interchange sender internal identification C an.35
0042 Interchange sender internal
sub-identification C an.35
©
ISO
040 S003 INTERCHANGE RECIPIENT M 1
0010 Interchange recipient identification M an.35
0007 Identification code qualifier C an.4
0014 Interchange recipient internal
identification C an.35
0046 Interchange recipient internal
sub-identification C an.35
---------------------------------------------------------------------------
---------------------------------------------------------------------------
USX SECURITY REFERENCES
Function: To refer to the secured EDIFACT structure and its associated date
and time.
POS TAG Name S R Repr. Notes
010 0020 INTERCHANGE CONTROL REFERENCE M 1 an.14
020 S002 INTERCHANGE SENDER C 1
0004 Interchange sender identification M an.35
0007 Identification code qualifier C an.4
0008 Interchange sender internal identification C an.35
0042 Interchange sender internal
sub-identification C an.35
030 S003 INTERCHANGE RECIPIENT C 1
0010 Interchange recipient identification M an.35
0007 Identification code qualifier C an.4
0014 Interchange recipient internal
identification C an.35
0046 Interchange recipient internal
sub-identification C an.35
040 0048 GROUP REFERENCE NUMBER C 1 an.14 1,3
050 S006 APPLICATION SENDER IDENTIFICATION C 1 1
0040 Application sender identification M an.35
0007 Identification code qualifier C an.4
060 S007 APPLICATION RECIPIENT IDENTIFICATION C 1 3
0044 Application recipient identification M an.35
0007 Identification code qualifier C an.4
070 0062 MESSAGE REFERENCE NUMBER C 1 an.14 2,4
080 S009 MESSAGE IDENTIFIER C 1 4
0065 Message type M an.6
0052 Message version number M an.3
0054 Message release number M an.3
0051 Controlling agency, coded M an.3
0057 Association assigned code C an.6
0110 Code list directory version number C an.6
0113 Message type sub-function identification C an.6
090 0800 PACKAGE REFERENCE NUMBER C 1 an.14 2
100 S501 SECURITY DATE AND TIME C 1
0517 Date and time qualifier M an.3
0338 Event date C n.8
0314 Event time C an.15
0336 Time offset C n4
©
ISO
DEPENDENCY NOTES:
1. D5 (050, 040) If first, then all
2. D1 (070, 090) One and only one
3. D5 (060, 040) If first, then all
4. D5 (080, 070) If first, then all
---------------------------------------------------------------------------
USY SECURITY ON REFERENCES
Function: To identify the applicable header, and to contain the security
result and/or to indicate the possible cause of security
rejection for the referred value.
POS TAG Name S R Repr. Notes
010 0534 SECURITY REFERENCE NUMBER M 1 an.14
020 S508 VALIDATION RESULT C 2 1
0563 Validation value qualifier M an.3
0560 Validation value C an.512
030 0571 SECURITY ERROR, CODED C 1 an.3 1
NOTES:
1. D3 (020, 030) One or more
---------------------------------------------------------------------------
A.2 Composite data element directory
No composite data elements are defined.
A.3 Simple data element directory
A.3.1 Simple data element specification legend:
The tags of all service simple data elements contained in the simple data element directory start with the figure “0”.
Name Name of a simple data element
Desc. Description of the simple data element
Repr. Data value representation of the simple data element:
a alphabetic characters
n numeric characters
an alphanumeric characters
a3 3 alphabetic characters, fixed length
n3 3 numeric characters, fixed length
an3 3 alphanumeric characters, fixed length
a.3 up to 3 alphabetic characters
n.3 up to 3 numeric characters
an.3 up to 3 alphanumeric characters
Notes Simple data element note number(s)
©
ISO
A.3.2 Index of simple data elements by tag
TAG Name
0020 Interchange control reference
0048 Group reference number
0062 Message reference number
0503 Response type, coded
0534 Security reference number
0571 Security error, coded
0800 Package reference number
A.3.3 Index of simple data elements by name
TAG Name
0048 Group reference number
0020 Interchange control reference
0062 Message reference number
0800 Package reference number
0503 Response type, coded
0571 Security error, coded
0534 Security reference number
A.3.4 Simple data element specifications
Note:
Only simple data elements not defined in other parts of ISO 9735 are included here.
---------------------------------------------------------------------------
0571 SECURITY ERROR, CODED
Desc: Identifies the security error causing the rejection of the EDIFACT
structure.
Repr: an.3
Note 1: This element shall specify the security error encountered. These may
be the reason for non-acknowledgement by a request for secure
acknowledgement, or may be sent on the initiative of the receiver of
an AUTACK or secured EDIFACT structure which contains error.
---------------------------------------------------------------------------
©
ISO
Annex B
(informative)
Service code directory
The service code directory is maintained by the UN/ECE and is part of the UN Trade Data Interchange Directory
(UNTDID) and as such is not reproduced in this International Standard. The most recent version of the service
code directory should be used to reference the code values for the coded data elements in the simple data element
directory (see annex C within this part). The UNTDID is updated and published at regular intervals.
©
ISO
Annex C
(informative)
AUTACK message examples
Three examples are provided herein to illustrate different applications of the AUTACK message.
The first one shows how to use an AUTACK message to secure a previously sent message, in order to provide the
security service of non-repudiation of origin. An AUTACK acknowledgement message is required.
The second example shows how an AUTACK message may secure two messages with different security services :
non repudiation of origin for one message, message origin authentication for an other message.
The third example illustrates the usage of AUTACK message for secure acknowledgement. It shows the AUTACK
acknowledgement message required by the AUTACK in the first example.
C.1 Example 1: Non-repudiation of origin service provided by an AUTACK message
C.1.1 Narrative
Bank A wants the security service of non repudiation of origin on the payment orders from Company A, performed
by Mr. Smith when they exceed a certain amount.
The interchange agreement between the parties establishes that the security service of non repudiation of origin,
required by Bank A, shall be achieved for these payment orders, by Mr. Smith of Company A, with the use of one
digital signature.
Both parties agree that this digital signature is computed by 512 bit RSA (asymmetric algorithm) upon a hashing
value computed using the MD5 algorithm.
The certificate identifying the public key of Mr. Smith is issued by an authority trusted by both parties, the certificate
issuer.
In these conditions, because the digital signature of the PAYORD is included in the AUTACK message, the
AUTACK itself does not need to be signed.
The PAYORD message secured by AUTACK was the third message of the first interchange sent by Mr. Smith to
the Bank A. It was generated in 1996.01.15 at 10:00:00.
The AUTACK itself was the fifth message of the interchange and it was generated in 1996.01.15 at 10:05:32.
The appearing security segments are the following ones:
• USH to indicate the security service applied to the PAYORD message.
• USC-USA-USA-USA-USR, the certificate of Mr. Smith.
• USB
• USX-USY with the security references and results (for PAYORD message).
• UST, without USR, referencing the USH.
C.1.2 Security details
SECURITY HEADER
SECURITY SERVICE, CODED Non repudiation of origin
SECURITY REFERENCE NUMBER The reference of this header is 1
RESPONSE TYPE Acknowledgement required: 1
FILTER FUNCTION All binary values (signatures) are filtered with
hexadecimal filter
ORIGINAL CHARACTER SET The message was coded in ASCII 8 bits when its
ENCODING signature was generated.
CERTIFICATE certificate of Mr. SMITH
CERTIFICATE REFERENCE This certificate is referenced, by AUTHORITY: 00000001.
SECURITY IDENTIFICATION DETAILS
Certificate owner Mr. SMITH of Company A
©
ISO
SECURITY IDENTIFICATION DETAILS
Certificate issuer Mr. SMITH's certificate was generated by a certification
Authority called: AUTHORITY.
Key name The Public Key of AUTHORITY used to generate Mr.
SMITH's certificate is PK1
CERTIFICATE SYNTAX VERSION Version of certificate of UN/EDIFACT service segment
directory.
FILTER FUNCTION All binary values (keys and digital signatures) are filtered
with hexadecimal filter
ORIGINAL CHARACTER SET The credentials of the certificate were coded in ASCII 8
ENCODING bits when the certificate was generated.
SERVICE CHARACTER FOR Service character used when signature was computed
SIGNATURE
Service character for signature qualifier Service character is segment terminator.
Service character for signature Value "'" (apostrophe).
SERVICE CHARACTER FOR Service character used when signature was computed
SIGNATURE
Service character for signature qualifier Service character is data element separator.
Service character for signature Value "+" (plus sign).
SERVICE CHARACTER FOR Service character used when signature was computed
SIGNATURE
Service character for signature qualifier Service character is component data element separator.
Service character for signature Value ":" (colon).
SERVICE CHARACTER FOR Service character used when signature was computed
SIGNATURE
Service character for signature qualifier Service character is repetition separator.
Service character for signature Value "*" (asterisk).
SERVICE CHARACTER FOR Service character used when signature was computed
SIGNATURE
Service character for signature qualifier Service character is release character.
Service character for signature Value "?" (question mark).
SECURITY DATE AND TIME Certificate generation time
Date and time Mr. SMITH certificate was generated on 931215 at
14:12:00
SECURITY DATE AND TIME Certificate start of validity period
Date and time Validity period of Mr. SMITH's certificate starts: 1996 01
01 000000
SECURITY DATE AND TIME Certificate end of validity period
Date and time Validity of Mr. SMITH's certificate ends: 1996 12 31
SECURITY ALGORITHM Asymmetric algorithm used by Mr. SMITH to sign
SECURITY ALGORITHM
Use of algorithm An owner signing algorithm is used.
Cryptographic mode of operation No mode of operation is relevant here.
Algorithm RSA is the asymmetric algorithm.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as a Public exponent
for signature verification.
Algorithm parameter value Mr SMITH's public key.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as a Modulus for
signature verification.
Algorithm parameter value Mr SMITH's modulus.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as the length of Mr
SMITH's modulus (in bits).
Algorithm parameter value Mr SMITH's modulus is 512 bits long.
SECURITY ALGORITHM Hash function used by AUTHORITY to generate Mr
SMITH's certificate
©
ISO
SECURITY ALGORITHM
Use of algorithm An issuer hashing algorithm is used.
Cryptographic mode of operation Hash function CD 10118-2 Hash functions using a n- bit
block cipher algorithm applied to provide a double length
hash code (128 bits); initializing values:
A = 01234567 B = 89ABCDEF
C = FEDCBA98 D = 76543210
Algorithm MD5 message-digest algorithm is used
SECURITY ALGORITHM Asymmetric algorithm used by AUTHORITY to sign
SECURITY ALGORITHM
Use of algorithm An issuer signing algorithm is used.
Cryptographic mode of operation No mode of operation is relevant here.
Algorithm RSA is the asymmetric algorithm.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as a public exponent
for signature verification.
Algorithm parameter value AUTHORITY's public key.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as a Modulus for
signature verification.
Algorithm parameter value AUTHORITY's modulus.
ALGORITHM PARAMETER
Algorithm parameter qualifier Identifies this algorithm parameter as the length of
AUTHORITY's modulus (in bits).
Algorithm parameter value AUTHORITY's modulus is 512 bits long.
Digital signature of the certificate
SECURITY RESULT
VALIDATION RESULT
Validation value qualifier Digital signature
Validation value 512 Bit filtered hexadecimal digital signature
SECURED DATA IDENTIFICATION
RESPONSE TYPE, CODED A secure acknowledgement from the Bank A is required
SECURITY DATE AND TIME A security related time-stamp of the AUTACK.
The security time stamp is : date: 1996 01 15
time: 10:05:32
INTERCHANGE SENDER Identification of the interchange sender
Interchange sender identification Identification of Mr.Smith, Company A
INTERCHANGE RECIPIENT Identification of the interchange recipient
Interchange sender identification Identification of Bank A
SECURITY REFERENCES Refers to the security entity (PAYORD related with the
service of non repudiation of origin) and its associated
date and time.
INTERCHANGE CONTROL Identifies the reference number assigned by the sender to
REFERENCE the interchange of the message PAYORD: 1
INTERCHANGE SENDER
Interchange sender identification Identifies the sender of the interchange of the message
PAYORD: Mr. Smith from Company A.
INTERCHANGE RECIPIENT
Interchange recipient identification Identifies the recipient of the interchange of the message
PAYORD: Bank A
MESSAGE REFERENCE NUMBER Identifies the reference number assigned by the sender to
the PAYORD message: 3.
SECURITY DATE AND TIME A security related time-stamp referring the PAYORD
Date and time The security time stamp is date: 1996 01 15 time:
10:00:00
SECURITY ON REFERENCES Identifies the applicable header (associated with the
functions of security applied to the PAYORD message) ,
and the result of applying these functions to the PAYORD
message.
SECURITY REFERENCE NUMBER Number which links the validation result to the
corresponding USH segment. In this case his value is 1.
©
ISO
VALIDATION RESULT
Validation value qualifier Digital Signature (of the PAYORD message).
Validation value 512 bit filtered hexadecimal Digital signature
SECURITY TRAILER
SECURITY REFERENCE NUMBER The reference of this security trailer is 1
NUMBER OF SECURITY SEGMENTS The number of security segments is 7
C.2 Example 2: Securing several messages with AUTACK.
C.2.1 Narrative
Bank A wants the security service of non repudiation of origin on the payment orders from Company A, performed
by Mr. Smith when they exceed a certain amount. For those payment orders not exceeding such amount, message
origin authentication service is requested.
The interchange agreement between the parties establishes that the security service of non repudiation of origin,
required by Bank A, shall be achieved for these payment orders, by Mr. Smith of Company A, with the use of one
digital signature. Both parties agree that this digital signature is computed by 512 bit RSA (asymmetric algorithm)
upon a hashing value computed using the MD5 algorithm.
In addition, message origin authentication will be achieved by generating a "Message Authentication Code" (MAC)
with the symmetric DES according to ISO 8731-1 at the sender's site.
The certificate identifying the public key of Mr. Smith is issued by an authority trusted by both parties, the certificate
issuer.
The first PAYORD message sent has to be secured with a digital signature by AUTACK. It is the fifth message of
the first interchange sent by Mr. Smith to Bank A. It was sent in 1996.01.15 at 08:00:00.
The second PAYORD message sent has to be secured with a MAC by AUTACK. It is the seventh message of the
first interchange. It was sent in 1996.01.15 at 09:00:00.
The AUTACK itself is the tenth message of the first interchange. It was sent in 1996.01.15 at 10:05:32.
As the first PAYORD message is secured with a digital signature, the AUTACK itself does not need to be signed.
In consequence, the appearing security segments are the following ones:
• USH to indicate the non-repudiation of origin service applied to the first PAYORD message.
• USC-USA-
...
NORME ISO
INTERNATIONALE 9735-6
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 6:
Message sécurisé Authentification et
accusé de réception (type de message
AUTACK)
Electronic data interchange for administration, commerce and transport
(EDIFACT) — Application level syntax rules (Syntax version number: 4) —
Part 6: Secure authentication and acknowledgement message (message
type-AUTACK)
Numéro de référence
©
ISO 1999
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
Sommaire Page
1 Domaine d'application.1
2 Conformité.1
3Références normatives .1
4Définitions .2
5Règles d’utilisation du message sécurisé Authentification et accusé de réception.2
Annexe A Addendum—à ajouter à l’annexe C de la Partie 1 une fois approuvée — Répertoires de
service syntaxiques (segments, éléments de données composites et éléments de données
simples) .8
Annexe B Répertoire des codes de service.14
Annexe C Exemples de messages AUTACK .15
Annexe D Services de sécurité et algorithmes.29
Annexe E Bibliographie.37
© ISO 1999 – Tous droits réservés iii
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-6 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
D'autres parties pourront être ajoutées ultérieurement.
L'annexe A constitue un élément normatif de la présente partie de l’ISO 9735. Les annexes B à E ne sont données
qu’à titre d’information.
© ISO 1999 – Tous droits réservés v
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.
La présente partie est nouvelle. Elle a été ajoutée à l'ISO 9735. Elle offre la possibilité de sécuriser des structures
EDIFACT, c’est-à-dire des messages, des paquets, des groupes ou des échanges au moyen d’un message
sécurisé d’authentification et d’accusé de réception.
vi © ISO 1999 – Tous droits réservés
NORME INTERNATIONALE ISO 9735-6:1999(F)
É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 Domaine d'application
La présente partie de l'ISO 9735 est destinée à la sécurité EDIFACT et définit le message Authentification et
accusé de réception sécurisé AUTACK.
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ésentepartiede l’ISO 9735 doit prendre en compte la conformité aux Parties 1, 2 et 5 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 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 1999 – Tous droits réservés 1
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-5: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 5: Règles
de sécurité pour l'EDI par lots (authentification, intégrité et non-répudiation de l'origine).
4Définitions
Pour les besoins de la présente partie de l’ISO 9735, les définitions données dans l’ISO 9735-1:1998, annexe A,
et dans l’ISO 9735-5:1999, annexe A, s’appliquent.
5Règles d’utilisation du message sécurisé Authentification et accusé de réception
5.1 Définition fonctionnelle
AUTACK est un message authentifiant des échanges, groupes, messages ou paquets émis ou permettant d’en
accuser réceptiondefaçon sécurisée.
Un message sécurisé d’authentification et d’accusé de réception peut servir à
a) appliquer l’authentification, l’intégrité ou la non-répudiation de l’origine à des messages, paquets, groupes ou
échanges;
b) assurer l’accusé de réception ou la non-répudiation de la réception sécurisés à des messages, paquets,
groupes ou échanges sécurisés.
5.2 Champ d’application
Le message sécurisé d’authentification et d’accusé de réception (AUTACK) peut être utilisé pour le commerce
tant national qu’international. Il est fondé sur la pratique universelle concernant l’administration, le commerce et le
transport. Il ne dépend pas du type d’activité commerciale ou industrielle.
5.3 Principes
Les procédures de sécurité qui s’appliquent doivent être convenues par les partenaires commerciaux et définies
dans un accord d’échange.
Le message sécurisé d’authentification et d’accusé de réception(AUTACK) permetdesécuriser d’autres
structures EDIFACT (messages, paquets, groupes ou échanges) et de fournir un accusé de réception sécurisé
relatif à des structures EDIFACT sécurisées. Il peut s’appliquer à des combinaisons de structures EDIFACT
devant être sécurisées entre deux partenaires.
Les services de sécurité sont fournis par des mécanismes cryptographiques appliqués au contenu des structures
EDIFACT initiales. Les résultats de ces mécanismes constituent le corps du message AUTACK et sont fournis
par les données appropriées telles que les références des méthodes cryptographiques utilisées, les numéros de
référence des structures EDIFACT et la date et l’heure des structures initiales.
Le message AUTACK doit utiliser les groupes d’en-tête etdefindesécurité standardisés.
Le message AUTACK peut s’appliquer à un ou plusieurs messages, paquets ou groupes d’un ou de plusieurs
échanges, ou à un ou plusieurs échanges.
2 © ISO 1999 – Tous droits réservés
5.3.1 Utilisation du message AUTACK pour remplir la fonction d’authentification
Un message AUTACK utilisé comme message d’authentification doit être émis par l‘initiateur d’uneoude
plusieurs structures EDIFACT acheminées séparément, ou par un intervenant habilitéà agir au nom de
l’initiateur. Son but est d’optimiser les services de sécurité définis dans la Partie 5 de l’ISO 9735, c’est-à-dire
l’authenticité,l’intégrité,etlanon-répudiation de l’origine des structures EDIFACT y étant associées.
Un message d’authentification AUTACK peut être mis en œuvre de deux façons. La première méthode véhicule
les valeurs de hachage des structures EDIFACT référencées, sécurisées par le message AUTACK lui-même; la
seconde n’utilise le message AUTACK que pour véhiculer les signatures numériques des structures EDIFACT
référencées.
5.3.1.1 Authentification utilisant les valeurs de hachage des structures EDIFACT référencées
La structure EDIFACT sécuriséedoit être référencée dans une occurrence du segment USX (références de
sécurité). A chaque segment USX, doit correspondre au moins un segment USY (sécurité sur les références) qui
contient le résultat de la sécurité, par exemple la valeur de hachage de la fonction de sécurisation appliquée à la
structure EDIFACT référencée.
Les informations détaillées sur la fonction appliquée doivent être contenues dans le groupe d’en-tête de sécurité
du message AUTACK. Les segments USY et USH de la structure EDIFACT référencée doivent être reliés à l’aide
des éléments de données du numéro de référencedelasécurité dans les deux segments.
En dernier lieu, toutes les informations véhiculées dans le message AUTACK doivent être sécurisées à l’aide d’au
moins une paire de groupes d’en-tête et de fin de sécurité.
NOTE AUTACK utilise le segment USX pour référencer un ou plusieurs messages, paquets ou groupes dans un ou
plusieurs échanges ou pour référencer un échange complet. A chaque segment USX, un segment USY correspondant contient
le résultat de hachage, la méthode d’authentification ou de non-répudiation appliquée à la structure EDIFACT référencée.
5.3.1.2 Authentification utilisant les signatures numériques de structures EDIFACT référencées
La structure EDIFACT sécuriséedoit être référencée dans une occurrence du segment USX (références de
sécurité). A chaque segment USX au moins un segment USY (sécurité sur les références) correspondant, qui
contient la signature numérique de la structure EDIFACT référencée, doit être présent. Les informations détaillées
sur la fonction de sécurité appliquée doivent être contenues dans le groupe d’en-tête de sécurité du message
AUTACK. Du fait qu’une seule structure EDIFACT référencéepeut être sécuriséeplus d’une fois, le segment USY
et le groupe d’en-tête de sécurité associés doivent être reliés à l’aide des éléments de données du numéro de
référence des deux segments.
Si la signature numérique de la structure EDIFACT référencée est contenue dans le message AUTACK (plutôt
qu’une simple valeur de hachage), ce dernier n’a pas besoin d’être sécurisé.
5.3.2 Utilisation du message AUTACK pour assurer la fonction d’accusé de réception
Un message AUTACK utilisé comme message d’accusé de réception doit être émis par le destinataire d’une ou de
plusieurs structures EDIFACT sécurisées qu’il aura précédemment reçues ou par l’intervenant habilitéà agir au
nom du destinataire. Le but visé est de faciliter la confirmation de la réception, la validation de l’intégrité du
contenu, la validation de l’intégralité et/ou la non-répudiation de réception de ses structures EDIFACT y étant
associées.
La fonction d’accusé de réceptionnedoit être appliquéequ’à des structures EDIFACT. La structure EDIFACT
sécuriséedoit être référencée dans une occurrence du segment USX (références de sécurité). A chaque segment
USX, doit correspondre au moins un segment USY (sécurité sur les références) qui contient soit la valeur de
hachage, soit la signature numériquedelastructure EDIFACT référencée. Le segment USY doit être reliéà un
groupe d'en-tête de sécurité de la structure EDIFACT référencéeoud’un message AUTACK le sécurisant, à l’aide
de l’élément de données « numéro de référencedelasécurité».L’en-tête de sécurité correspondante associéà la
structure EDIFACT référencée contient les informations détaillées sur la fonction de sécurité,appliquée à la
structure EDIFACT référencée par l’émetteur du message initial.
© ISO 1999 – Tous droits réservés 3
A la dernière étape de la génération du message d’accusé de réception, toutes les informations véhiculées dans le
message AUTACK doivent être sécurisées à l’aide d’au moins une paire de groupes d’en-tête etdefindesécurité.
Le message AUTACK peut également servir d’accusé de non-réception au cas où la vérification des résultats de
sécurité poserait des difficultés.
NOTE L’accusé de réception ne prend son sens que pour les structures EDIFACT sécurisées. La sécurisation des
structures EDIFACT s’effectue par l’utilisation soit de segments de sécurité intégrés (voir Partie 5 de l’ISO 9735), soit par le
message d’authentification AUTACK.
Pour éviter des boucles infinies, un message AUTACK utilisé pour assurer la fonction d’accusé de réception ne
doit pas obliger son destinataire à renvoyer un message d’accusé de réception AUTACK.
5.4 Définition du message
5.4.1 Précisions sur les segments de données
0010 UNH, En-tête de message
Segment de service débutant et identifiant de façon unique un message.
Le code du type de message pour le message Authentification et accusé de réception est AUTACK.
L’élément de données « Identification de la sous-fonction du type de message » doit être utilisé pour
indiquer si le message AUTACK doit remplir la fonction du message AUTACK d’authentification, d’accusé de
réception ou de refus d’accusé réception.
NOTE Les messages conformes à ce document doivent contenir les données suivantes dans la composite S009 du
segment UNH.
Elément de Données 0065 AUTACK
0052 4
0054 1
0051 UN
0020 Groupe de segments 1: USH-USA-SG2 (groupe d’en-tête de sécurité)
Groupe de segments identifiant le service de sécurité et les mécanismes de sécurité appliqués et contenant
les données nécessaires à l’exécution des calculs de validation (comme défini dans la Partie 5 de
l’ISO 9735). Ce groupe de segments doit indiquer le service et le (les) algorithme(s) appliqué(s) au message
AUTACK ou à la structure EDIFACT référencée.
Chaque groupe d’en-tête de sécurité doit être reliéà un groupe de fin de sécurité et certains peuvent être,
de surcroît, reliés aux segments USY.
0030 USH, En-tête de sécurité
Segment indiquant un service de sécurité appliqué au message/paquet précisé dans ce segment ou à la
structure EDIFACT référencée(commedéfini dans la Partie 5 de l’ISO 9735).
L’élément de données de service de la sécurité doit indiquer la fonction de sécurité appliquéeaumessage
AUTACK ou à la structure EDIFACT référencée:
� services de sécurité:l’authentification de l’origine et la non-répudiation d’origine du message ne doivent
être utilisés que pour le message AUTACK lui-même.
� services de sécurité:l’intégrité de la structure EDIFACT référencée, l’authentification et la non-
répudiation de la structure EDIFACT référencéenedoivent être utilisées par l’émetteur que pour
sécuriser les structures EDIFACT référencées du message AUTACK.
4 © ISO 1999 – Tous droits réservés
� services de sécurité:l’authentification de la réception et la non-répudiation de la réception ne doivent
être utilisées par le récepteur de structures EDIFACT sécurisées que pour sécuriser l’accusé de
réception.
Le domaine d’application du service de sécurité doit être précisé,comme défini dans la Partie 5 de
l’ISO 9735. Dans un message AUTACK, quatre domaines d’application peuvent exister :
� les deux premiers sont tels que définisdanslasection5delaPartie5 de l’ISO 9735.
� le troisième comprend l’ensemble de la structure EDIFACT, dans lequel le domaine d’application de la
sécurité commence à partir du premier caractère du message, paquet, groupe ou échange (à savoir un
« U ») et se termine au dernier caractère compris du message, paquet, groupe ou échange.
� le quatrième est défini par l’utilisateur, l’application de la sécurité dans ce domaine étant définie en
accord entre l’émetteur et le récepteur.
0040 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 (comme défini dans la Partie 5 de l’ISO 9735).
0050 Groupe de segments 2: USC-USA-USR (groupe du certificat)
Groupe de segments contenant les données nécessaires à la validation des méthodes de sécurité
appliquées au message/paquet, lorsque des algorithmes asymétriques sont utilisés(comme défini dans la
Partie5del’ISO 9735).
0060 USC, Certificat
Segment contenant, par exemple, l’identité du propriétaire du certificat et identifiant l’autorité de certification
qui a produit le certificat (comme défini dans la Partie 5 de l’ISO 9735).
0070 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 (comme défini dans la Partie 5 de l’ISO 9735).
0080 USR, Résultat de la sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au certificat par l’autorité de certification
(comme défini dans la Partie 5 de l’ISO 9735).
0090 USB, Identification des données sécurisées
Ce segment doit contenir l’identification de l’émetteur de l’échange et du destinataire de l’échange, un
horodatage de sécurité associé du message AUTACK et doit indiquer si un accusé de réception sécurisé
émanant du destinataire de ce même message est requis ou non. Dans l’affirmative, l’émetteur du message
doit s’attendre à ce qu’un message d’accusé de réception AUTACK lui soit retourné par le destinataire du
message.
L’émetteur de l’échange et le destinataire de l’échange doivent faire référence, dans le segment USB, à
l’émetteur et au destinataire de l’échange dans lequel le message AUTACK est présent, afin de sécuriser
ces informations.
0100 Groupe de segments 3: USX-USY
Ce groupe de segments doit servir à identifier un intervenant impliqué dans le processus de sécurité et à
donner les informations concernant la sécurité de la structure EDIFACT référencée.
© ISO 1999 – Tous droits réservés 5
0110 USX, Références de la sécurité
Ce segment doit contenir les références renvoyant à l’intervenant impliqué dans le processus de sécurité.
L’élément de données composite «Date et heure de la sécurité» peut contenir la date et l’heure initiales de la
production de la structure EDIFACT référencée.
Si l’élément de données 0020 est présent et qu’aucun des éléments: 0048, 0062 et 0800 ne le sont,
l’ensemble de l’échange est référencé.
Si les éléments de données 0020 et 0048 sont présents et aucun des éléments: 0062 et 0800 ne le sont, le
groupe est référencé.
0120 USY, Sécurité sur les références
Segment contenant un lien à un groupe d’en-tête de sécurité et le résultat des services de sécurité appliqués
à la structure EDIFACT référencée comme précisé dans le groupe d’en-tête de sécurité relié.
Lorsque les structures EDIFACT référencées sont sécurisées par le même servicedesécurité,avec les
mêmes paramètres de sécurité associés, de nombreux segments USY peuvent être reliésaumême groupe
d’en-tête de sécurité. Dans ce cas, la valeur du lien entre le groupe d’en-tête de sécurité et les segments
USY associésdoit être la même. Lorsque le message AUTACK est utilisé pour assurer la fonction d’accusé
de réception, le groupe d’en-tête de sécurité correspondant doit être soit l’un de la structure EDIFACT
référencée, soit l’un d’un message AUTACK utilisé pour indiquer la structure EDIFACT référencéeavec la
fonction d’authentification.
Dans un segment USY, l’élément de données 0534 doit être identique à la valeur de cet élément 0534
contenu dans le segment USH correspondant
� du message AUTACK courant, si la fonction d’authentification est utilisée (services de sécurité:
authenticité de l’originedelastructure EDIFACT référencée, intégrité de la structure EDIFACT
référencée ou non-répudiation de l’originedelastructure EDIFACT référencée);
� de la structure EDIFACT référencéeelle-même ou d’un message AUTACK fournissant la structure
EDIFACT référencée avec la fonction d’authentification, si la fonction d’accusé de réception est utilisée
(services de sécurité:non-répudiation de réception ou authentification de réception).
0130 Groupes de segments 4: UST-USR (groupe de fin de sécurité)
Groupe de segments contenant un lien avec le groupe de segments d’en-tête et le résultat des fonctions de
sécurité appliquées au message/paquet (comme défini dans la Partie 5 de l’ISO 9735).
Le segment USR peut êtreomis sile groupedefin de sécurité est reliéà un groupe d’en-tête de sécurité
associéà une structure EDIFACT référencée. Dans ce cas, les résultats correspondants de la fonction de
sécurité doivent se trouver dans les segments USY qui sont liés au groupe d’en-tête de sécurité approprié.
0140 UST, Fin de sécurité
Segment établissant un lien entre le groupe de segments d’en-tête et de fin de sécurité et indiquant le
nombre de segments de sécurité contenant ces groupes (comme défini dans la Partie 5 de l’ISO 9735).
0150 USR, Résultat de la sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au message/paquet comme défini dans
le groupe d’en-tête de sécurité relié (comme défini dans la Partie 5 de l’ISO 9735). Dans ce segment, le
résultat de la sécurité doit être appliqué au message AUTACK lui-même.
6 © ISO 1999 – Tous droits réservés
0160 UNT, Fin du message
Segment de service terminant un message, indiquant le nombre total de segments dans le message et le
numéro de référence de contrôle du message.
5.4.2 Structure du message
5.4.2.1 Table des segments
POS Etiquette Nom S R Notes
0010 UNH En-tête de message M 1
0020 ---- Groupe de segments 1--------- M 99 -------+
0030 USH En-tête de sécurité M 1 |
0040 USA Algorithme de sécurité C 3 |
|
0050 ----- Groupe de segments 2--------- C 2 ----+ |
0060 USC Certificat M 1 | |
0070 USA Algorithme de sécurité C 3 | |
0080 USR Résultat de la sécurité C 1 ----+--+
0090 USB Identification des données M1
sécurisées
0100 ----- Groupe de segments 3--------- M 9999 ----+
0110 USX Références de la sécurité M 1 |
0120 USY Sécurité sur les références M 9 ----+
0130 ----- Groupe de segments 4--------- M 99 ----+
0140 UST Fin de sécurité M 1 |
0150 USR Résultat de la sécurité C 1 ----+
0160 UNT Fin de message M 1
NOTE Le corps du message AUTACK comprend le segment UNB et le groupe de segments 3.
© ISO 1999 – Tous droits réservés 7
Annexe A
(normative)
Addendum —à ajouter à l’annexe C de la Partie 1 une fois approuvée —
Répertoires syntaxiques de service (segments, éléments de données
composites et éléments de données simples)
A.1 Répertoire des segments
A.1.1 Légende de la spécification d’un segment
Fonction Fonction du segment
POS Numéro séquentiel de la position d’un élément de données autonome ou d’un élément de données
composite de la table des segments
Etiquette Les étiquettes de tous les segments de service contenus dans le répertoire des segments
commencent par la lettre « U ». Les étiquettes de tous les éléments de données composites de
service commencent par la lettre « S » et les étiquettes de tous les éléments de données simples de
service commencent par le chiffre « 0 »
Nom Nom d’un ELEMENT DE DONNEES COMPOSITE en majuscules
Nom d’un ELEMENT DE DONNEES AUTONOME en majuscules
Nom d’un élément de données constitutif en minuscules
SStatutdel’élément de données autonome ou de l’élément de données composite dans le segment, ou
des éléments constitutifs de l’élément de données composites (où M= Obligatoire etC=
Conditionnel)
R Nombre maximal d’occurrences d’un élément de données autonome ou d’un élément de données
composite dans le segment
Repr. Représentation de la valeur de l’élément de données autonome ou des éléments de données
constitutifs de la composite.
a caractères alphabétiques
n caractères numériques
an caractères alphanumériques
a3 3 caractères alphabétiques à longueur fixe
n3 3 caractères numériques à longueur fixe
an3 3 caractères alphanumériques à longueur fixe
a.3 jusqu’à 3 caractères alphabétiques
n.3 jusqu’à 3 caractères numériques
an.3 jusqu’à 3 caractères alphanumériques
A.1.2 Identifiants des notes de dépendance
Code Nom
D1 Une et seulement une
D2 Toutes ou aucune
8 © ISO 1999 – Tous droits réservés
D3 Une ou plusieurs
D4 Une ou aucune
D5 Si la première, alors toutes
D6 Si la première, alors une autre au moins
D7 Si la première, alors aucune des autres
Voir à l’article 11.5 de l’ISO 9735-1:1998, la définition des identifiants des notes de dépendance.
A.1.3 Index des segments par étiquette
Etiquette Nom
UNH En-tête de message
UNT Findemessage
USA Algorithme de sécurité
USB Identification des données sécurisées
USC Certificat
USH En-tête de sécurité
USR Résultat de la sécurité
UST Fin de sécurité
USX Références de la sécurité
USY Sécurité sur les références
A.1.4 Index des segments par nom
Etiquette Nom
USC Certificat
UNH En-tête de message
UNT Findemessage
USB Identification des données sécurisées
USA Algorithme de sécurité
USH En-tête de sécurité
USY Sécurité sur les références
USX Références de la sécurité
USR Résultat de la sécurité
UST Fin de sécurité
A.1.5 Spécifications des segments
NOTE Seuls les segments non définis dans les autres parties de l’ISO 9735 figurent ici.
---------------------------------------------------------------------------
USB IDENTIFICATION DES DONNEES SECURISEES
Fonction : Contenir les informations détaillées se rapportant au
message AUTACK.
POS ETIQUETTE Nom S R Repr. Notes
010 503 TYPE DE REPONSE, EN CODE M 1 an.3
020 S501 DATE ET HEURE DE LA SECURITE C 1
0517 Qualifiant de la date et de l’heure M an.3
0338 Date de l’événement C n.8
© ISO 1999 – Tous droits réservés 9
0314 Heure de l’événement C an.15
0336 Décalage horaire C n4
030 S002 EMETTEUR DE L’ECHANGE M 1
0004 Identification de l’émetteur de l’échange M an.35
0007 Qualifiant du code d’identification C an.4
0008 Identification interne de l’émetteur
de l’échange C an.35
0042 Identification secondaire interne de
l’émetteur de l’échange C an.35
040 S003 DESTINATAIRE DE L’ECHANGE M 1
0010 Identification du destinataire de
l’échange M an.35
0007 Qualifiant du code d’identification C an.4
0014 Identification interne du destinataire
de l’échange C an.35
0046 Identification secondaire interne du
destinataire de l’échange C an.35
---------------------------------------------------------------------------
USX REFERENCES SUR LA SECURITE
Fonction : Faire référence à la structure EDIFACT sécuriséeet à la date et
à l’heure s’y rapportant.
POS Etiquette Nom S R Repr. Notes
010 0020 REFERENCE DU CONTRÔLE DE L’ECHANGE M 1 an.14
020 S002 EMETTEUR DE L’ECHANGE C 1
0004 Identification de l’émetteur de
l’échange M an.35
0007 Qualifiant du code d’identification C an.4
0008 Identification interne de l’émetteur C an.35
0042 Identification interne secondaire de
l’émetteur de l’échange C an.35
030 S003 DESTINATAIRE DE L’ECHANGE C 1
0010 Identification du destinataire de
l’échange M an.35
0007 Qualifiant du code d’identification C an.4
0014 Identification interne du destinataire
de l’échange C an.35
0046 Identification secondaire interne du
destinataire C an.35
040 0048 NUMERO DE REFERENCE DU GROUPE C 1 an.14 1, 3
050 S006 IDENTIFICATION DE L’EMETTEUR DE
L’APPLICATION C 1 1
0040 Identification de l’émetteur de
l’application M an.35
0007 Qualifiant du code d’identification C an.4
10 © ISO 1999 – Tous droits réservés
060 S007 IDENTIFICATION DU DESTINATAIRE DE
L’APPLICATION C 1 3
0044 Identification du destinataire de
l’application M an.35
0007 Qualifiant du code d’identification C an.4
070 0062 NUMERO DE REFERENCE DU MESSAGE C 1 an.14 2,4
080 S009 IDENTIFIANT DU MESSAGE C 1 4
0065 Type du message M an.6
0052 Numéro de version du message M an.3
0054 Numéro de publication du message M an.3
0051 Agence de contrôle, en code M an.3
0057 Code attribué par l’association C an.6
0110 Numéro de version du répertoire de la
liste des codes C an.6
0113 Identification de la fonction secondaire
du message C an.6
090 0800 NUMERO DE REFERENCE DU PAQUET C 1 an.14 2
100 S501 DATE ET HEURE DE LA SECURITE C 1
0517 Qualifiant de la date et de l’heure M an.3
0338 Date de l’événement C n.8
0314 Heure de l’événement C an.15
0336 Décalage horaire C n4
NOTES DE DEPENDANCE :
1. D5 (050, 040) Si la première, alors toutes
2. D1 (070, 090) Une et seulement une
3. D5 (060, 040) Si la première, alors toutes
4. D5 (080, 070) Si la première, alors toutes
---------------------------------------------------------------------------
USY SECURITE SUR LES REFERENCES
Fonction : Identifier l’en-tête applicable et contenir le résultat de
sécurité et/ou indiquer la cause du rejet de sécurité de la
valeur à laquelle il est fait référence.
POS Etiquette Nom S R Repr. Notes
010 0534 NUMERO DE REFERENCE DE LA SECURITE M 1 an.14
020 S508 RESULTAT DE LA VALIDATION C 2 1
0563 Qualifiant de la valeur de la validation M an.3
0560 Valeur de la validation C an.512
030 0571 ERREUR DE SECURITE, EN CODE C 1 an.3 1
NOTES :
1. D3 (020, 030) Une ou plusieurs
---------------------------------------------------------------------------
© ISO 1999 – Tous droits réservés 11
A.2 Répertoire des éléments de données composites
Aucun élément de données composite n’est défini.
A.3 Répertoire des éléments de données simples
A.3.1 Légende de la spécification des éléments de données simples
Les étiquettes de tous les éléments de données simples contenus dans le répertoire des éléments de données
simples commencent par le chiffre «0».
Nom Nom d’un élément de données simple
Desc. Description de l’élément de données simple
Repr. Représentation de la valeur de l’élément de données simple
a caractères alphabétiques
n caractères numériques
an caractères alphanumériques
a3 3 caractères alphabétiques
n3 3 caractères numériques à longueur fixe
an3 3 caractères alphanumériques à longueur fixe
a.3 jusqu’à 3 caractères alphabétiques
n.3 jusqu’à 3 caractères numériques
an.3 jusqu’à 3 caractères alphanumériques
NOTES Numéro de(s) note(s) des éléments de données simples.
A.3.2 Index des éléments de données simples par étiquette
Etiquette Nom
0020 Référence de contrôle de l’échange
0048 Numéro de référence du groupe
0062 Numéro de référence du message
0503 Type de réponse, en code
0534 Numéro de référencedelasécurité
0571 Erreur de sécurité, en code
0800 Numéro de référence du paquet
A.3.3 Index des éléments de données simples par nom
Etiquette Nom
0048 Numéro de référence du groupe
0020 Référence de contrôle de l’échange
0062 Numéro de référence du message
0800 Numéro de référence du paquet
0503 Type de réponse, en code
0571 Erreur de sécurité, en code
0534 Numéro de référencedelasécurité
A.3.4 Spécifications des éléments de données simples
NOTE Seuls les éléments de données simples non définis dans d’autres parties de l’ISO 9735 figurent ici.
12 © ISO 1999 – Tous droits réservés
---------------------------------------------------------------------------
0571 ERREUR DE SECURITE, EN CODE
Desc.: Identifie l’erreur de sécurité entraînant le rejet de la
structure EDIFACT
Repr.: an.3
Note 1: Cet élément doit indiquer l’erreur de sécurité rencontrée.
Les erreurs peuvent être la cause de l’absence d’accusé de
réception faisant suite à une demande d’accusé de réception
sécurisé,oucet élément peut être émis à l’initiative du
récepteur d’un message AUTACK ou d’une structure EDIFACT qui
contient une erreur.
---------------------------------------------------------------------------
© ISO 1999 – Tous droits réservés 13
Annexe B
(informative)
Répertoire des codes de service
Le répertoire des codes de service maintenu par la CEE/ONU fait partie du Répertoire d’échange de données
commerciales des Nations Unies. De ce fait, il n’est pas reproduit dans la présente partie de l’ISO 9735. Il convient
d’utiliser la plus récente version du répertoire des codes de service pour référencer les valeurs des codes des
éléments de données en code du répertoire des éléments de données simples (voir l’annexe C de la présente
partie). Le Répertoire d’échange de données commerciales est tenu à jour et publiéà intervalles réguliers.
14 © ISO 1999 – Tous droits réservés
Annexe C
(informative)
Exemples de messages AUTACK
Trois exemples sont donnés ici pour illustrer différentes applications du message AUTACK.
Le premier montre la façon d’utiliser un message AUTACK pour sécuriser un message précédemment émis, afin
d’assurer le service de sécurité de non-répudiation de l’origine. Un message d’accusé de réception AUTACK est
requis.
Le deuxième exemple montre la façon dont un message AUTACK peut sécuriser deux messages grâce à
différents services de sécurité:lanon-répudiation de l’origine appliquée à un message, l’authentification de l’origine
de message appliquée à un autre.
Le troisième exemple illustre l’utilisation du message AUTACK en tant qu’accusé de réception sécurisé. Il illustre le
message d’accusé de réception AUTACK requis par le message AUTACK du premier exemple.
C.1 Exemple 1: Service de non-répudiation de l’origine assuré par un message AUTACK
C.1.1 Contexte de l’exemple
La banque A souhaite faire appliquer par M. Smith la non-répudiation de l’origine sur les ordres de paiement de la
Société A lorsque ces ordres dépassent un certain montant.
L’accord d’échange entre les partenaires stipule que le service de sécurité relatif à la non-répudiation de l’origine
requis par la Banque A soit assuré, pour les ordres de paiement, par M. Smith de la Société A, par une signature
numérique.
Les deux partenaires conviennent de calculer cette signature numérique à l’aide de l’algorithme RSA (algorithme
asymétrique) de 512 bits sur une valeur de hachage calculée par l’algorithme MD5.
Le certificat identifiant la clé publique de M. Smith est émis par une autorité en laquelle les deux partenaires ont
confiance, l’émetteur du certificat.
Dans ces conditions, étant donné que la signature numérique du message PAYORD est intégrée au message
AUTACK, ce dernier n’a pas besoin d’être signé.
Le message PAYORD sécurisé par le message AUTACK est le troisième message du premier échange transmis
par M. Smith à la Banque A. Il a été produit en 1996.01.15 à 10:00:00.
Le message AUTACK lui-même est le cinquième message de l’échange et il a été produit en 1996.01.15 à
10:05:32.
Les segments de sécurité présents sont les suivants:
� le segment USH pour indiquer le service de sécurité appliqué au message PAYORD.
� les segments USC-USA-USA-USA-USR, le certificat de M. Smith.
� le segment USB.
� les segments USX-USY comportant les références et les résultats delasécurité (pour le message PAYORD).
© ISO 1999 – Tous droits réservés 15
� le segment UST, sans le segment USR, référençant le segment USH.
C.1.2 Informations détaillées sur la sécurité
EN-TETE DE SECURITE
SERVICE DE SECURITE, EN CODE Non-répudiation de l’origine
NUMERO DE REFERENCE DE LA SECURITE La référence de cet en-tête est 1
TYPE DE REPONSE Accusé de réception requis
FONCTION DU FILTRE Toutes les valeurs binaires (signatures) sont filtrées par un filtre
hexadécimal
CODAGE D’ORIGINE DU JEU DE CARACTERES Le message a été codé en 8 bits ASCII lorsque sa signature a été
générée.
CERTIFICAT Certificat de M. SMITH
REFERENCE DU CERTIFICAT Ce certificat est référencé par l’AUTORITE: 00000001.
INFORMATIONS DETAILLES SUR L’IDENTIFICATION
DE LA SECURITE
Propriétaireducertificat M. SMITH de la Société A.
INFORMATIONS DETAILLEES SUR
L’IDENTIFICATION DE LA SECURITE
Emetteur du certificat Le certificat de M. SMITH a été produit par une Autorité de
certification désignée: AUTORITE.
Nom delaclé La clé publique de l’AUTORITE utilisée pour produire le certificat
de M. SMITH est PK1.
VERSION DE SYNTAXE DU CERTIFICAT Version du certificat du répertoire des segments de service
EDIFACT/ONU.
FONCTION DU FILTRE Toutes les valeurs binaires (clés et signatures numériques) sont
filtrées par un filtre hexadécimal.
CODAGE D’ORIGINE DU JEU DE CARACTERES Les justificatifs du certificat ont été codés en 8 bits ASCII lorsque le
certificat a été produit.
CARACTERE DE SERVICE POUR LA SIGNATURE Caractère de service utilisé lorsque la signature a été calculée.
Caractère de service pour le qualifiant de la signature Le caractère de service est le caractère de findesegment.
Caractère de service pour la signature Valeur « ' » (apostrophe).
CARACTERE DE SERVICE POUR LA SIGNATURE Caractère de service utilisé lorsque la signature a été calculée.
Caractère de service pour le qualifiant de la signature Le caractère est le séparateur de l’élément de données.
Caractère pour la signature Valeur « + » (signe plus).
CARACTERE DE SERVICE POUR LA SIGNATURE Caractère de service utilisé lorsque la signature a été calculée.
Caractère pour le qualifiant de la signature Le caractère de service est le séparateur de l’élément de données
constitutif.
Caractère pour la signature Valeur «: » (deux points).
CARACTERE DE SERVICE POUR LA SIGNATURE Caractère de service utilisé lorsque la signature a été calculée.
Caractère pour le qualifiant de la signature Le caractère de service est le séparateur de répétition.
Caractère pour la signature Valeur « * » (astérisque).
CARACTERE DE SERVICE POUR LA SIGNATURE Caractère de service utilisé lorsque la signature a été calculée.
Caractère pour le qualifiant de la signature Le caractère de service est le caractère suspensif.
Caractère pour la signature Valeur « ? » (point d’interrogation).
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...