ISO 9735-9:1999

Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 9: Security key and certificate management message (message type- KEYMAN)

É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 9: Message Gestion de clés et de certificats de sécurité (type de message KEYMAN)

General Information

• Status: Withdrawn
• Publication Date: 24-Mar-1999
• Withdrawal Date: 24-Mar-1999
• ICS: 35.240.60 - IT applications in transport
• ICS: 35.240.63 - IT applications in trade
• Technical Committee: ISO/TC 154 - Processes, data elements and documents in commerce, industry and administration
• Drafting Committee: ISO/TC 154 - Processes, data elements and documents in commerce, industry and administration
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 01-Aug-2002
• Completion Date: 13-Dec-2025

Relations

• Revised: OSIST ISO 9735-9:2004 - Electronic data interchange for administration, commerce and transport (EDIFACT) -- Application level syntax rules (Syntax version number: 4, Syntax release number: 1) -- Part 9: Security key and certificate management message (message type- KEYMAN)
• Effective Date: 12-May-2008
• Revised: PSIST ISO 9735:1996 - Electronic data interchange for administration, commerce and transport (EDIFACT) -- Application level syntax rules
• Effective Date: 12-May-2008
• Revised: ISO 9735-9:2002 - Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 9: Security key and certificate management message (message type- KEYMAN)
• Effective Date: 15-Apr-2008
• Revises: ISO 9735:1988/Amd 1:1992 - Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules - Amendment 1
• Effective Date: 15-Apr-2008
• Revises: ISO 9735:1988 - Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 9735-9
First edition
1999-04-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Application level syntax rules
(Syntax version number: 4) —
Part 9:
Security key and certificate management
message (message type — KEYMAN)
É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 9: Clé de sécurité et message de gestion de certificat (type de
message-KEYMAN)
A
Reference number
Contents Page
1 Scope 1
2 Conformance 1
3 Normative references 1
4 Definitions 2
5 Rules for the use of security key and certificate management
message 2
Annex A: Definitions 6
Annex B: Syntax service directories (segments, composite data
elements and simple data elements) 7
Annex C: KEYMAN functions 12
Annex D: Security techniques to be applied to KEYMAN
messages 16
Annex E: Use of segment groups in KEYMAN messages 17
Annex F: A model for key management 19
Annex G: Syntax service code directory 21
Annex H: Key and certificate management examples 22
©  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 [e-mail]
Printed in Switzerland
ii
©
ISO ISO 9735-9: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
Documents and data elements in
Technical Committee ISO/TC 154,
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:
Syntax version number: 1
ISO 9735:1988 —
Syntax version
ISO 9735:1988 (amended and reprinted in 1990) —
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.
Annexes A and B form an integral part of this part of ISO 9735. Annexes C
to H are for information only.
iv
©
ISO ISO 9735-9: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 batch 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 managing security keys and certificates.
v
©
INTERNATIONAL STANDARD  ISO ISO 9735-9:1999(E)
Electronic data interchange for administration, commerce and
transport (EDIFACT) — Application level syntax rules
(Syntax version number: 4)
Part 9:
Security key and certificate management message
(message type - KEYMAN)
1 Scope
This part of ISO 9735 for batch EDIFACT security defines the security key and certificate management message
KEYMAN.
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.
1)
Information technology — Open Systems Interconnection — The Directory: Authentication
ISO/IEC 9594-8:— ,
framework. [ITU-T Recommendation X.509 (1997)]
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.
__________
1)  To be published. (Revision of ISO/IEC 9594-8:1995)
©
ISO
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-5:1998,
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:1998, annex A apply.
5 Rules for the use of security key and certificate management message
5.1 Functional definition
KEYMAN is a message providing for security key and certificate management. A key may be a secret key used with
symmetric algorithms, or a public or private key used with asymmetric algorithms.
5.2 Field of application
The security key and certificate management message (KEYMAN) 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 message may be used to request or deliver security keys, certificates, or certification paths (this includes
requesting other key and certificate management actions, for example renewing, replacing or revoking certificates,
and delivering other information, such as certificate status), and it may be used to deliver lists of certificates (for
example to indicate which certificates have been revoked). The KEYMAN message may be secured by the use of
security header and trailer segment groups. Security header and trailer segment group structures are defined in
Part 5 of ISO 9735.
A security key and certificate management message can be used to:
a) request actions in relation to keys and certificates
b) deliver keys, certificates, and related information
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 security key and certificate management message is KEYMAN.
Note: messages conforming to this document must contain the following data in segment UNH, composite
S009:
Data element 0065 KEYMAN
0052 4
0054 1
0051 UN
0020 Segment group 1: USE-USX- SG2
A group of segments containing all information necessary to carry key, certificate or certification path
management requests, deliveries and notices.
©
ISO
0030 USE, Security message relation
A segment identifying a relationship to an earlier message, such as a KEYMAN request.
0040 USX, Security references
A segment identifying a link to an earlier message, such as a request. The composite data element
“security date and time” may contain the original generation date and time of the referenced message.
0050 Segment group 2: USF-USA-SG3
A group of segments containing a single key, single certificate, or group of certificates forming a
certification path.
0060 USF, Key management function
A segment identifying the function of the group it triggers, either a request or a delivery. When used
for indicating elements of the certification paths, the certificate sequence number shall indicate the
position of the following certificate within the certification path. It may be used on its own for list
retrieval, with no certificate present. There may be several different USF segments within the same
message, if more than one key or certificate is handled. However, there shall be no mixture of
request functions and delivery functions. The USF segment may also specify the filter function used
for binary fields of the USA segment immediately following this segment.
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). This segment shall be used for
symmetric key requests, discontinuation or delivery. It may also be used for an asymmetric key pair
request.
0080 Segment group 3: USC-USA-USR
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). This
group shall be used in the request or delivery of keys and certificates.
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 desired 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
0090 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). This segment
shall be used for certificate requests such as renewal, or asymmetric key requests such as
discontinuation, and for certificate deliveries.
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). This segment shall be used for
certificate requests such as credentials registration, and for certificate deliveries.
0110 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). This segment shall be used for certificate
validation or certificate deliveries.
©
ISO
0120 Segment group 4: USL-SG5
A group of segments containing lists of certificates or public keys. The group shall be used to group
together certificates of similar status - i.e. which are still valid, or which may be invalid for some reason.
0130 USL, Security list status
A segment identifying valid, revoked, unknown or discontinued items. These items may be certificates
(e.g. valid, revoked) or public keys (e.g. valid or discontinued). There may be several different USL
segments within this message, if the delivery implies more than one list of certificates or public keys. The
different lists may be identified by the list parameters.
0140 Segment group 5: USC-USA-USR
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). This group
shall be used in the delivery of lists of keys or certificates of similar status.
0150 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). This segment shall be used either
in the full certificate using in addition the USA and USR segments, or may alternatively indicate the
certificate reference number or key name, in which case the message shall be signed using security
header and trailer segment groups.
0160 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). If it is required to indicate the algorithms used
with a certificate, this segment shall be used.
0170 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). If it is required to sign a certificate, this segment shall be
used.
0180 UNT, Message trailer
A service segment ending a message, giving the total number of segments and the control reference
number of the message.
5.4.2 Data segment index
TAG Name
UNH Message header
UNT Message trailer
USA Security algorithm
USC Certificate
USE Security message relation
USF Key management function
USL Security list status
USR Security result
USX Security references
©
ISO
5.4.3 Message structure
5.4.3.1 Segment table
POS TAG Name S R
0010 UNH Message header M 1
0020 ----- Segment group 1 ---------------- C 999 --------+
0030 USE Security message relation M 1    |
0040 USX Security references C 1    |
|
0050 ----- Segment group 2 ---------------- M 9 ----+  |
0060 USF Key management function M 1  |  |
0070 USA Security algorithm C 1  |  |
|  |
0080 ----- Segment group 3 ---------------- C 1 -+ |  |
0090 USC Certificate M 1 | |  |
0100 USA Security algorithm C 3 | |  |
0110 USR Security result C 1 --------+
0120 ----- Segment group 4 ---------------- C 99 --------+
0130 USL Security list status M 1    |
|
0140 ----- Segment group 5 ---------------- M 9999 ----+  |
0150 USC Certificate M 1  |  |
0160 USA Security algorithm C 3  |  |
0170 USR Security result C 1 --------+
0180 UNT Message trailer M 1
©
ISO
Annex A
(normative)
Definitions
Addendum — to be added to Part 1 annex A when approved
A.1 certification path: An ordered sequence of certificates of objects in the Directory Information Tree which,
together with the public key of the initial object in the path, can be processed to obtain that of the final
object in the path. (ISO 9594-8) [1]
©
ISO
Annex B
(normative)
Addendum — to be added to Part 1 annex C when approved
Syntax service directories
(segments, composite data elements and simple data elements)
B.1 Segment directory
B.1.1 Legend
Function The function of the segment
POS The sequential position number of the segment or stand-alone data element or composite data element in
the segment table
TAG The tags of 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 SEGMENT in capital letters
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 segment in the structure or of the stand-alone data element or composite data element
in the segment, or of the components in the composite (where M = Mandatory, C = Conditional)
R The maximum number of occurrences of the segment in the structure or of the stand-alone data element
or composite data element in the segment
Repr. Data value representation of the stand-alone data element or component data element 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
B.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
B.1.3 Index of segments by tag
TAG Name
UNH Message header
UNT Message trailer
USA Security algorithm
USC Certificate
USE Security message relation
USF Key management function
USL Security list status
USR Security result
USX Security references
B.1.4 Index of segments by name
TAG Name
USC Certificate
USF Key management function
UNH Message header
UNT Message trailer
USA Security algorithm
USE Security message relation
USX Security references
USR Security result
USL Security list status
B.1.5 Segment specifications
Notes:
1. Only segments which are not included in other parts of ISO 9735 are defined here.
---------------------------------------------------------------------------
USE  SECURITY MESSAGE RELATION
Function: To specify the relation to earlier security messages, such
as response to a particular request, or request for a
particular answer.
Pos  TAG  Name                    S R  Repr.  Notes
010  0565 MESSAGE RELATION, CODED           M 1  an.3
---------------------------------------------------------------------------
USF KEY MANAGEMENT FUNCTION
Function: To specify the type of key management function and the
status of a corresponding key or certificate
Pos  TAG  Name                    S R  Repr.  Notes
010  0579 KEY MANAGEMENT FUNCTION QUALIFIER      M 1  an.3
020  S504 LIST PARAMETER               C 9
0575  List parameter qualifier          M   an.3
0558  List parameter               M   an.70
030  0567 SECURITY STATUS, CODED           C 1  an.3
040  0572 CERTIFICATE SEQUENCE NUMBER         C 1  n.4
©
ISO
050  0505 FILTER FUNCTION, CODED           C 1  an.3
---------------------------------------------------------------------------
USL SECURITY LIST STATUS
Function: To specify the status of security objects, such as keys or
certificates to be delivered in a list, and the
corresponding list parameters.
Pos  TAG  Name                    S R  Repr.  Notes
010  0567 SECURITY STATUS, CODED           M 1  an.3
020  S504 LIST PARAMETER               C 9
0575  List parameter qualifier          M   an.3
0558  List parameter               M   an.70
---------------------------------------------------------------------------
B.2 Composite data element directory
B.2.1 Legend
POS The sequential position number of the component data element in the composite data element
TAG The tags of all service composite data elements contained in the composite data element directory start
with the letter "S", and all service simple data elements start with the figure "0"
Name Name of a component data element in small letters
S The status of the component data element in the composite data element
(where M = Mandatory and C = Conditional)
Repr. Data value representation of the component data element 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
Desc. Description of the composite data element
B.2.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 Part 1 for the definition of the dependency note identifiers.
©
ISO
B.2.3 Index of composite data elements by tag
Notes:
1. Only composite data elements which are not included in other parts of ISO 9735 are included here.
TAG Name
S504 List parameter
B.2.4 Index of composite data elements by name
TAG Name
S504 List parameter
B.2.5 Composite data element specifications
---------------------------------------------------------------------------
S504 LIST PARAMETER
Desc : Identification of a parameter for a list request or delivery
POS  TAG  Name                      S Repr.  Notes
010  0575 List parameter qualifier            M an.3
020  0558 List parameter                 M an.70
---------------------------------------------------------------------------
B.3 Simple data element directory
B.3.1 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)
B.3.2 Index of simple data elements by tag
Notes:
1. Only data elements which are not included in other parts of ISO 9735 are defined here.
©
ISO
TAG Name
0558 List parameter
0565 Message relation, coded
0572 Certificate sequence number
0575 List parameter qualifier
0579 Key management function qualifier
B.3.3 Index of simple data elements by name
TAG Name
0572 Certificate sequence number
0579 Key management function qualifier
0558 List parameter
0575 List parameter qualifier
0565 Message relation, coded
B.3.4 Simple data element specifications
---------------------------------------------------------------------------
0558 LIST PARAMETER
Desc : Specification of the list requested or delivered.
Repr : an.70
---------------------------------------------------------------------------
0565 MESSAGE RELATION, CODED
Desc : Relationship with another message, past or future
Repr : an.3
---------------------------------------------------------------------------
0572 CERTIFICATE SEQUENCE NUMBER
Desc : Specification of a certificate’s position within a certification
path
Repr : n.4
Note 1: Allows certification paths to be ordered by specifying the
ordinal number of the certificate within a certification path.
---------------------------------------------------------------------------
0575 LIST PARAMETER QUALIFIER
Desc : Specification of the type of list parameter.
Repr : an.3
---------------------------------------------------------------------------
0579 KEY MANAGEMENT FUNCTION QUALIFIER
Desc : Specification of the type of key management function
Repr : an.3
---------------------------------------------------------------------------
©
ISO
Annex C
(informative)
KEYMAN functions
This annex describes the different functions provided by KEYMAN. In the following, credentials will just mean
information relating to one particular party, but not the public key, nor timestamps. So a certificate will consist of
• Credentials
•
A public key
• Timestamps
•
A digital signature
Certain functions are considered to be handled out of band, i.e. using a communication channel different from that
normally used. This is the case with communication of the secret key of the user, if he is not responsible for his own
key generation.
C.1 Registration-related key management functions
C.1.1 Registration submission
The purpose is to submit (part of) certificate content for registration.
Although this function typically will be backed up by some secure out of band technique (such as a personal visit, or
a human signature), it may be more efficient for the registration authority (RA, an authority trusted by one or more
users to register users) not to have to re-key the information, but merely to check it. For this reason, this message
itself need not be secured, though integrity checking using the normal header/trailer approach defined in Part 5 of
ISO 9735 may be useful, if further secured out of band.
C.1.2 Asymmetric key pair request
The purpose is to request a trusted party to generate an asymmetric key pair. The subsequent transport of the
secret key must be handled out of band.
C.2 Certification-related key management functions
C.2.1 Certification request
The purpose is to request certification of credentials and public key.
It may be presumed to be merely a request following pr
...

NORME ISO
INTERNATIONALE 9735-9
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 9:
Message Gestion de clés et de certificats
de sécurité (type de message KEYMAN)
Electronic data interchange for administration, commerce and transport
(EDIFACT) — Application level syntax rules (Syntax version number: 4) —
Part 9: Security key and certificate management message (message
type — KEYMAN)
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 [e-mail]
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 Gestion des clés et de certificats de sécurité .2
Annexe A Définitions Addendum—à ajouter à l’annexe A de la Partie 1 une fois approuvée —.7
Annexe B 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 C Fonctions du message KEYMAN .15
Annexe D Techniques de sécuritéà appliquer aux messages KEYMAN .19
Annexe E Utilisation des groupes de segments dans les messages KEYMAN.20
Annexe F Modèle de gestion de clés.22
Annexe G Addendum —à ajouter à l’annexe D de la Partie 1 une fois approuvée — Répertoire des
codes de service syntaxiques.25
AnnexeH Exemplesdegestion declés et de certificats.26
© 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-9 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.
Les annexes A et B constituent des éléments normatifs de la présente partie de l’ISO 9735. Les annexes C à H
sont données uniquement à 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.
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 gérer les cléset les
certificats de sécurité.
vi © ISO 1999 – Tous droits réservés

NORME INTERNATIONALE ISO 9735-9: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 9:
Message Gestion de clésetdecertificats desécurité (type de
message KEYMAN)
1 Domaine d'application
La présente partie de l’ISO 9735 est destinée à la sécurité EDIFACT par lots et définit le message Gestion de clés
et de certificats de sécurité KEYMAN.
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 1999 – Tous droits réservés 1

1)
ISO/CEI 9594-8:— , Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — L’Annuaire:
Cadre d’authentification [Recommandation UIT-T X 509 (1997)].
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-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,
s’appliquent.
5Règles d’utilisation du message Gestion des clés et de certificats de sécurité
5.1 Définition fonctionnelle
KEYMAN est un message assurant la gestion de clés et de certificats de sécurité.Une clé peut être une clé secrète
utilisée avec des algorithmes symétriques ou une clé publique ou privéeutilisée avec des algorithmes
asymétriques.
5.2 Champ d’application
Le message Gestion de clés et de certificats de sécurité (KEYMAN) 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
Ce message peut servir à demander ou à remettre des clésde sécurité, des certificats, ou des chemins de
certification (ce principe couvre la demande d’autres activités portant sur la gestion de clés et de certificats, par
exemple le renouvellement, le remplacement ou la révocation de certificats et la fourniture d’autres informations
telles que le statut d’un certificat). Il peut servir à remettre des listes de certificats (par exemple, indiquer les
certificats qui ont été révoqués). Le message KEYMAN peut être sécuriséà l’aide des groupes de segments d’en-
tête et de findesécurité. Les structures des groupes de segments d’en-tête et de fin de sécurité sont définis dans
la Partie5del’ISO 9735.
Un message de gestion de clés et de certificats de sécurité peut servir à
a) demander des actions concernant des clés et des certificats
b) fournir des clés, des certificats et des informations s’y rapportant.
1) À publier. (Révision de l'ISO/CEI 9594-8:1995)
2 © ISO 1999 – Tous droits réservés

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 Gestion de clés et de certificats de sécurité est KEYMAN.
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 KEYMAN
0052 4
0054 1
0051 UN
0020 Groupe de segments 1: USE-USX-SG2
Groupe de segments contenant toutes les informations nécessaires pour véhiculer les demandes, remises
et avis de clés, de certificats ou de chemins de certification.
0030 USE, relation avec un message de sécurité
Segment identifiant une relation à un message antérieur, telle qu’une demande d’un message KEYMAN.
0040 USX, Références de la sécurité
Segment identifiant un lien avec un message antérieur, tel qu’une demande. L’élément de données
composite «Date et heure de la sécurité» peut contenir la date et l’heure de la production d’origine du
message référencé.
0050 Groupe de segments 2: USF-USA-SG3
Groupe de segments contenant une seule clé, un seul certificat ou groupe de certificats formant un
chemin de certification.
0060 USF, Fonction de gestion de la clé
Segment identifiant la fonction du groupe qu’il déclenche, soit une demande ou une remise. S’il est utilisé
pour indiquer des éléments des chemins de certification, le numéro de séquence du certificat doit indiquer
la position du certificat qui suit dans le chemin de certification. Il peut être utilisé seul pour la restitution de
listes, sans qu’aucun certificat ne soit présent. Plusieurs différents segments USF peuvent se trouver
dans le même message, si plus d’une clé ou d’un certificat est traité. Cependant, les fonctions de
demande et les fonctions de remise ne doivent pas être mélangées. Le segment USF peut également
préciser la fonction du filtre utilisé pour les champs binaires du segment USA qui suit immédiatement ce
segment.
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). Ce segment doit être utilité
pour des demandes, une suspension ou une remise de cléssymétriques. Il peut également servir à
demander une paire de clésasymétriques.
© ISO 1999 – Tous droits réservés 3

0080 Groupe de segments 3: USC-USA-USR
Groupe de segments contenant les dates 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). Ce groupe doit être utilisé dans la demande ou la remise de clés et de certificats.
Ou bien la totalité du groupe de segments du certificat (y compris le segment USR) ou les seuls éléments
de données nécessaires à identifier de façon non ambiguë la paire de clésasymétriques utilisée, doit être
présente dans le segment USC. La présence d’un certificat dans sa totalité peut être évitéesi lecertificat
adéjàétééchangé entre les deux intervenants, ou il peut être extrait d’une base de données.
Si l’on veut faire référence à un certificat non EDIFACT (tel que X.509), la syntaxe et la version du
certificat doivent être identifiées dans l’élément de données 0545 du segment USC. Ces certificats
peuvent être véhiculés dans un paquet EDIFACT.
0090 USC, Certificat
Segment contenant les justificatifs 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). Ce segment doit être utilisé pour des
demandes de certificat concernant un renouvellement ou des demandes de clésasymétriques telles
qu’une suspension ainsi que pour des remises de certificats.
0100 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). Ce segment doit être utilisé
pour des demandes de certificats concernant l’enregistrement de justificatifs et pour des remises de
certificats.
0110 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). Ce segment doit être utilisé pour la validation
des certificats ou les remises de certificats.
0120 Groupe de segments 4: USL-SG5
Groupe de segments contenant les listes de certificats ou de clés publiques. Ce groupe doit être utilisé
pour regrouper des certificats de statut similaire, c’est-à-dire qui sont toujours en cours de validité,ou
peuvent ne plus l’être à cause d’une raison quelconque.
0130 USL, Statut de la liste de sécurité
Segment identifiant des éléments en cours de validité,révoqués, inconnus ou suspendus. Il peut s’agir de
certificats (par exemple, en cours de validité,révoqués) ou de clés publiques (par exemple, en cours de
validité ou interrompues). Ce message peut comporter plusieurs différents segments USL, si la remise
implique plus d’une liste de certificats ou de clés publiques. Ces différentes listes peuvent être identifiées
par les paramètres de la liste.
0140 Groupe de segments 5: USC-USA-USR
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
Partie 5del’ISO 9735). Ce groupe doit être utilisé dans la remise de listes de clés ou de certificats de
statut similaire.
4 © ISO 1999 – Tous droits réservés

0150 USC, Certificat
Segment contenant les justificatifs du propriétaire du certificat et identifiant l’autorité de certification qui a
produit le certificat (comme défini dans la Partie 5). Ce segment doit être utilisé, soit dans la totalité du
certificat, avec, en plus, les segments USA et USR. Il peut aussi indiquer le numéro de référence du
certificat ou le nom de la clé. Dans ce cas le message doit être signé en utilisant les groupes de segments
d’en-tête et de fin de sécurité.
0160 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). S’il est nécessaire d’indiquer
les algorithmes utilisés avec un certificat, ce segment doit être utilisé.
0170 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). S’il est nécessaire de signer un certificat, ce
segment doit être utilisé.
0180 UNT, Fin de 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 Index des segments de données
Etiquette Nom
UNH En-tête de message
UNT Findemessage
USA Algorithme de sécurité
USC Certificat
USE Relation avec un message de sécurité
USF Fonction de gestion de la clé
USL Statutdelalistedesécurité
USR Résultat de la sécurité
USX Références de la sécurité
© ISO 1999 – Tous droits réservés 5

5.4.3 Structure du message
5.4.3.1 Segment table
POS EtiquetteNom S R
0010 UNH En-tête de message M 1
0020 ----- Groupe de segments 1 -------------- C 999 --------+
0030 USE Relation avec un message de sécurité M 1 |
0040 USX Références de la sécurité C 1 |
|
0050 ----- Groupe de segments 2 -------------- M 9 ----+ |
0060 USF Fonction de gestion de la clé M l | |
0070 USA Algorithme de sécurité C 1 | |
||
0080 ----- Groupe de segments 3 -------------- C 1 -+ | |
0090 USC Certificat M 1 | | |
0100 USA Algorithme de sécurité C 3 | | |
0110 USR Résultat de la sécurité C 1 --------+
0120 ----- Groupe de segments 4 -------------- C 99 --------+
0130 USL Statut de la liste de sécurité M 1 |
|
0140 ----- Groupe de segments 5 -------------- M 9999 ----+ |
0150 USC Certificat M 1 | |
0160 USA Algorithme de sécurité C 3 | |
0170 USR Résultat de la sécurité C 1 --------+
0180 UNT Fin de message M 1
6 © ISO 1999 – Tous droits réservés

Annexe A
(normative)
Définitions
Addendum —à ajouter à l’annexe A de la Partie 1 une fois approuvée —
A.1
chemin de certification
séquence ordonnéedecertificats d’objets dans l’Arbre des informations de l’annuaire qui, accompagnéedela clé
publique de l’objet d’origine dans le chemin, peut être traitée pour obtenir celle de l’objet final dans ce chemin.
(ISO 9594-8) [1]
© ISO 1999 – Tous droits réservés 7

Annexe B
(normative)
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)
B.1 Répertoire des segments
B.1.1 Légende de la spécification d’un segment
Fonction Fonction du segment
POS Numéro séquentiel de la position du segment ou d’un élément de données autonome ou d’un élément
de données composite dans 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 segment en majuscules.
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
S Statut du segment dans la structure ou de l’élément de données autonome ou de l’élément de
données composite dans le segment, ou des éléments constitutifs de la composites (où M=
Obligatoire et C = 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 de l’élément de données constitutif
dans 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
8 © ISO 1999 – Tous droits réservés

B.1.2 Identifiants des notes de dépendance
Code Nom
D1 Une et seulement une
D2 Toutes ou aucune
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.
B.1.3 Index des segments par étiquette
Etiquette Nom
UNH En-tête de message
UNT Findemessage
USA Algorithme de sécurité
USC Certificat
USE Relation avec un message de sécurité
USF Fonction de gestion de la clé
USL Statutdelalistedesécurité
USR Résultat de la sécurité
USX Références de la sécurité
B.1.4 Index des segments par nom
Etiquette Nom
USC Certificat
USF Fonction de gestion de la clé
UNH En-tête de message
UNT Findemessage
USA Algorithme de sécurité
USE Relation avec un message de sécurité
USX Références de la sécurité
USL Statutdelalistedesécurité
© ISO 1999 – Tous droits réservés 9

B.1.5 Spécifications des segments
NOTES Seuls les segments non définis dans d’autres parties de l’ISO 9735 figurent ici.
---------------------------------------------------------------------------
USE RELATION AVEC UN MESSAGE DE SECURITE
Fonction : Indiquer la relation à des messages antérieurs de sécurité,
telle qu’une réponse à une demande particulière ou une demande
à une réponse particulière.
Pos Etiquette Nom S R Repr. Notes
010 0565 RELATION A UN MESSAGE, EN CODE M 1 an.3
---------------------------------------------------------------------------
USF FONCTION DE GESTION DE LA CLE
Fonction : indiquer le type de la fonction de gestion de la clé et le
statut d’une clé ou d’un certificat correspondants.
Pos Etiquette Nom S R Repr. Notes
010 0579 QUALIFIANT DE LA FONCTION DE GESTION
DE LA CLE M 1 an.3
020 S504 PARAMETRE DE LA LISTE C 9
0575 Qualifiant du paramètre de la liste M an.3
0558 Paramètre de la liste M an.70
030 0567 STATUT DE LA SECURITE, EN CODE C 1 an.3
040 0572 NUMERO DE SEQUENCE DU CERTIFICAT C 1 n.4
050 0505 FONCTION DU FILTRE, EN CODE C 1 an.3
---------------------------------------------------------------------------
USL STATUT DE LA LISTE DE SECURITE
Fonction : indiquer le statut des objets de sécurité, tels que les
clés ou les certificats à remettre dans une liste, et les
paramètres de la liste correspondante.
Pos Etiquette Nom S R Repr. Notes
010 0567 STATUT DE LA SECURITE, EN CODE M 1 an.3
020 S504 PARAMETRE DE LA LISTE C 9
0575 Qualifiant du paramètre de la liste M an.3
0558 Paramètre de la liste M an.70
---------------------------------------------------------------------------
10 © ISO 1999 – Tous droits réservés

B.2 Répertoire des éléments de données composites
B.2.1 Légende
POS Numéro séquentiel de la position de l’élément de données constitutif dans l’élément de données
composite.
Etiquette Les étiquettes de tous les éléments de données composites de service contenus dans le répertoire
des éléments de données composites commencent par la lettre « S » et tous les éléments de
données simples de service commencent par le chiffre « 0 ».
Nom Nom d’un élément de données constitutif en minuscules.
SStatutdel’élément de données constitutif dans l’élément de données composite (où M=Obligatoireet
C = Conditionnel).
Repr. Représentation de la valeur de l’élément de données constitutif ou des éléments de données
constitutifs de l’élément 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
Desc. Description de l’élément de données composite
B.2.2 Identifiants des notes de dépendance
Code Nom
D1 Une et seulement une
D2 Toutes ou aucune
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, la définition des identifiants des notes de dépendance.
B.2.3 Index des éléments de données composites par étiquette
NOTES Seuls les éléments de données composites non définisdansd’autres parties de l’ISO 9735 figurent ici.
Etiquette Nom
S504 Paramètre de la liste
© ISO 1999 – Tous droits réservés 11

B.2.4 Index des éléments de données composites par nom
Etiquette Nom
S504 Paramètre de la liste
B.2.5 Spécifications des éléments de données composites
---------------------------------------------------------------------------
S504 PARAMETRE DE LA LISTE
Desc. : identification d’un paramètre destinéà une demande ou une remise
de liste
POS Etiquette Nom S Repr. Notes
010 0575 Qualifiant du paramètre de la liste M an.3
020 0558 Paramètre de la liste M an.70
---------------------------------------------------------------------------
B.3 Répertoire des éléments de données simples
B.3.1 Légende
Les étiquettes de tous les éléments de données simples de service 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.
12 © ISO 1999 – Tous droits réservés

B.3.2 Index des éléments de données simples par étiquette
NOTES Seuls les éléments de données simples non définis dans d’autres parties de l'ISO 9735 figurent ici.
Etiquette Nom
0558 Paramètre de la liste
0565 Relation avec un message, en code
0572 Numéro de séquence du certificat
0575 Qualifiant du paramètredelaliste
0579 Qualifiant de la fonction de gestion de la clé
B.3.3 Index des éléments de données simples par nom
Etiquette Nom
0572 Numéro de séquence du certificat
0579 Qualifiant de la fonction de gestion de la clé
0558 Paramètre de la liste
0575 Qualifiant du paramètredelaliste
0565 Relation avec un message, en code
B.3.4 Spécifications des éléments de données simples
---------------------------------------------------------------------------
0558 PARAMETRE DE LA LISTE
Desc. : spécification de la liste demandée ou remise.
Repr. : an.70
---------------------------------------------------------------------------
0565 RELATION AVEC UN MESSAGE, EN CODE
Desc. : relation avec un autre message, antérieur ou ultérieur.
Repr. : an.3
---------------------------------------------------------------------------
0572 NUMERO DE SEQUENCE DU CERTIFICAT
Desc. : spécification de la position d’un certificat dans un chemin
de certification.
Repr. : n.4
Note 1 : permet d’ordonner les chemins de certification en précisant le
numéro d’ordre du certificat au sein d’un chemin de certification.
© ISO 1999 – Tous droits réservés 13

---------------------------------------------------------------------------
0575 QUALIFIANT DU PARAMETRE DE LA LISTE
Desc. : spécification du type du paramètre de la liste.
Repr. : an.3
---------------------------------------------------------------------------
0579 QUALIFIANT DE LA FONCTION DE GESTION DE LA CLE
Desc. : Spécification du type de la fonction de la gestion de la clé
Repr. : an.3
----------------------------------------------------------------------------
14 © ISO 1999 – Tous droits réservés

Annexe C
(informative)
Fonctions du message KEYMAN
Cette annexe décrit les différentes fonctions remplies par le message KEYMAN. Dans le texte qui suit, on entend
par justificatifs les informations se rapportant à un intervenant particulier, mais non la clé publique ni l’horodatage.
Un certificat consistera en
� Justificatifs
� Une clé publique
� L’horodatage
� Une signature numérique
Certaines fonctions sont considérées comme traitées hors bande, c’est-à-dire par l’utilisation d’une voix de
communication qui diffère de la voie habituelle. C’est le cas lors de la communication de la clé secrète de
l’utilisateur si ce dernier n’est pas responsable de la production de sa propre clé.
C.1 Fonctions de gestion de clés se rapportant à l’enregistrement
C.1.1 Soumission à l’enregistrement
L’objectif vise à soumettre à l’enregistrement le contenu (partie) d’un certificat.
Bien que cette fonction soit généralement sauvegardée par une technique hors bande (telle que la visite d’une
personne ou une signature manuscrite), l’autorité d’enregistrement (RA, autoritéà laquelle un ou plusieurs
utilisateurs font confiance pour enregistrer les utilisateurs) peut juger plus efficace de ne pas devoir ressaisir les
informations, mais se limiter purement à les vérifier. De ce fait, ce message lui-même n’a pas besoin d’être
sécurisé. Toutefois la vérification de l’intégrité assuréepar l’utilisation de l’en-tête/fin de sécurité,définie dans la
Partie5del’ISO 9735 peut s’avérer efficace, si elle est sécurisée hors bande par la suite.
C.1.2 Demande de paire de clésasymétriques
L’objectif vise à demander à un tiers deconfiancedeproduireune paire declésasymétriques. L’acheminement
postérieurdelaclé secrète doit être effectué hors bande.
C.2 Fonctions de gestion de clés se rapportant à la certification
C.2.1 Demande de certification
L’objectif vise à demander la certification des justificatifs et de la clé publique.
On peut considérer qu’il s’agit purement d’une demande suivant un transfert préalable hors bande d’informations.
Dans ce cas, la demande même n’entraîne aucun transfert d’informations. Aucune clé enregistrée ne pouvant
encore être disponible, on peut supposer qu’il s’agit d’un message non sécurisé. Si ces informations sont
transmises dans le message, elles nécessiteront une authentification séparée. Si une clé enregistrée existe déjà,
cette possibilité peut être utilisée pourassurerla non-répudiation de l’origine des informations destinées à la
nouvelle clé et au nouveau certificat.
© ISO 1999 – Tous droits réservés 15

Néanmoins, si un utilisateur emploie le message pour acheminer sa clé publique, il devrait lui êtrepossibledela
signer avec la clé secrète correspondante, bien qu’il n’existe encore aucune étiquette de clé secrète. Cette
démarche se rapproche de l’auto-certification et nécessite d’utiliser les groupes de segments d’en-tête et de fin de
sécurité. Pour indiquer que la clé est auto-certifiée, le groupe de segments d’en-tête de sécurité défini dans la
Partie 5del’ISO 9735 doit contenir un certificat émis par l’utilisateur sur sa propre clé.Bienqu’une clé publique
auto-certifiéeneprouvepas à un autre intervenant l’authenticité de son utilisateur, elle prouve à l’autorité de
certification que l’utilisateur est en possession de la clé privée correspondante.
C.2.2 Demande de renouvellement de certificat
L’objectif vise à demander le renouvellement (mise à jour) d’un certificat.
Cette démarche vise àétendre la périodedevalidité de la clé en cours de validité, dont le certificat vient à
échéance. Cette demande doit être signée en utilisant les groupes de segments d’en-tête et de fin de sécurité
EDIFACT décrits dans la Partie 5 de l’ISO 9735, par la clé privée certifiée par le certificat à renouveler.
C.2.3 Demande de remplacement de certificat
L’objectif vise à demander le remplacement d’un certificat courant par un nouveau, comportant une clé publique
différente, aussi bien que de donner des informations complémentaires si besoin. Cette demande doit être signée
conformément à un accord convenu utilisant les groupes d’en-tête et de fin EDIFACT décrits dans la Partie 5 de
l’ISO 9735.
Cette fonction diffère d’une demande de renouvellement en ce que l’ancien certificat est en général révoqué plutôt
qu’il ne vient àéchéance. Un nouveau certificat porte toujours un nouveau numéro de référence de certificat,
tandis qu’un certificat de révocation porte toujours le même numéro de référence que le certificat en cours de
révocation.
C.2.4 Demande de restitution de certificat (chemin)
L’objectif vise à demander la remise d’un certificat existant, d’un certificat en cours de validité ou révoqué ou d’un
certificat de révocation. Cette fonction couvre la situation dans laquelle la réponse contient un chemin de
certification, plutôtqu’un simple certificat car le demandeur ignore en général ces précisions.
Si le numéro de référence du certificat a été précisé,sasécurisation n’est pas nécessaire puisque ces certificats
sont publics.
C.2.5 Remise de certificats
L’objectif vise àremettreuncertificatexistantouuncertificat derévocation avec ou sans demande préalable.
Le transport de la clé publique de l’autorité de certification (CA) est normalement traité hors bande. Toutefois, pour
des raisons de commodité de ressaisie, un message peut être requis, éventuellement sécurisé par les groupes de
segments d’en-tête et de fin de sécurité pour en assurer l’intégrité, accompagné d’une authentification séparée. Si
ce message est disponible, les utilisateurs peuvent être tentésd’ignorer la vérification de la valeur hors bande.
Dans ce cas, la sécurité sera réellement considérablement réduite. Cette fonction peut nécessiter des services de
sécurité, tels que la non-répudiation de l’origine
C.2.6 Demande de statut de certificat
L’objectif vise à demander le statut en cours d’un certificat donné.
C.2.7 Avis de statut de certificat
L’objectif vise à informer le demandeur sur le statut du certificat donné.
16 © ISO 1999 – Tous droits réservés

Les statuts peuvent être: inconnu, en cours de validité ou révoqué. Cet avis peut être remis sans demande
préalable et doit en général être sécurisé par la non-répudiation de l’origine.
C.2.8 Demande de validation de certificat
La demande doit être acheminée à une CA pour la validation d’un certificat existant.
Cette fonction concerne les certificats d’autres domaines de sécurité (c’est-à-dire émis par une autre CA). Dans ce
cas, l’utilisateur peut être incapable d’en établir la validité.
C.2.9 Avis de validation de certificat
Il s’agit de la réponse à une demande de validation de certificat. Il est recommandé d’utiliser la non-répudiation de
l’origine ou d’autres moyens d’authentification à cet effet.
C.3 Fonctions de gestion de clés se rapportant à la révocation
C.3.1 Demande de révocation
L’objectif vise à demander la révocation (modification de statut de valide à non valide) du certificat d’un intervenant,
par exemple, car la clé privéea été compromise, l’utilisateur s’est adresséà une nouvelle CA, le certificat d’origine
a été remplacé,l’utilisation est terminée (par exemple, l’utilisateur a quitté l’entreprise) ou à cause d’un autre motif.
Il est recommandé d’utiliser l’authentification si possible. Cette fonction peut nécessiter une autre voie et couvrir le
cas où l’usager a perdu la clé privée.
C.3.2 Confirmation de révocation
L’objectif vise à confirmer la révocation du certificat demandé.
Il est recommandé de sécuriser cette fonction au moyen de la non-répudiation de l’origine.
C.3.3 Demande de liste de révocation
L’objectif vise à demander toute ou partie de la liste des certificats révoqués.
C.3.4 Remise de liste de révocation
L’objectif vise à informer les intervenants sur la totalité (ou un sous-ensemble précisdelatotalité) des certificats
couramment révoqués dans le domaine de la CA.
Cette fonction ressemble à un avis de statut multiple, mais elle ne s’applique qu’aux certificats révoqués. Alors qu’il
s’avérerait possible de disposer d’une sorte de liste noire séparée, il est préférableden’en avoir qu’une seule et
d‘en identifier le statut. La remise doit être sécurisée par la non-répudiation de l’origine.
C.4 Demande d’alerte
L’objectif vise à demander de mettre en alerte le certificat d’un intervenant.
Ce certificat n’est pas révoqué (aucune demande formulée à la CA) mais les autres utilisateurs sont avertis qu’un
incident peut être survenu au certificat. Cette fonction peut être utilisée si aucun moyen approprié d’authentification
n’est disponible pour sécuriser une demande de révocation, par exemple, une seconde clé valide et un second
certificat.
© ISO 1999 – Tous droits réservés 17

C.5 Chemins de certificat
C.5.1 Remise de chemin de certificat
L’objectif vise à remettre un chemin existant de certification avec ou sans demande préalable.
C.6 Production et transport de cléssymétriques
C.6.1 Demande de cléssymétriques
L’objectif vise à demander la remise de cléssymétriques de données ou d’une clé de chiffrement de clés.
Puisque laremisedeclés implique une relation sécuriséepréalable entre les deux intervenants, l’initiateur doit être
authentifié en utilisant une clé chiffrant une clé (KEK, clé utilisée pour conférer la confidentialitéà une autre), si les
techniques de clés publiques ne sont pas utilisées.
C.6.2 Remise de cléssymétriques
L’objectif vise à remettre des cléssymétriques (avec ou sans demande préalable).
Si seules des techniques symétriques sont utilisées, il convient de supposer que le transfert hors bande d’une KEK
est nécessaire avant le transfert. Le paramètre de l’algorithme dans le segment USA véhiculera alors la clé
chiffrée.
C.7 Suspension de clés
C.7.1 Demande de suspension de cléssymétriques (asymétriques)
L’objectif vise à demander l’interruption d’une clé symétrique ou asymétrique existante (si les certificats ne sont
pas utilisés), par exemple, car la clé a été compromise, la clé d’origine a été remplacée, son utilisation est terminée
(par exemple, l’utilisateur a quitté l’entreprise, ou à cause d’un autre motif). Il est recommandé de sécuriser cette
fonction en utilisant des clés existantes pour l’authentification.
C.7.2 Accusé de réception de suspension
L’objectif vise à confirmer qu’une (des) clé(s) spécifiée(s) a (ont) été suspendue(s).
REMARQUE Fonctions qui ne peuvent être couvertes par un message KEYMAN :
� lesfonctionsindépendantes de l’horodatage (nécessitant un message séparé, par exemple, AUTACK),
� l’accusé de réception et l’avis d’erreur se rapportant aux messages KEYMAN reçus nécessiteront l’utilisation
d’autres messages, par exemple, AUTACK ou CONTRL.
18 © ISO 1999 – Tous droits réservés

Annexe D
(informative)
Techniques de sécuritéà appliquer aux messages KEYMAN
Cette annexe propose le niveau minimal et maximal d’en-tête/fin de sécurité (H/T) décrits dans la Partie 5 de
l’ISO 9735, à utiliser avec chaque fonction de KEYMAN.
Sécurité H/T
Fonction Observations
MIN MAX
Soumission à l’enregistrement INT AUT Hors bande
Demandedepaire de clésasymétriques
Demande de certification NRO AUT Hors bande
Demande de renouvellement de certificat NRO
Demande de remplacement de certificat NRO
Demande de restitution de certificat (chemin) NRO
Remise de certificat
Demande de statut de certificat NRO
Avis de statut de certific
...