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)

This part of ISO 9735 for batch EDIFACT security defines the security key and certificate management message 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, numéro d'édition de syntaxe: 1) -- Partie 9: Clé de sécurité et message de gestion de certificat (type de message KEYMAN)

Elektronska menjava podatkov (-računalniška-) v administraciji (upravi), trgovini in transportu (prevozništvu) EDIFACT - Pravila sintakse za uporabniški nivo (izvedbena oblika sintakse: 4, zaporedna št. izdaje 1) Deveti del: varnostni ključ in certifikat upravljalskega (management) sporočila (Vrsta sporočila KEYMAN)

General Information

• Status: Not Published
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: EDI - Documents and data elements in administration , commerce and industry
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 01-May-2004
• Due Date: 01-May-2004
• Completion Date: 01-May-2004
• Ref Project: 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)

Relations

• Revised: 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)
• Effective Date: 12-May-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 9735-9
Second edition
2002-07-01


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)
É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, numéro d'édition de syntaxe: 1) —
Partie 9: Clé de sécurité et message de gestion de certificat (type de
message KEYMAN)




Reference number
ISO 9735-9:2002(E)
©
 ISO 2002

---------------------- Page: 1 ----------------------
ISO 9735-9:2002(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.


©  ISO 2002
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 either ISO at the address below or ISO's member body
in the country of the requester.
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
Printed in Switzerland

ii © ISO 2002 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 9735-9:2002(E)
Contents Page
Foreword.iv
Introduction.vi
1 Scope .1
2 Conformance.1
3 Normative references.2
4 Terms and definitions .2
5 Rules for the use of security key and certificate management message.2
Annex A (informative) KEYMAN functions .7
Annex B (informative) Security techniques to be applied to KEYMAN messages.11
Annex C (informative) Use of segment groups in KEYMAN messages .12
Annex D (informative) A model for key management.14
Annex E (informative) Key and certificate management examples .16

© ISO 2002 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 9735-9:2002(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 collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of technical committees is to prepare International Standards. 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.
Attention is drawn to the possibility that some of the elements of this part of ISO 9735 may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 9735-9 was prepared by Technical Committee ISO/TC 154, Processes, data elements and documents in
commerce, industry and administration in collaboration with UN/CEFACT through the Joint Syntax Working Group
(JSWG).
This second edition cancels and replaces the first edition (ISO 9735-9:1999). However ISO 9735:1988 and its
Amendment 1:1992 are provisionally retained for the reasons given in clause 2.
Furthermore, for maintenance reasons the Syntax service directories have been removed from this and all other
parts of the ISO 9735 series. They are now consolidated in a new part, ISO 9735-10.
At the time of publication of ISO 9735-1:1998, ISO 9735-10 had been allocated as a part for “Security rules for
interactive EDI”. This was subsequently withdrawn because of lack of user support, and as a result, all relevant
references to the title “Security rules for interactive EDI” were removed in this second edition of ISO 9735-9.
Definitions from all parts of the ISO 9735 series have been consolidated and included in ISO 9735-1.
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, Syntax release
number: 1):
— Part 1: Syntax rules common to all 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)
— Part 6: Secure authentication and acknowledgement message (message type — AUTACK)
— Part 7: Security rules for batch EDI (confidentiality)
— Part 8: Associated data in EDI
iv © ISO 2002 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 9735-9:2002(E)
— Part 9: Security key and certificate management message (message type — KEYMAN)
— Part 10: Syntax service directories
Further parts may be added in the future.
Annexes A to E of this part of ISO 9735 are for information only.
© ISO 2002 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 9735-9:2002(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.
vi © ISO 2002 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 9735-9:2002(E)

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)
1 Scope
This part of ISO 9735 for batch EDIFACT security defines the security key and certificate management message
KEYMAN.
2 Conformance
Whereas this part shall use a version number of “4” in the mandatory data element 0002 (Syntax version number),
and shall use a release number of “01” in the conditional data element 0076 (Syntax release number), each of
which appear 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 and its Amendment 1:1992 — Syntax version number: 3
 ISO 9735:1998 — Syntax version number: 4
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 parts 1, 2, 5 and 10 of ISO 9735.
When identified in this part of ISO 9735, provisions defined in related standards shall form part of the conformance
criteria.
© ISO 2002 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 9735-9:2002(E)
3 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO 9735. For dated references, subsequent amendments to, or revisions of, any of these publications
do not apply. However, parties to agreements based on this part of ISO 9735 are encouraged to investigate the
possibility of applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain
registers of currently valid International Standards.
ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules
common to all parts
ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific
to batch EDI
ISO 9735-5:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for
batch EDI (authenticity, integrity and non-repudiation of origin)
ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 10: Syntax service
directories
4 Terms and definitions
For the purposes of this part of ISO 9735, the terms and definitions given in ISO 9735-1 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
ISO 9735-5.
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.
2 © ISO 2002 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 9735-9:2002(E)
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.
Security key and certificate management 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.
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 ISO 9735-5). 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 ISO 9735-5). This group
shall be used in the request or delivery of keys and certificates.
© ISO 2002 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 9735-9:2002(E)
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 ISO 9735-5). This segment shall be
used for certificate requests such as renewal, or asymmetric key requests such as
discontinuation, and for certificate deliveries.
0100 USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the
technical parameters required (as defined in ISO 9735-5). 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 ISO 9735-5). This segment shall be used for certificate
validation or certificate deliveries.
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 ISO 9735-5). 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 ISO 9735-5). 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 ISO 9735-5). If it is required to indicate the algorithms used with a
certificate, this segment shall be used.
4 © ISO 2002 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 9735-9:2002(E)
0170 USR, Security result
A segment containing the result of the security functions applied to the certificate by the certification
authority (as defined in ISO 9735-5). 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 2002 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 9735-9:2002(E)
5.4.3 Message structure
Table 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

6 © ISO 2002 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 9735-9:2002(E)
Annex A
(informative)

KEYMAN functions
A.1 Introduction
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.
A.2 Registration-related key management functions
A.2.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
ISO 9735-5 may be useful, if further secured out of band.
A.2.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.
A.3 Certification-related key management functions
A.3.1 Certification request
The purpose is to request certification of credentials and public key.
It may be presumed to be merely a request following prior out of band transfer of information, in which case the
request itself results in no transfer of information. No registered keys may yet available, so it is assumed to be an
unsecured message. However, if this information is transmitted in the message, it will require separate
authentication. If a registered key already exists, then this may be used to provided non-repudiation of origin for the
information for the new key and certificate.
© ISO 2002 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 9735-9:2002(E)
Nevertheless, if the message is used by a user to forward his public key, it should be possible for him to sign it with
the corresponding secret key, even though no label exists yet for the public key. This is called self-certification, and
requires the use of security header and trailer segment groups. To indicate that the key is self-certified, the security
header segment group defined in ISO 9735-5 must contain a certificate issued by the user on his own key.
Although a self-certified public key does not prove its user’s authenticity to another party, it does prove to the
certification authority that the user is in possession of the corresponding private key.
A.3.2 Certificate renewal request
The purpose is to request the renewal (or update) of a certificate.
The purpose of this is to extend the validity period of the current valid key, whose certificate is about to expire. The
request must be signed, using EDIFACT security header and trailer segment groups described in ISO 9735-5, by
the private key certified by the certificate to be renewed.
A.3.3 Certificate replacement request
The purpose is to request the replacement of a current certificate by a new one with a different public key, as well
as giving additional information if required. The request must be signed according to an agreed policy using
EDIFACT header and trailer segment groups described in ISO 9735-5.
It differs from a renewal request in that the old certificate typically is revoked, rather than expiring. A new certificate
always has a new certificate reference number, while a revocation certificate always carries the same reference
number as the certificate being revoked.
A.3.4 Certificate (path) retrieval request
The purpose is to request the delivery of an existing certificate, valid or a revoked, or a revocation certificate. This
also includes the situation where the response contains a certification path rather than just a certificate, as usually
the inquirer is ignorant to such details.
If the certificate reference number has been specified, there are no requirements for security since the certificates
are public.
A.3.5 Certificate delivery
The purpose is to deliver an existing certificate or revocation certificate with or without prior request.
The certification authority (CA) public key transport would normally be handled out of band. However, for
convenience of re-keying, a message may be required, possibly secured by header and trailer segment groups for
integrity, with separate authentication. If available, it may tempt users to ignore checking the out of band value, in
which case it will actually reduce security considerably. This may require security services, such as non-repudiation
of origin.
A.3.6 Certificate status request
The purpose is to request the current status of a given certificate.
A.3.7 Certificate status notice
The purpose is to inform the requesting party about the status of the given certificate.
The possible status’s are: unknown, valid or revoked. This notice may be delivered without prior request and would
typically have to be secured by non-repudiation of origin.
8 © ISO 2002 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 9735-9:2002(E)
A.3.8 Certificate validation request
The request is to be forwarded to a CA for the validation of an existing certificate.
This pertains to certificates of other security domains (i.e. issued by other CA’s), in which case the user may be
unable to establish the validity.
A.3.9 Certificate validation notice
This is the response to a certificate validation request. It is recommended to use non-repudiation of origin or other
means of authentication for this.
A.4 Revocation-related key management functions
A.4.1 Revocation request
The purpose is to request revocation (the change of status from valid to invalid) of a party’s certificate, e.g.
because the private key has been compromised, the user has changed to a new CA, the original certificate has
been superseded, use has been terminated (for example, the user left the company), or some other reason. It is
recommended to use authentication if possible. The function may require a separate channel, and may cover the
case where the user has lost the private key.
A.4.2 Revocation confirmation
The purpose is to confirm the revocation of the requested certificate.
It is recommended to secure this by means of non-repudiation of origin.
A.4.3 Revocation list request
The purpose is to request full or partial list of revoked certificates.
A.4.4 Revocation list delivery
The purpose is to inform parties about all (or a specified subset of all) currently revoked certificates in the CA’s
domain.
This is like a multiple status notice, but only for revoked certificates. While it would be possible to have a separate
black list type, it is probably better to just have one, and identify the status. The delivery should be secured by
non-repudiation of origin.
A.5 Alert request
The purpose is to request a party’s certificate to be put on alert.
The certificate is not revoked (no request to the CA) but the other users are warned that there can be something
wrong with this certificate. This could be used if no appropriate means of authentication is available to secure a
revocation request, for example a second, valid, key and certificate.
A.6 Certificate path delivery
The purpose is to deliver an existing certification path with or without prior request.
© ISO 2002 – All rights reserved 9

---------------------- Page: 15 ----------------------
ISO 9735-9:2002(E)
A.7 Symmetric key generation and transport
A.7.1 Symmetric key request
The purpose is to request the delivery of symmetric data keys or key encryption keys. Since the delivery of the keys
implies a prior secure relationship between the two parties, the originator must be authenticated using a key
encrypting key (KEK, a key used to provide confidentiality for another key), if public key te
...

OSIST ISO 9735-9:2004SLOVENSKImaj 2004
PREDSTANDARDElektronska menjava podatkov (-računalniška-) v administraciji (upravi), trgovini in transportu (prevozništvu) EDIFACT
- Pravila sintakse za uporabniški nivo (izvedbena oblika sintakse: 4, zaporedna št. izdaje 1) Deveti del: varnostni ključ in certifikat upravljalskega (management) sporočila (Vrsta sporočila KEYMAN)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)©
Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljenoReferenčna številkaOSIST ISO 9735-9:2004(en)ICS35.240.60







Reference numberISO 9735-9:2002(E)© ISO 2002
INTERNATIONAL STANDARD ISO9735-9Second edition2002-07-01Electronic 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) É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, numéro d'édition de syntaxe: 1) — Partie 9: Clé de sécurité et message de gestion de certificat (type de message KEYMAN)



ISO 9735-9:2002(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
©
ISO 2002 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 either ISO at the address below or ISO's member body in the country of the requester. 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 Printed in Switzerland
ii © ISO 2002 – All rights reserved



ISO 9735-9:2002(E) © ISO 2002 – All rights reserved iii Contents Page Foreword.iv Introduction.vi 1 Scope.1 2 Conformance.1 3 Normative references.2 4 Terms and definitions.2 5 Rules for the use of security key and certificate management message.2 Annex A (informative)
KEYMAN functions.7 Annex B (informative)
Security techniques to be applied to KEYMAN messages.11 Annex C (informative)
Use of segment groups in KEYMAN messages.12 Annex D (informative)
A model for key management.14 Annex E (informative)
Key and certificate management examples.16



ISO 9735-9:2002(E) iv © ISO 2002 – All rights reserved
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 collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. The main task of technical committees is to prepare International Standards. 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. Attention is drawn to the possibility that some of the elements of this part of ISO 9735 may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO 9735-9 was prepared by Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and administration in collaboration with UN/CEFACT through the Joint Syntax Working Group (JSWG). This second edition cancels and replaces the first edition (ISO 9735-9:1999). However ISO 9735:1988 and its Amendment 1:1992 are provisionally retained for the reasons given in clause 2. Furthermore, for maintenance reasons the Syntax service directories have been removed from this and all other parts of the ISO 9735 series. They are now consolidated in a new part, ISO 9735-10. At the time of publication of ISO 9735-1:1998, ISO 9735-10 had been allocated as a part for “Security rules for interactive EDI”. This was subsequently withdrawn because of lack of user support, and as a result, all relevant references to the title “Security rules for interactive EDI” were removed in this second edition of ISO 9735-9. Definitions from all parts of the ISO 9735 series have been consolidated and included in ISO 9735-1. 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, Syntax release number: 1): — Part 1: Syntax rules common to all 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) — Part 6: Secure authentication and acknowledgement message (message type — AUTACK) — Part 7: Security rules for batch EDI (confidentiality) — Part 8: Associated data in EDI



ISO 9735-9:2002(E) © ISO 2002 – All rights reserved v — Part 9: Security key and certificate management message (message type — KEYMAN) — Part 10: Syntax service directories Further parts may be added in the future. Annexes A to E of this part of ISO 9735 are for information only.



ISO 9735-9:2002(E) vi © ISO 2002 – All rights reserved
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.



INTERNATIONAL STANDARD ISO 9735-9:2002(E) © ISO 2002 – All rights reserved 1 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) 1 Scope This part of ISO 9735 for batch EDIFACT security defines the security key and certificate management message KEYMAN. 2 Conformance Whereas this part shall use a version number of “4” in the mandatory data element 0002 (Syntax version number), and shall use a release number of “01” in the conditional data element 0076 (Syntax release number), each of which appear 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 and its Amendment 1:1992 — Syntax version number: 3  ISO 9735:1998 — Syntax version number: 4 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 parts 1, 2, 5 and 10 of ISO 9735. When identified in this part of ISO 9735, provisions defined in related standards shall form part of the conformance criteria.



ISO 9735-9:2002(E) 2 © ISO 2002 – All rights reserved
3 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this part of ISO 9735. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this part of ISO 9735 are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards. ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 1: Syntax rules common to all parts ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 2: Syntax rules specific to batch EDI ISO 9735-5:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin) ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application level syntax rules (Syntax version number: 4, Syntax release number: 1) — Part 10: Syntax service directories 4 Terms and definitions For the purposes of this part of ISO 9735, the terms and definitions given in ISO 9735-1 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 ISO 9735-5. 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.



ISO 9735-9:2002(E) © ISO 2002 – All rights reserved 3 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. Security key and certificate management 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. 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 ISO 9735-5). 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 ISO 9735-5). This group shall be used in the request or delivery of keys and certificates.



ISO 9735-9:2002(E) 4 © ISO 2002 – All rights reserved
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 ISO 9735-5). This segment shall be used for certificate requests such as renewal, or asymmetric key requests such as discontinuation, and for certificate deliveries. 0100 USA, Security algorithm A segment identifying a security algorithm, the technical usage made of it, and containing the technical parameters required (as defined in ISO 9735-5). 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 ISO 9735-5). This segment shall be used for certificate validation or certificate deliveries. 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 ISO 9735-5). 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 ISO 9735-5). 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 ISO 9735-5). If it is required to indicate the algorithms used with a certificate, this segment shall be used.



ISO 9735-9:2002(E) © ISO 2002 – All rights reserved 5 0170 USR, Security result A segment containing the result of the security functions applied to the certificate by the certification authority (as defined in ISO 9735-5). 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 9735-9:2002(E) 6 © ISO 2002 – All rights reserved
5.4.3 Message structure Table 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 9735-9:2002(E) © ISO 2002 – All rights reserved 7 Annex A (informative)
KEYMAN functions A.1 Introduction 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. A.2 Registration-related key management functions A.2.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 ISO 9735-5 may be useful, if further secured out of band. A.2.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. A.3 Certification-related key management functions A.3.1 Certification request The purpose is to request certification of credentials and public key. It may be presumed to be merely a request following prior out of band transfer of information, in which case the request itself results in no transfer of information. No registered keys may yet available, so it is assumed to be an unsecured message. However, if this information is transmitted in the message, it will require separate authentication. If a registered key already exists, then this may be used to provided non-repudiation of origin for the information for the new key and certificate.



ISO 9735-9:2002(E) 8 © ISO 2002 – All rights reserved
Nevertheless, if the message is used by a user to forward his public key, it should be possible for him to sign it with the corresponding secret key, even though no label exists yet for the public key. This is called self-certification, and requires the use of security header and trailer segment groups. To indicate that the key is self-certified, the security header segment group defined in ISO 9735-5 must contain a certificate issued by the user on his own key. Although a self-certified public key does not prove its user’s authenticity to another party, it does prove to the certification authority that the user is in possession of the corresponding private key. A.3.2 Certificate renewal request The purpose is to request the renewal (or update) of a certificate. The purpose of this is to extend the validity period of the current valid key, whose certificate is about to expire. The request must be signed, using EDIFACT security header and trailer segment groups described in ISO 9735-5, by the private key certified by the certificate to be renewed. A.3.3 Certificate replacement request The purpose is to request the replacement of a current certificate by a new one with a different public key, as well as giving additional information if required. The request must be signed according to an agreed policy using EDIFACT header and trailer segment groups described in ISO 9735-5. It differs from a renewal request in that the old certificate typically is revoked, rather than expiring. A new certificate always has a new certificate reference number, while a revocation certificate always carries the same reference number as the certificate being revoked. A.3.4 Certificate (path) retrieval request The purpose is to request the delivery of an existing certificate, valid or a revoked, or a revocation certificate. This also includes the situation where the response contains a certification path rather than just a certificate, as usually the inquirer is ignorant to such details. If the certificate reference number has been specified, there are no requirements for security since the certificates are public. A.3.5 Certificate delivery The purpose is to deliver an existing certificate or revocation certificate with or without prior request. The certification authority (CA) public key transport would normally be handled out of band. However, for convenience of re-keying, a message may be required, possibly secured by header and trailer segment groups for integrity, with separate authentication. If available, it may tempt users to ignore checking the out of band value, in which case it will actually reduce security considerably. This may require security services, such as non-repudiation of origin. A.3.6 Certificate status request The purpose is to request the current status of a given certificate. A.3.7 Certificate status notice The purpose is to inform the requesting party about the status of the given certificate. The possible status’s are: unknown, valid or revoked. This notice may be delivered without prior request and would typically have to be secured by non-repudiation of origin.



ISO 9735-9:2002(E) © ISO 2002 – All rights reserved 9 A.3.8 Certificate validation request The request is to be forwarded to a CA for the validation of an existing certificate. This pertains to certificates of other security domains (i.e. issued by other CA’s), in which case the user may be unable to establish the validity. A.3.9 Certificate validation notice This is the response to a certificate validation request. It is recommended to use non-repudiation of origin or other means of authentication for this. A.4 Revocation-related key management functions A.4.1 Revocation request The purpose is to request revocation (the change of status from valid to invalid) of a party’s certificate, e.g. because the private key has been compromised, the user has changed to a new CA, the original certificate has been superseded, use has been terminated (for example, the user left the company), or some other reason. It is recommended to use authentication if possible. The function may require a separate channel, and may cover the case where the user has lost the private key. A.4.2 Revocation confirmation The purpose is to confirm the revocation of the requested certificate. It is recommended to secure this by means of non-repudiation of origin. A.4.3 Revocation list request The purpose is to request full or partial list of revoked certificates. A.4.4 Revocation list delivery The purpose is to inform parties about all (or a specified subset of all) currently revoked certificates in the CA’s domain. This is like a multiple status notice, but only for revoked certificates. While it would be possible to have a separate black list type, it is probably better to just have one, and identify the status. The delivery should be secured by
non-repudiation of origin. A.5 Alert request The purpose is to request a party’s certificate to be put on alert. The certificate is not revoked (no request to the CA) but the other users are warned that there can be something wrong with this certificate. This could be used if no appropriate means of authentication is available to secure a revocation request, for example a second, valid, key and certificate. A.6 Certificate path delivery The purpose is to deliver an existing certification path with or without prior request.



ISO 9735-9:2002(E) 10 © ISO 2002 – All rights reserved
A.7 Symmetric key generation and transport A.7.1 Symmetric key request The purpose is to request the delivery of symmetric data keys or key encryption keys. Since the delivery of the keys implies a prior secure relationship between the two parties, the originator must be authenticated using a key encrypting key (KEK, a key used to provide confidentiality for another key), if public key techniques are not used. A.7.2 Symmetric key delivery The purpose is to deliver symmetric keys (with or without prior request). If symmetric techniques are used only, it must be assumed that an out of band transfer of a KEK would be necessary before the transfer. The algorithm parameter in USA would then carry the encrypted key. A.8 Key discontinuation A.8.1 (A)symmetric key discontinuation request The purpose is to request discontinuation of an existing symmetric or asymmetric key (if certificates are not used), e.g. because the key has been compromis
...