Committee EDIFACT DRAFT CD 9735-5 Release 1 1996-06-15 Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin.) Contents Page Foreword 4 Introduction 5 1 Scope 6 2 Conformance 6 3 References 6 4 Definitions 7 5 Rules for the use of security headers and trailers for batch EDI 8 8 6 Rules for the use of interchange and group security headers and trailers for batch EDI 15 Annex A: Definitions 16 Annex B: Directory specification 17 Annex C: Security threats and solutions 37 Annex D: How to protect an EDIFACT structure 40 Annex E: Message protection examples 43 Annex F: UN/EDIFACT character set repertoire A filter function: the EDA filter 51 Annex G: Code lists 52 Foreword (To be amended as necessary, according to ISO procedures) 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. Draft International Standards adopted by the technical committees are circulated to the member bodies for approval before their acceptance as International Standards by the ISO Council. They are approved in accordance with ISO procedures requiring at least 75% approval by the member bodies voting. International Standard ISO 9735-1 Version 4 was prepared by the UN/ECE Trade Division (as UN/EDIFACT) and was adopted, under the "fast-track procedure" as an existing standard, by Technical Committee ISO TC 154, Documents and data elements in administration; commerce and industry. ISO/IEC 9735 consists (currently) of the following parts, under the general title Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules: ISO 9735-1 - Syntax rules common to all parts and the syntax service directories ISO 9735-2 - Syntax rules specific to batch EDI ISO 9735-3 - Syntax rules specific to interactive EDI ISO 9735-4 - Syntax and service report message for batch EDI (message type - CONTRL) ISO 9735-5 - Security rules for batch EDI (authenticity, integrity and non-repudiation of origin) ISO 9735-6 - Secure authentication and acknowledgement message (message type - AUTACK) ISO 9735-7 - Security rules for batch EDI (confidentiality) ISO 9735-8 - Associated data in EDI ISO 9735-9 - Security key and certificate management message (message type - KEYMAN) Further parts may be added in the future. In this Part 5, annexes A and B form an integral part of this International Standard. Introduction This International Standard includes the rules at the application level for the structuring of data in the interchange of electronic messages in an open environment, based on the requirements of either batch or interactive processing. These rules have been agreed by the United Nations Economic Commission for Europe (UN/ECE) as syntax rules for Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) and are part of the United Nations Trade Data Interchange Directory (UNTDID) which also includes both batch and interactive Message Design Guidelines. These syntax rules may be used in any application, but messages using these rules may only be referred to as EDIFACT messages if they comply with other guidelines, rules and directories in the UNTDID. For UN/EDIFACT, messages shall comply with the message design rules for batch or interactive usage as applicable. These rules are maintained in the UNTDID. Communications specifications and protocols are outside the scope of this standard. This is a new part, which has been added to ISO 9735. It provides an optional capability of securing an EDIFACT structure i.e. message, package, group or interchange. Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules Part 5: Security rules for batch EDI (authenticity, integrity and non- repudiation of origin.) 1 Scope This part of ISO 9735 specifies syntax rules for EDIFACT security. This provides a method to address message/package level, group level and interchange level security for authenticity, integrity and non-repudiation of origin, in accordance with established security mechanisms. 2 Conformance Conformance to a standard means that all of its requirements, including all options, are supported. If all options are not supported, any claim of conformance shall include a statement which identifies those options to which conformance is claimed. Data that is interchanged is in conformance if the structure and representation of the data conforms to the syntax rules specified in this International Standard. Devices supporting this International Standard are in conformance when they are capable of creating and/or interpreting the data structured and represented in conformance with the standard. Conformance to this part shall include conformance to Part 1, Part 2 and Part 8. When identified in this International Standard, provisions defined in related standards shall form part of the conformance criteria. 3 References 3.1 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. ISO 8601 Representation of dates and times in information interchange ISO 10646-1 Information technology - Universal Multiple-Octet Coded Character Set (UCS); Part 1: Architecture and basic multilingual plane ISO 7498-2 Information processing systems - Open Systems Interconnection - Basic Reference Model. Part 2: Security architecture ISO 9594-8 (CCITT Recommendation X 509) Information technology - Open System Interconnection - The Directory - Part 8: Authentication framework. ISO 10770-1 Information technology - Security techniques - Key management - . Part 1: Framework ISO 10181-1 Information technology - Security frameworks for Open Systems - . Part 1: Frameworks overview ISO 10181-1 Information technology - Security frameworks for Open Systems - . Part 1: Frameworks overview ISO 10181-2 Information technology - Security frameworks for Open Systems - . Part 2: Authentication framework ISO 10181-4 Information technology - Security frameworks for Open Systems - . Part 4: Non-repudiation framework ISO 10181-6 Information technology - Security frameworks for Open Systems - . Part 6: Integrity framework 4 Definitions For the purpose of this International Standard, the definitions in Part 1 annex A and in annex A of this document apply. 5 Rules for the use of security headers and trailers for batch EDI 5.1 Message/package level security - integrated message/package sec urity The security threats relevant to message/package transmission and the security services which address them are described in annexes C and D. This section describes the structure of EDIFACT message/package level security. The security services may either be integrated into the message/package itself or provided by a separate message. Security services addressed in this International Standard shall be provided by the inclusion of security header and trailer segment groups after the UNH and before the UNT, in a way which shall be applied to any existing message, or after the UNO and before the UNP, for any existing package. after the UNH and before the UNT, in a way which shall be applied to any existing message/package. 5.1.1 Security headers and trailers Figure 1 describes an interchange containing a secured message and a secured package. Figure 1 - Interchange containing a secured message (schematic) THIS SCHEMATIC IS NOT AVAILABLE IN ASCII.FORMAT. Figure 2 describes an interchange containing a secured package. Figure 2 - Interchange containing a secured package (schematic) THIS SCHEMATIC IS NOT AVAILABLE IN ASCII.FORMAT. 5.1.2 Security header and trailer groups segment structure TAG Name S R UNH Message Header M 1 ---- Segment Group 1 ----------- C 99 -------+ USH Security Header M 1 I USA Security Algorithm C 1 I ---- Segment Group 2 ----------- C 2 ----+ I I USC Certificate M 1 I I USA Security Algorithm C 3 I I USR Security Result C 1 -------+ Message body ---- Segment Group n ----------- C 99 ----+ UST Security Trailer M 1 I USR Security Result C 1 ----+ UNT Message Trailer M 1 Figure 3 - Security header and security trailer groups segment table (secured message) TAG Name S R UNO Package Header M 1 ---- Segment Group 1 ----------- C 99 -------+ USH Security Header M 1 I USA Security Algorithm C 1 I ---- Segment Group 2 ------------C 2 ----+ I USC Certificate M 1 I I USA Security Algorithm C 3 I I USR Security Result C 1 -------+ Object ---- Segment Group n ----------- C 99 ____+ UST Security Trailer M 1 I USR Security Result C 1 ----+ UNP Package Trailer M 1 Figure 4 - Security header and security trailer groups segment table (secured package) Note: UNH message header and UNT message trailer are specified in Part 1 of this International Standard. UNO package header and UNP package trailer are specified in Part 8 of the present International Standard. They are not described further in this Part. The complete directory specification of the segments and data elements may be found in annex B. 5.1.3 Data segment clarification Segment Group 1: USH-USA-Group 2 (security header) A group of segments identifying the security service and security mechanisms applied and containing the data necessary to carry out the validation calculations. There may be several different security header groups within the same message/package, if different security services are applied to the message/package(e. g. integrity and non-repudiation of origin) or if the same security service is applied by several entities. USH, Security header A segment specifying a security service applied to the message/package in which the segment is included. The entities involved in the security service (security elements originator and security elements recipient), may be identified in this segment, unless they are unambiguously identified by means of certificates (USC segment) when asymmetric algorithms are used. Security identification details composite data element (S500) shall be used in USH segment either: - if symmetric algorithms are used, or - if asymmetric algorithms are used and when two certificates are present, in order to distinguish between the originator and the recipient certificates In this latter case, the identification of the party in S500 (any of the data elements S500/0511, S500/0513, S500/0515, S500/0586) shall be the same as the identification of the party, qualified as "certificate owner" in one of the S500 present in the USC segment in segment group 2, and data element S500/0577 shall identify the function (originator or recipient) of the party involved. Data element key name in security identification details composite data element (S500/0538) may be used to establish the key relationship between the sending and receiving parties. This key relationship may also be established by using the data element identification of the key of the algorithm parameter composite data element(S503/0554) in the USA segment of segment group 1. S500/0538 Usage of data element key name in security identification details composite data element inof USH segment mayshall be usedpreferred if there is no need to convey a USA segment in segment group 1 (because the cryptographic mechanisms have been agreed previously between the partners). Nevertheless, it is strongly recommended to use either S500/0538 in the USH segment, or S503/0554 with the appropriate qualifier in the USA segment, but not both of them, within the same security header group. USH segment may specify the filter function used for the binary fields of USA segment within segment group 1 and of the USR segment of the corresponding security trailer group. USH segment may include a security sequence number, to provide sequence integrity, and the date of creation of the security elements. USA, Security algorithm A segment identifying a security algorithm, the technical usage made of it, and containing the technical parameters required. This shall be the algorithm applied directly on the message/package. This algorithm may be either symmetric, or a hash function. For example, for digital signature, it indicates the message-dependent hash function to be used. Asymmetric algorithms shall not be referred to directly in this USA segment within segment group 1 but may appear only within segment group 2, triggered by a USC segment. Segment Group 2: USC-USA-USR (certificate) A group of segments containing the data necessary to validate the security methods applied to the message/package, when asymmetric algorithms are used. Certificate segment group shall be used when asymmetric algorithms are used to identify the asymmetric key pair used, even if certificates are not used. Either the full certificate segment group (including the USR segment), or the only data elements necessary to identify unambiguously the asymmetric key pair used shall be present, in the USC segment. The presence of a full certificate may be avoided if the certificate has already been exchanged by the two parties, or if it may be retrieved from a database. Two occurrences of this segment group are allowed, one being the message/package sender certificate (that the message/package receiver will use to verify the sender's signature), the other being the message/package receiver certificate (only referred to by certificate reference) in the case where the receiver public key is used by the sender for confidentiality of symmetric keys. If both are present within one security header group, the security identification details data element (S500) together with the certificate reference data element (0536) allow them to be differentiated. This segment group shall be omitted if no asymmetric algorithm is used. USC, Certificate A segment containing the credentials of the certificate owner and identifying the certification authority which has generated the certificate. The data element filter function, coded (0505) shall identify the filter function used for the binary fields of USA segments and USR segment within segment group 2. USC certificate may contain two occurrences of S500: one for the certificate owner (identifying the entity which signs with the private key associated to the public key contained in this certificate), one for the certificate issuer (certification authority or CA). USA, Security algorithm A segment identifying a security algorithm, the technical usage made of it, and containing the technical parameters required. The three different occurrences of this USA segment in segment group 2 are identifying: 1 the algorithm used by the certificate issuer to compute the hash value of the certificate (hashing function) 2 the algorithm used by the certificate issuer to generate the certificate (i.e. to sign the result of the hash function computed on the certificate content) (asymmetric algorithm) 3a - either the algorithm used by the sender to sign the message/package (i.e. to sign the result of the hash function described in the USH segment, computed on the message/package content) (asymmetric algorithm), 3b - or the receiver's asymmetric algorithm used by the sender to encrypt the key required by a symmetric algorithm applied to the message/package content and referred to by the segment group 1 triggered by the USH segment (asymmetric algorithm) USR, Security result A segment containing the result of the security functions applied to the certificate by the certification authority. This result shall be the signature of the certificate computed by the certification authority by signing the hash result computed on the data of the credentials. For the certificate, the signature computation starts with the first character of the USC segment (namely the "U") and ends with the last character of the last USA segment (including the separator following this USA segment). Segment Group n: UST-USR (security trailer) A group of segments containing a link with security header segment group and the result of the security functions applied to the message/package. UST, Security trailer A segment establishing a link between security header and security trailer. USR, Security result A segment containing the result of the security functions applied to the message/package as specified in the linked security header group. Depending on the security mechanisms specified in the linked security header group, this result shall be either: - computed directly on the message/package by the algorithm specified in the USA segment within segment group 1 of the security header group, or - computed by signing with an asymmetric algorithm specified in USA segment within segment group 2 of the security header group a hash result computed on the message/package by the algorithm specified in the USA segment within segment group 1 of the security header group 5.1.4 Scope of security application There are two possibilities for the scope of security application: 1. The computation of each of the integrity and authentication values and of the digital signatures starts with and includes the current security header group and the message body, or object, itself. In this case no other security header or security trailer groups shall be encompassed within this scope. The security header segment group shall be counted from the first character, namely a "U", to the separator ending this security header segment group, both included, and the message body, or object, from the first character following the separator ending the last security header segment group to the separator preceding the first character of the first security trailer segment group, both included. Thus the order in which security services integrated in this manner are performed, is not prescribed. They are completely independent of each other. Figure 5 illustrates this case (the scope of application of the security service defined in the security header 2 is represented by shaded boxes): FIGURE 5 IS NOT AVAILABLE IN ASCII.FORMAT. Figure 5 - Scope of application: security header group and message body/object only (schematic) 2. The computation starts with and includes the current security header group to the associated security trailer group. In this case the current security header group, the message body, or object, and all the other embedded security header and trailer groups shall be encompassed within this scope. The scope shall include every character from the first character, namely a "U", of the current security header segment group, to the separator preceding the first character of the associated security trailer segment group, both included. Figure 6 illustrates this case (the scope of application of the security service defined in the security header 2 is represented by shaded boxes): THIS FIGURE IS NOT AVAILABLE IN ASCII.FORMAT. Figure 6 - Scope of application: from security header group to security trailer group (schematic) For each added security service, either of the two approaches may be chosen In both cases, the relation between the security header and associated security trailer segment groups shall be provided by the data elements security reference number of the USH and of the UST segments. 5.2 Principles of usage 5.2.1 Choice of service The security header group may include the following general information: Security service applied Identification of the entities involved Security mechanism used "Unique" value (sequence number and/or timestamp) Non-repudiation of receipt request If more than one security service is required for the same EDIFACT structure, then the security header group may be present several times. This shall be the case when several pairs of entities are involved. However, if several services are required between the same two entities they may be included in a single pair of security header and trailer groups, as certain services include others implicitly. 5.2.2 Authenticity If origin authentication of a EDIFACT structure is required, it shall be provided in accordance to the principles defined in ISO 10181-2 "Security frameworks for Open Systems- Part 2: Authentication framework", using an appropriate a pair of security header and security trailer groups. The security service of origin authentication shall be specified in the security header group and the algorithm shall be identified in the USA segment in segment group 1. It shall be a symmetric algorithm. The party acting as security originator shall compute an authenticity value that shall be conveyed in the USR segment of the security trailer group. The party acting as security recipient shall check the authenticity value. This service may include integrity service and may be obtained as a sub-product of non-repudiation of origin service. If an appropriate implementation of this "origin authentication" service, based on tamper resistant hardware or trusted third parties, is used, it may be considered as an instance of "non repudiation of origin" service. Such a practice shall be defined in the interchange agreement. 5.2.3 Integrity If content integrity of a EDIFACT structure is required, it shall be provided in accordance to the principles defined in ISO 10181-6 "Security frameworks for Open Systems- Part 6: Integrity framework", using an appropriate a pair of security header and security trailer groups. The security service of integrity shall be specified in the security header group and the algorithm shall be identified in the USA segment in segment group 1. It shall be hash function or a symmetric algorithm. The party acting as security originator shall compute an integrity value that shall be conveyed in the USR segment of the security trailer group.The party acting as security recipient shall check the integrity value. This service may be obtained as a sub-product of origin authentication service or of non-repudiation of origin service. If sequence integrity is required, either a security sequence number or a security timestamp, or both, shall be contained by the security header group and either content integrity service or origin authentication service or non-repudiation of origin service shall be used. 5.2.4 Non-repudiation of origin If non-repudiation of origin of a EDIFACT structure is required, it shall be provided in accordance to the principles defined in ISO 10181-4 "Security frameworks for Open Systems- Part 4: Non- repudiation framework", using an appropriate a pair of security header and security trailer groups. The security service of non-repudiation of origin shall be specified in the security header group and the hashing algorithm shall be identified in the USA segment in segment group 1, and the asymmetric algorithm used for signature in the USA segments of segment group 2, if certificates are used. If the certificate is not conveyed in the message/package, the asymmetric algorithm shall be implicitly known by the receiving party. In this case the asymmetric algorithm shall be defined in the interchange agreement. The party acting as security originator shall compute a digital signature that shall be conveyed in the USR segment of the security trailer group.The party acting as security recipient shall verify the digital signature value. This service provides also content integrity and origin authentication services. 5.3 Internal representation and filters for compliance with EDIFACT syntax The use of mathematical algorithms to compute integrity values and digital signatures introduces two problems. The first problem is that the result of the calculation depends on the internal representation of the character set. Thus the computation of the digital signature by the sender and its verification by the recipient shall be executed using the same character set encoding. Therefore the sender shall indicate the representation used to produce the original security validation result. The second problem is that the result of the calculation is a seemingly random bit pattern. This causes problems during transmission and with interpretation software. To avoid these problems the bit pattern is reversibly mapped on to a particular representation of the character set used by means of a filtering function. For simplicity, only one filtering function shall be used for each security service. Any appearance of an anomalous terminator in the output of this mapping is dealt with by including an escape sequence. 6 Rules for the use of interchange and groups security headers and trailers for batch EDI 6.1 Group and interchange level security The security threats relevant to message/package transmission and the security services which address them, as described in annexes C and D, are also valid at group and interchange level. The techniques described in the previous section for applying security to messages/packages may also be applied to interchanges and groups. 6.2 Integrated message security For group and interchange level security, the same header and trailer groups as those described at message/package level, shall be used, and header-trailer cross referencing shall always apply at the same level, even when security is applied separately at more than one level. When security is applied at message/package level, the protected structure is the message body or object. At group level it is the set of messages in the group including all message headers and trailers. At interchange level, it is the set of messages or groups in the interchange, including all message and/or group headers and trailers. Two alternative scopes of application of the security services for message/package level security are detailed in section 5.1.4 The same possibilities are applicable at interchange or group level. The structure of an interchange containing secured interchange, groups and/or messages/packages is described in figure 57. Figure 7 - Secured interchange containing a secured group (schematic) THIS SCHEMATIC IS NOT AVAILABLE IN ASCII.FORMAT. ANNEX A (normative) DEFINITIONS For the purpose of this International Standard, the following definitions apply: A.1 asymmetric algorithm: A cryptographic algorithm employing a public key and a private key. Together these form an asymmetric key set. [1] A.2 certificate: The public key of a user, together with some other information, rendered unforgeable by a signature with the private key of the certification authority which issued it. (ISO 9594-8) [2] A.3 certification authority: An authority trusted by one or more users to create and assign certificates. (ISO 9594-8) [3] A.4 confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities or processes. (ISO 7498-2) [4] A.5 credential: Data that serves to establish the claimed identity of an entity. (ISO 7498-2) [5] A.6 cryptography: The discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use. (ISO 7498- 2) [6] A.7 data integrity: The property that data has not been altered or destroyed in an unauthorised manner. (ISO 7498-2) [7] A.8 data origin authentication: The corroboration that the source of data received is as claimed. (ISO 7498-2) [8] A.9 decryption: See decipherment. (ISO 7498-2) [9] A.10 decipherment: The reversal of a corresponding reversible encipherment. (ISO 7498-2) [10] A.11 digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient. (ISO 7498-2) [11] A.12 encipherment: The cryptographic transformation of data (see cryptography) to produce ciphertext. (ISO 7498-2) [12] A.13 encryption: See encipherment. (ISO 7498-2) [13] A.14 hash function: A (mathematical) function which maps values from a large (possibly very large) domain into a smaller range. A 'good' hash function is such that the results of applying the function to a (large) set of values in the domain will be evenly distributed (and apparently at random) over the range. (ISO 9594-8) [14] A.15 key: A sequence of symbols that controls the operations of encipherment and decipherment. (ISO 7498-2) [15] A.16 private key: (In a public key cryptosystem) that key of a user's key pair which is known only by that user. (ISO 9594- 8) [16] A.17 public key: (In a public key cryptosystem) that key of a user's key pair which is publically known. (ISO 9594-8) [17] A.18 repudiation: Denial by one of the entities involved in a communication of having participated in all or part of the communication. (ISO 7498-2) [18] A.19 secret key: a key used with symmetric cryptographic techniques and usable only by a set of specified entities. (ISO 11770-1) [19] A.20 symmetric algorithm: A cryptographic algorithm employing the same value of key for both enciphering and deciphering or for both authentication and validation. [1920] A.21 threat: A potential violation of security. (ISO 7498-2) [201] ANNEX B (normative) DIRECTORY SPECIFICATION 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 tag for the segment of for the data elements contained in the segment. All service composite data elements are preceded by the letter "S", and 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 Notes Segment note number(s) B.1.2 Dependency notes 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 B.1.3 Index of segments by tag TAG Name USA Security algorithm USC Certificate USH Security header USR Security result UST Security trailer B.1.4 Index of segments by name TAG Name USC Certificate USA Security algorithm USH Security header USR Security result UST Security trailer B.1.5 Segment specification -------------------------------------------------------------- USA SECURITY ALGORITHM Function: To identify a security algorithm, the technical usage made of it, and to contain the technical parameters required. Pos TAG Name S R Repr. Notes 010 S502 SECURITY ALGORITHM M 1 0523 Use of algorithm, coded M an..3 0525 Cryptographic mode of operation, coded C an..3 0533 Mode of operation code list identifier C an..3 0527 Algorithm, coded C an..3 0529 Algorithm code list identifier C an..3 020 S503 ALGORITHM PARAMETER C 9 1 0531 Algorithm parameter qualifier M an..3 0554 Algorithm parameter value M an..512 NOTES: 1. S503, provides space for one parameter. The number of repetitions of S503 actually used will depend on the algorithm used. The order of the parameters is arbitrary but, in each case, the actual value is preceded by a coded algorithm parameter qualifier. ----------------------------------------------------------------------------- -------------------------------------------------------------- USC CERTIFICATE Function: To convey the public key and the credentials of its owner. Pos TAG Name S R Repr. Notes 010 0536 CERTIFICATE REFERENCE C 1 an..35 2 020 S500 SECURITY IDENTIFICATION DETAILS C 2 3 0577 Security party qualifier M an..3 0538 Key name C an..35 0511 Security party identification C an..17 0513 Security party code list qualifier C an..3 0515 Security party code list responsible agency, coded C an..3 0586 Security party name C an..35 0586 Security party name C an..35 0586 Security party name C an..35 030 0545 CERTIFICATE SYNTAX VERSION, CODED C 1 an..3 040 0505 FILTER FUNCTION, CODED C 1 an..3 050 0507 ORIGINAL CHARACTER SET ENCODING, CODED C 1 an..3 4 060 0543 CERTIFICATE ORIGINAL CHARACTER SET REPERTOIRE, CODED C 1 an..3 5 070 0546 USER AUTHORISATION LEVEL C 1 an..35 080 S505 SERVICE CHARACTER FOR SIGNATURE C 5 6 0551 Service character for signature qualifier M an..3 0548 Service character for signature M an..4 090 S501 SECURITY DATE AND TIME C 4 7 0517 Date and time qualifier M an..3 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4 100 0567 SECURITY STATUS, CODED C 1 an..3 1 110 0569 REVOCATION REASON, CODED C 1 an..3 1 DEPENDENCY NOTES: 1. D5 (110, 100) If first, then all. NOTES: 2. 0536, if a full certificate (including the USR segment) is not used,the only data elements of the certificate shall be a unique certificate reference made of: the certificate reference (0536), the S500 identifying the issuer certification authority or the S500 identifying the certificate owner, including its public key name. 3. S500/0538, identifies a public key: either of the owner of this certificate, or the public key related to the private key used by the certificate issuer (certification authority or CA) to sign this certificate. 4. 0507, the original character set encoding of the certificate when it was signed. If no value is specified, the character set encoding corresponds to that identified by the character set repertoire standard. 5. 0543, the original character set repertoire of the certificate when it was signed. If no value is specified, the default is defined in the interchange header. 6. S505, when this certificate is tranferred, it will use the default service characters defined in part 1 of this International Standard, or those defined in the service string advice, if used. This data element may specify the service characters used when the certificate was signed. If this data element is not used then they are the default service characters. 7. S501, dates and times involved in the certification process. Four occurrences of this composite data element are possible: one for the certificate generation date and time, one for the certificate start of validity period, one for the certificate end of validity period, one for revocation date and time. -------------------------------------------------------------- -------------------------------------------------------------- USH SECURITY HEADER Function: To specify a security mechanism applied to a EDIFACT structure (i.e.: either message/package, group or interchange). Pos TAG Name S R Repr. Notes 010 0501 SECURITY SERVICE, CODED M 1 an..3 020 0534 SECURITY REFERENCE NUMBER M 1 an..14 030 0541 SCOPE OF SECURITY APPLICATION, CODED C 1 an..3 1 040 0503 RESPONSE TYPE, CODED C 1 an..3 050 0505 FILTER FUNCTION, CODED C 1 an..3 060 0507 ORIGINAL CHARACTER SET ENCODING, CODED C 1 an..3 2 070 0509 ROLE OF SECURITY PROVIDER, CODED C 1 an..3 080 S500 SECURITY IDENTIFICATION DETAILS C 2 3,4 0577 Security party qualifier M an..3 0538 Key name C an..35 0511 Security Party identification C an..17 0513 Security party code list qualifier C an..3 0515 Security party code list responsible agency, coded C an..3 0586 Security party name C an..35 0586 Security party name C an..35 0586 Security party name C an..35 090 0520 SECURITY SEQUENCE NUMBER C 1 an..35 100 S501 SECURITY DATE AND TIME C 1 5 0517 Date and time qualifier M an..3 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4 110 0519 COMPRESSION FUNCTION, CODED C 1 an..3 NOTES: 1. 0541, if not present the default scope of security application is the current security header and the message body or object itself. 2. 0507, the original character set encoding of the EDIFACT structure when it was secured. If no value is specified, the character set encoding corresponds to that identified by the character set repertoire standard. 3. S500, two occurrences are possible: one for the security originator,one for the security recipient. 4. S500/0538, may be used to establish the key relationship between the sending and receiving parties. 5. S501, may be used as a security timestamp of the EDIFACT structure to which security is applied. This timestamp is security related and may differ from any dates and times that may appear elsewhere in the EDIFACT structure. It may be used to provide sequence integrity. ------------------------------------------------------------------ USR SECURITY RESULT Function: To contain the result of the security mechanisms. Pos TAG Name S R Repr. Notes 010 S508 VALIDATION RESULT M 2 1 0563 Validation value qualifier M an..3 0560 Validation value C an..256 NOTES: 1. S508, two occurrences shall be used in the case of signature algorithms requiring two parameters to express the result. In the case of an RSA signature, only one occurrence of S508 shall be used. In the case of a DSA signature two occurrences of S508 shall be used. ---------------------------------------------------------------------- UST SECURITY TRAILER Function: To establish a link between security header and security trailer. Pos TAG Name S R Repr. Notes 010 0534 SECURITY REFERENCE NUMBER M 1 an..14 1 NOTES: 1. 0534, the value shall be identical to the value in 0534 in the corresponding USH segment. ------------------------------------------------------------------- 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 tag for the component data element contained in the composite data element. All service composite data elements are preceded by 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 Notes Composite data element note number(s) B.2.2 Dependency notes 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 B.2.3 Index of composite data element by tag TAG Name S500 Security identification details S501 Security date and time S502 Security algorithm S503 Algorithm parameter S505 Service character for signature S508 Validation result B.2.4 Index of composite data element by name TAG Name S503 Algorithm parameter S502 Security algorithm S501 Security date and time S500 Security identification details S505 Service character for signature S508 Validation result B.2.5 Composite data element specifications -------------------------------------------------------------- S500 SECURITY IDENTIFICATION DETAILS Desc: Identification of parties involved in the security process. POS TAG Name S Repr. Notes 010 0577 Security party qualifier M an..3 020 0538 Key name C an..35 030 0511 Security Party identification C an..17 1 040 0513 Security party code list qualifier C an..3 1 050 0515 Security party code list responsible agency, coded C an..3 1 060 0586 Security party name C an..35 070 0586 Security party name C an..35 080 0586 Security party name C an..35 DEPENDENCY NOTES: 1. D2 (030, 040, 050) All or none -------------------------------------------------------------- S501 SECURITY DATE AND TIME Desc: Security related date and time. POS TAG Name S Repr. Notes 010 0517 Date and time qualifier M an..3 020 0338 Event date C n..8 030 0314 Event time C an..15 040 0336 Time offset C n4 -------------------------------------------------------------- -------------------------------------------------------------- S502 SECURITY ALGORITHM Desc: Identification of a security algorithm. POS TAG Name S Repr. Notes 010 0523 Use of algorithm, coded M an..3 020 0525 Cryptographic mode of operation, coded C an..3 1,3 030 0533 Mode of operation code list identifier C an..3 1,4 040 0527 Algorithm, coded C an..3 2,3 050 0529 Algorithm code list identifier C an..3 2 DEPENDENCY NOTES: 1. D5 (030, 020) If first, then all 2. D5 (050, 040) If first, then all 3. D5 (020, 040) If first, then all NOTES: 4. 0533, a mode of operation shall be chosen in relation to the chosen algorithm (data element 0527). Some combinations of mode of operation and algorithm are not appropriate. -------------------------------------------------------------- S503 ALGORITHM PARAMETER Desc: Parameter required by a security algorithm. POS TAG Name S Repr. Notes 010 0531 Algorithm parameter qualifier M an..3 020 0554 Algorithm parameter value M an..512 -------------------------------------------------------------- S505 SERVICE CHARACTER FOR SIGNATURE Desc: Identification of the characters used as syntactical service characters when a signature was computed. POS TAG Name S Repr. Notes 010 0551 Service character for signature qualifier M an..3 020 0548 Service character for signature M an..4 -------------------------------------------------------------- -------------------------------------------------------------- S508 VALIDATION RESULT Desc: Result of the application of the security mechanism. POS TAG Name S Repr. Notes 010 0563 Validation value qualifier M an..3 020 0560 Validation value C an..256 1 NOTES: 1. 0560, the length of this data element shall be determined by the characteristics of the cryptographic algorithm used to compute the validation value and the filter function applied to the result. ---------------------------------------------------------------------- B.3 Simple data element directory B.3.1 Legend TAG The tag for the simple data element. All service simple data elements 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 TAG Name 0501 Security service, coded 0503 Response type, coded 0505 Filter function, coded 0507 Original character set encoding, coded 0509 Role of security provider, coded 0511 Security party identification 0513 Security party code list qualifier 0515 Security party code list responsible agency, coded 0517 Date and time qualifier 0519 Compression function, coded 0520 Security sequence number 0523 Use of algorithm, coded 0525 Cryptographic mode of operation, coded 0527 Algorithm, coded 0529 Algorithm code list identifier 0531 Algorithm parameter qualifier 0533 Mode of operation code list identifier 0534 Security reference number 0536 Certificate reference 0538 Key name 0541 Scope of security application, coded 0543 Certificate original character set repertoire, coded 0545 Certificate syntax version, coded 0546 User authorisation level 0548 Service character for signature 0551 Service character for signature qualifier 0554 Algorithm parameter value 0560 Validation value 0563 Validation value qualifier 0567 Security status, coded 0569 Revocation reason, coded 0577 Security party qualifier 0586 Security party name B.3.3 Index of simple data element by name TAG Name 0529 Algorithm code list identifier 0531 Algorithm parameter qualifier 0554 Algorithm parameter value 0527 Algorithm, coded 0543 Certificate original character set repertoire, coded 0536 Certificate reference 0545 Certificate syntax version, coded 0519 Compression function, coded 0525 Cryptographic mode of operation, coded 0517 Date and time qualifier 0505 Filter function, coded 0538 Key name 0533 Mode of operation code list identifier 0507 Original character set encoding, coded 0503 Response type, coded 0569 Revocation reason, coded 0509 Role of security provider, coded 0541 Scope of security application, coded 0513 Security party code list qualifier 0515 Security party code list responsible agency, coded 0511 Security party identification 0586 Security party name 0577 Security party qualifier 0534 Security reference number 0520 Security sequence number 0501 Security service, coded 0567 Security status, coded 0548 Service character for signature 0551 Service character for signature qualifier 0523 Use of algorithm, coded 0546 User authorisation level 0560 Validation value 0563 Validation value qualifier Only simple data elements not defined in other parts of this international Standard are included here. B.3.4 Service code list directory Unless otherwise specified, code values shall be found in the UNTDID Service Code List Directory. B.3.5 Simple data element specifications -------------------------------------------------------------- 0501 SECURITY SERVICE, CODED Desc: Specification of the security service applied. Repr: an..3 -------------------------------------------------------------- 0503 RESPONSE TYPE, CODED Desc: Specification of the type of response expected from the recipient. Repr: an..3 -------------------------------------------------------------- 0505 FILTER FUNCTION, CODED Desc: Identification of the filtering function used to reversibly map any bit pattern on to a restricted character set. Repr: an..3 -------------------------------------------------------------- 0507 ORIGINAL CHARACTER SET ENCODING, CODED Desc: Identification of the character set in which the secured entity was coded when security mechanisms were applied. Repr: an..3 -------------------------------------------------------------- 0509 ROLE OF SECURITY PROVIDER, CODED Desc: Identification of the role of the security provider in relation to the secured item. Repr: an..3 -------------------------------------------------------------- 0511 SECURITY PARTY IDENTIFICATION Desc: Identification of a party involved in the security process, according to a defined registry of security parties. Repr: an..17 -------------------------------------------------------------- 0513 SECURITY PARTY CODE LIST QUALIFIER Desc: Identification of the type of identification used to register the security parties. Repr: an..3 -------------------------------------------------------------- 0515 SECURITY PARTY CODE LIST RESPONSIBLE AGENCY, CODED Desc: Identification of the agency in charge of registration of the security parties. Repr: an..3 -------------------------------------------------------------- 0517 DATE AND TIME QUALIFIER Desc: Specification of the type of date and time. Repr: an..3 -------------------------------------------------------------- 0519 COMPRESSION FUNCTION, CODED Desc: Specification of compression function. Repr: an..3 -------------------------------------------------------------- 0520 SECURITY SEQUENCE NUMBER Desc: Sequence number assigned to the EDIFACT structure to which security is applied. Repr: an..35 Note 1: This sequence number is security related and may differ from the identification of the EDIFACT structure that may appear elsewhere. It may be used when sequence integrity is required. -------------------------------------------------------------- 0523 USE OF ALGORITHM, CODED Desc: Specification of the usage made of the algorithm. Repr: an..3 -------------------------------------------------------------- 0525 CRYPTOGRAPHIC MODE OF OPERATION, CODED Desc: Specification of the mode of operation used for the algorithm. Repr: an..3 -------------------------------------------------------------- 0527 ALGORITHM, CODED Desc: Identification of the algorithm. Repr: an..3 -------------------------------------------------------------- 0529 ALGORITHM CODE LIST IDENTIFIER Desc: Specification of the code list used to identify the algorithm. Repr: an..3 -------------------------------------------------------------- 0531 ALGORITHM PARAMETER QUALIFIER Desc: Specification of the type of parameter value. Repr: an..3 -------------------------------------------------------------- 0533 MODE OF OPERATION CODE LIST IDENTIFIER Desc: Specification of the code list used to identify the cryptographic mode of operation. Repr: an..3 -------------------------------------------------------------- 0534 SECURITY REFERENCE NUMBER Desc: Unique reference number assigned by the security originator to a pair of security header and security trailer groups. Repr: an..14 Note 1: The value shall be arbitrarily assigned, but the same value shall not be used more than once within the same EDIFACT structure, i.e.interchange, group, message or package. -------------------------------------------------------------- 0536 CERTIFICATE REFERENCE Desc: Identifies one certificate for a certification authority. Repr: an..35 -------------------------------------------------------------- 0538 KEY NAME Desc: Name used to establish a key relationship between the parties. Repr: an..35 -------------------------------------------------------------- 0541 SCOPE OF SECURITY APPLICATION, CODED Desc: Specification of the scope of application of the security service defined in the security header. Repr: an..3 Note 1: It defines the data that have to be taken into account by the related cryptographic process. -------------------------------------------------------------- 0543 CERTIFICATE ORIGINAL CHARACTER SET REPERTOIRE, CODED Desc: Identification of the character set repertoire used to create the certificate it was signed. Repr: an..3 -------------------------------------------------------------- 0545 CERTIFICATE SYNTAX VERSION, CODED Desc: Coded identification of the syntax version used to create the certificate. Repr: an..3 -------------------------------------------------------------- 0546 USER AUTHORISATION LEVEL Desc: Specification of the authorisation level associated with the owner of the certificate. Repr: an..35 -------------------------------------------------------------- 0548 SERVICE CHARACTER FOR SIGNATURE Desc: Service character used when the signature was computed. Repr: an..4 Note 1: In order to avoid translator problems, this service character is represented by its value in the character set identified by the original character set encoding data element (0507), hexa-filtered on, at least, two characters. For example the service character "'" is coded "27" (two characters), if ASCII 8bit code page is used. -------------------------------------------------------------- 0551 SERVICE CHARACTER FOR SIGNATURE QUALIFIER Desc: Identification of the type of service character used when the signature was computed. Repr: an..3 -------------------------------------------------------------- 0554 ALGORITHM PARAMETER VALUE Desc: Value of a parameter required by the algorithm. Repr: an..512 Note 1: If necessary, this value shall be filtered by an appropriate filter function. Note that key names do not need to be filtered. -------------------------------------------------------------- 0560 VALIDATION VALUE Desc: Security result corresponding to the security function specified. Repr: an..256 Note 1: If necessary, this value shall be filtered by an appropriate filter function. ------------------------------------------------------------------ 0567 SECURITY STATUS, CODED Desc: Identification of the security element (key or certificate, for instance) status. Repr: an..3 -------------------------------------------------------------- 0569 REVOCATION REASON, CODED Desc: Identification of the reason why the certificate has been revoked. Repr: an..3 -------------------------------------------------------------- 0577 SECURITY PARTY QUALIFIER Desc: Identification of the role of the security party. Repr: an..3 -------------------------------------------------------------- 0586 SECURITY PARTY NAME Desc: Name of the security party. Repr: an..35 -------------------------------------------------------------- ANNEX C (informative) SECURITY THREATS AND SOLUTIONS This annex describes the generic security threats to message/package transmission, between the originator(s) of the message/package and the recipient(s). The general approaches to overcome these threats are also covered. These threats and solutions are relevant at any level: message/package, group or interchange. C.1 Security threats The storage and transfer of EDIFACT messages/packages via electronic media and means expose them to a number of threats, notably: * the unauthorized disclosure of message/package content * the intentional insertion of non-bonafide messages/packages * the duplication, loss or replay of messages/packages * the modification of message/package content * the deletion of messages/packages * the repudiation of message/package responsibility by its sender or its receiver These threats may be intentionally perpetrated, as with the unauthorized manipulation of message/package content, or unintentionally perpetrated, as with a communication error resulting in the modification of message/package content. C.2 Security solutions - basic services and principles of usage To counter the aforementioned threats a number of security mechanisms have been identified which utilize one or more methodologies to meet their objectives. It is important to be able to identify unambiguously the entities involved when messages/packages are secured - the security originator, henceforth called the sender for simplicity, who secures the message/package prior to transmission, and the security recipient, henceforth called the receiver, who performs checks on the received message/package. These entities may be identified in the security segments. This identification may be performed by means of so-called certificates, (in fact, either the certificate itself or the certificate identifier), explained below, if asymmetric algorithms are used. Typically, the use of a certification authority (CA) is required in an open system. This is a third party which is trusted by the involved parties to a limited degree, namely to identify and register all users with their public key. This information is conveyed to other users by means of a certificate, which is a digital signature issued by the CA on a message which consists of user identification information and the user's public key. In this situation, the trust is purely functional and does not involve secret or private keys. Alternatively, if symmetric techniques are used the identity of the parties involved would be indicated in the security sender/recipient name fields. A message/package may be secured by several entities (for example a message/package may have multiple digital signatures) and so the security related information may be repeated to allow the identification of several signing or authenticating entities and correspondingly to include several digital signatures or control values. The requirements and techniques prescribed for securing EDIFACT messages/packages, groups or interchanges are presented below. C.2.1 Sequence integrity Sequence integrity protects against the duplication, addition, deletion, loss or replay of a EDIFACT structure (message/package, group or interchange). To detect lost messages/packages, groups or interchanges - the sender may include and the receiver check a sequence number (related to the message/package flow between the two parties concerned); - the sender may request and check an acknowledgement. To detect added or duplicated messages/packages, groups or interchanges - the sender may include and the receiver check a sequence number. - the sender may include and the receiver check a time stamp. When sequence numbers are used it shall be agreed between the parties how these are to be managed. The timestamp will normally be produced by the sender's system. This implies, as in the paper world, that the initial accuracy of the value of the timestamp is solely under the control of the sender. In order to give full protection, the integrity of timestamp or sequence number shall be guaranteed by one of the other functions mentioned below. C.2.2 Content integrity Content integrity protects against the modification of data. Protection may be achieved by the sender including an integrity control value. This value may be computed by using an appropriate cryptographic algorithm, such as an MDC (Modification Detection Code). As this control value in itself is unprotected, additional measures, such as forwarding the control value by a separate channel or calculating a digital signature, to actually provide non-repudiation of origin, on the control value are necessary. Alternatively, origin authentication, which is obtained using a message authentication code, will imply content integrity. The receiver computes the integrity control value of the data actually received using the corresponding algorithms and parameters and compares the result with the value received. In conclusion, content integrity in EDI is typically obtained as a sub-product of origin authentication or non-repudiation of origin. C.2.3 Origin authentication Origin authentication protects the receiver against the actual sender of a message/package, group or interchange claiming to be some other (authorized) entity. Protection may be achieved by including an authentication value (for example, MAC: message authentication code). The value depends both on the data content and on a secret key in the possession of the sender. This service may include content integrity and may be obtained as a sub-product of non-repudiation of origin. In most cases, it would be desirable to have at least origin authentication. C.2.4 Non-repudiation of origin Non-repudiation of origin protects the receiver of a message/package, group or interchange from the sender's denial of having sent it. Protection may be achieved by including a digital signature (or by using an appropriate implementation of the function described under "origin authentication" based on tamper resistant hardware or trusted third parties). A digital signature is obtained by encrypting, with an asymmetric algorithm and a private key, the object or a control value derived from the data (by using a hash function, for example). The digital signature may be verified by using the public key which corresponds to the private key used to create it. This public key may be included with the interchange agreement signed by the parties or be included in a certificate digitally signed by a certification authority. The certificate may be sent as part of the EDIFACT structure. The digital signature provides not only non-repudiation of origin but also content integrity and origin authentication. C.2.5 Non-repudiation of receipt Non-repudiation of receipt protects the sender of a message/package, group or interchange from the receiver's denial of having received it. Protection may be achieved by the receiver sending an acknowledgement which includes a digital signature based on the data in the original EDIFACT structure. The acknowledgement takes the form of a service message from the receiver to the sender. C.2.6 Confidentiality of content Confidentiality of content protects against the unauthorized reading, copying or disclosure of the content of a message/package, group or interchange. Protection may be assured by encrypting the data. Encryption may be performed by using a symmetric algorithm with a secret key shared by the sender and the receiver. However the secret key may be transmitted securely by encrypting it under the receiver's public key using an asymmetric algorithm. Confidentiality is being addressed separately in a subsequent part of this International Standard. C.2.7 Interrelation among security services As noted already, some services by nature encompass other services, and it is thus not necessary to additionally include the services which are achieved implicitly. For example, the use of the mechanism to provide non-repudiation of origin implies content integrity. The following table summarizes these interrelations: Content Origin Non- also implies: Integrity Authentication repudiation of origin Use of: Content Integrity yes Origin Authentication yes yes Non-repudiation of origin yes yes yes ANNEX D (informative) HOW TO PROTECT AN EDIFACT STRUCTURE The following are some of the more fundamental steps to be taken in order to implement security for EDIFACT structures: messages/packages, groups or interchanges. For further details and explanation of principles, refer to Annex C of the present standard, ISO 7498-2 and CCITT X.509. The first step is to identify (in co-operation with business associates) the need for security services. The security services available in the EDIFACT world are revisited below, and it is important to establish which of these are required in the business relations to prevent the identified threats. Typically, the needs could be defined by the request for auditing, internally as well as externally. The basic security services available at the sender's end are the following: - content integrity - origin authentication - non-repudiation of origin These services are not independent, and it is thus not necessary to additionally include the services which are achieved implicitly. For example, the use of the non-repudiation of origin service implicitly achieves content integrity. These relations are summarized in the interrelation table of Annex C, section C.2.7. Consequently, the sender would choose at most one service of the three. Non-repudiation of receipt is a service to be initiated by the receiver. It could either be requested explicitly by the sender or mandated in an interchange agreement. A message, AUTACK, has been developed to convey the receipt. D.1 Bilateral agreement/third party If security services are being integrated, additional agreements have to be set up with the business partners. There are a number of different approaches available, of which two extremes are briefly presented here. A minimal requirement would be a bilateral agreement with each individual partner, agreeing on security services, algorithms, codes, key management methods, actions in case of misconduct, etc. A draft of such an agreement is available from the EC TEDIS programme. In this case, very little security-related information needs to be included in the message/package itself. The other extreme would be to involve a third party acting as a certification authority, which registers all users and issues certificates to certify the users' public keys. In this situation, it may be adequate simply to conclude an agreement with the certification authority. The certification authority would typically be responsible for blacklisting as well. In this case, more comprehensive security-related information may need to be included. The security services have been integrated into the EDIFACT setting in a manner that offers maximum flexibility, and caters for both extremes described above, as well as for any intermediate situation. D.2 Practical aspects There are, of course, a number of different aspects that need to be addressed in order to realize these security services, such as key generation, the need for a translator capable of handling security segments, internal procedures to make full use of the security services, such as storing incoming messages/packages with digital signatures, the use of multiple signatures, etc. It shall be emphasized that integration of security services is completely transparent to, and independent of, the communication protocols used. If a system allows the transmission of an EDIFACT message/package, it will also allow the transmission of a secured EDIFACT message/package. D.3 Procedure for constructing a secured EDIFACT structure First, an EDIFACT structure message/package, group or interchange is created. Then the appropriate security services are determined and applied. If these are based on digital signatures, the persons possessing the private keys have to be involved, directly or indirectly. This does not have to take place immediately after the generation of the EDIFACT structure. Likewise, on incoming EDIFACT structures, the first step would be to verify the security services , and, just as in the paper world, possibly to store the secured EDIFACT structure for later auditing and documentation. D.4 Security services sequence of application The order in which the security services are performed is left entirely to the users as all services may be completely independent of each other. In particular, if multiple signatures are used, without embedding of security header and security trailer groups, the order in which they are calculated, and verified, is of no consequence. D.5 Separated message security at message/package level There are two business requirements for this feature, namely 1) to provide security for one or more messages/packages in a single separate message from the sender, 2) to provide a secured acknowledgement to the sender for having received the original message/package(s), without returning them. These requirements may be met by the secure authentication and acknowledgement message, AUTACK which is described in Part 6 of the present International Standard. D.5.1 Separated message security used by sender This use of the AUTACK allows the sender to provide any security service but forwarded in a separate message. Thus the security services may be communicated at a later or more appropriate stage. Additionally they may secure several original messages/packages, in contrast to direct integration, at message/package level, which secures one message/package at a time. The principles are identical for the integrated and separated approaches, but the latter requires a unique reference to the original message/package(s) being secured. D.5.2 Separated message security used by receiver This use of the AUTACK addresses the requirement to provide non- repudiation of receipt. For a detailed description of the message, refer to AUTACK itself in Part 6 of the present International Standard. The AUTACK may be used as a secured acknowledgement sent by the receiver of one or more interchanges or one or more messages/packages from one or more interchanges to their sender. The criteria and means by which an AUTACK is generated provide the sender of the original message/package(s) or interchange(s) with secured acknowledgement that it was received by the intended party. D.6 Separated message security at group or interchange levels The technique described as separated message/package security, in section D.5 at message/package level, may be used to secure complete groups or complete interchanges. The two business requirements for this feature, are: 1) to provide security for one or more group or interchange in a single separate message from the sender, 2) to provide a secured acknowledgement to the sender for having received the original group(s) or interchange(s), without returning them. These requirements may be met by the secure authentication and acknowledgement message, AUTACK described in Part 6 of this International Standard. ANNEX E (informative) MESSAGE PROTECTION EXAMPLES Three examples are provided herein to illustrate different application of security service segments. These examples of message security are based on EDIFACT payment orders as described in the MIG handbook of Financial messages published by SWIFT, with similar presentation rules. However, the security mechanisms described here are totally independent of the type of message and may be applied to any EDIFACT message. "Example 1: message Origin Authentication" shows how security service segments may be used when a symmetric algorithm based method is applied, to provide message origin authentication. The symmetric key has been exchanged previously between the partners, and the security header group contains only two rather simple segments. "Example 2: non repudiation of origin, first technique" shows how security service segments may be used when an asymmetric algorithm based method is applied, to provide non repudiation of origin. The algorithm applied directly to the message is a hash-function, which does not require any key exchange between the partners. The hash-value is signed by an asymmetric algorithm. The public key needed by the receiver to verify the signature of the message is included in a certificate segment which is conveyed in the security header group of the message. This certificate is signed by its issuer (the "authority") and contains the public key of the authority, in order that any partner may verify the integrity and authenticity of the certificate. "Example 3: non repudiation of origin, second technique" shows how security service segments may be used when an asymmetric algorithm based method is applied, to provide non repudiation of origin. The algorithm applied directly to the message is a symmetric algorithm, which requires a symmetric key exchange between the partners, and provides an "integrity value". This symmetric key is exchanged within the security header group of the message, encrypted by means of an asymmetric algorithm, under the public key of the expected receiver. The integrity value is signed by an asymmetric algorithm. The public key needed by the receiver to verify the signature of the message is included in the first certificate segment which is conveyed in the security header group of the message. This certificate is signed by its issuer (the "authority") and contains the public key of the authority, in order that any partner may verify the integrity and authenticity of the certificate. A second certificate segment contains the reference to the public key of the expected receiver, used by the message sender to protect the symmetric key. This technique is currently used by the French banks in the ETEBAC 5 system (secured file transfer between banks and corporate customers). In the last two examples, any partner, trusting the authority, may verify the signature of the received message using only data contained in the message. E.1 Example 1: message origin authentication E.1.1 Narrative Company A orders Bank A, sort code 603000 to debit its account number 00387806 on April 9th 1996 in the amount of 54345.10 Pounds Sterling. The amount is to be paid to Bank B, sort code 201827, in favour of account number 00663151 of Company B, West Dock, Milford Haven. The payment is in settlement of invoice 62345. The contact name at the Beneficiary is Mr. Jones in the Sales Department. Bank A requires the payment order to be secured by the security function "message origin authentication". This is achieved by generating a "Message Authentication Code" (MAC) with the symmetric "Data Encryption Algorithm" (DEA) according to ISO 8731-1 at the message sender's side, which is to be validated by Bank A. It is assumed that the secret DEA-key has previously been exchanged between Company A and Bank A. Remark: In the following, only the security relevant parts of the message will be referred to. E.1.2 Security details SECURITY HEADER SECURITY SERVICE Message origin authentication SECURITY REFERENCE The reference of this header is 1 NUMBER FILTER FUNCTION All binary values (MAC) are filtered with hexadecimal filter ORIGINAL CHARACTER SET The message was coded in ASCII 8 bits ENCODING when the MAC was generated. SECURITY IDENTIFICATION DETAILS Message sender (party Mr. SMITH of Company A which generates the Message Authentication Code). SECURITY IDENTIFICATION DETAILS Message receiver (party Bank A which verifies the Message Authentication Code). SECURITY SEQUENCE The security sequence number of this NUMBER message is 001 SECURITY DATE AND TIME The security time stamp is : date: 1996 04 09 time: 13:59:50 SECURITY ALGORITHM SECURITY ALGORITHM Use of algorithm A symmetric algorithm is used to achieve message origin authentication. Cryptographic mode of A MAC is computed, according to ISO 8731- operation 1. Algorithm The DES algorithm is used. ALGORITHM PARAMETER Algorithm parameter Identifies the preceding algorithm qualifier parameter value as the name of a previously exchanged symmetric key. Algorithm parameter The key called MAC-KEY1 is used. value SECURITY TRAILER SECURITY REFERENCE The reference of this trailer is 1 NUMBER SECURITY RESULT VALIDATION RESULT Validation value MAC qualifier 4 Byte validation result (Message Validation value Authentication Code) E.2 Example 2: non-repudiation of origin, first technique E.2.1 Narrative Bank A wants the security service of non repudiation of origin on the payment order from Company A, performed by Mr. Smith. The interchange agreement between the parties establishes that the security service of non repudiation of origin, required by Bank A, shall be achieved for payment orders, by Mr. Smith of Company A, with the use of one digital signature. The certificate identifying the public key of Mr. Smith is issued by an authority trusted by both parties, the certificate issuer. E.2.2 Security details SECURITY HEADER SECURITY SERVICE Non repudiation of origin SECURITY REFERENCE NUMBER The reference of this header is 1 RESPONSE TYPE No acknowledgement required FILTER FUNCTION All binary values (signatures) are filtered with hexadecimal filter ORIGINAL CHARACTER SET The message was coded in ASCII 8 ENCODING bits when its signature was generated. SECURITY SEQUENCE NUMBER The security sequence number of this message is 202. SECURITY DATE AND TIME The security time stamp is : date: 1996 01 15 time: 10:05:30 SECURITY ALGORITHM Hash function used by Mr. SMITH for signature SECURITY ALGORITHM Use of algorithm An owner hashing algorithm is used. Cryptographic mode of Hash function CD 10118-2 Hash operation functions using a n- bit block cipher algorithm applied to provide a double length hash code (128 bits); initializing values: IV = 0F 0F 0F 0F 0F 0F 0F 0F IV' = F0 F0 F0 F0 F0 F0 F0 F0; padding rules as first variant Algorithm paragraph B.3.1 of the standard; transformation u and u' as specified in annex A of the standard. DES block cipher algorithm is used. CERTIFICATE certificate of Mr. SMITH CERTIFICATE REFERENCE This certificate is referenced, by AUTHORITY: 00000001. SECURITY IDENTIFICATION DETAILS Certificate owner Mr. SMITH of Company A SECURITY IDENTIFICATION DETAILS Mr. SMITH's certificate was Certificate issuer generated by a certification Authority called: AUTHORITY. Key name The Public Key of AUTHORITY used to generate Mr. SMITH's certificate is PK1 CERTIFICATE SYNTAX VERSION Version of certificate of UN/EDIFACT service segment directory. FILTER FUNCTION All binary values (keys and digital signatures) are filtered with hexadecimal filter ORIGINAL CHARACTER SET The credentials of the certificate ENCODING were coded in ASCII 8 bits when the certificate was generated. SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is segment Service character for terminator. signature Value "'" (apostrophe). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is data element Service character for separator. signature Value "+" (plus sign). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is component data Service character for element separator. signature Value ":" (colon). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is repetition Service character for separator. signature Value "*" (asterisk). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is release Service character for character. signature Value "?" (question mark). SECURITY DATE AND TIME Certificate generation time Date and time Mr. SMITH certificate was generated on 931215 at 14:12:00 SECURITY DATE AND TIME Certificate start of validity Date and time period Validity period of Mr. SMITH's starts: 1996 01 01 000000 SECURITY DATE AND TIME Certificate end of validity period Date and time Validity ends of Mr. SMITH's starts: 1996 12 31 235959 SECURITY ALGORITHM Asymmetric algorithm used by Mr. SMITH to sign SECURITY ALGORITHM Use of algorithm An owner signing algorithm is used. Cryptographic mode of No mode of operation is relevant operation here. Algorithm RSA is the asymmetric algorithm. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a Public exponent for signature verification. Algorithm parameter value Mr SMITH's public key. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a Modulus for signature verification. Algorithm parameter value Mr SMITH's modulus. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as the length of Mr SMITH's modulus (in bits). Algorithm parameter value Mr SMITH's modulus is 512 bits long. SECURITY ALGORITHM Hash function used by AUTHORITY to generate Mr SMITH's certificate SECURITY ALGORITHM Use of algorithm An issuer hashing algorithm is Cryptographic mode of used. operation Hash function CD 10118-2 Hash functions using a n- bit block cipher algorithm applied to provide a double length hash code (128 bits); initializing values: IV = 0F 0F 0F 0F 0F 0F 0F 0F IV' = F0 F0 F0 F0 F0 F0 F0 F0; Algorithm padding rules as first variant paragraph B.3.1 of the standard; transformation u and u' as specified in annex A of the standard. DES block cipher algorithm is used. SECURITY ALGORITHM Asymmetric algorithm used by AUTHORITY to sign SECURITY ALGORITHM Use of algorithm An issuer signing algorithm is Cryptographic mode of used. operation No mode of operation is relevant Algorithm here. RSA is the asymmetric algorithm. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a public exponent for signature verification. Algorithm parameter value AUTHORITY's public key. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a Modulus for signature verification. Algorithm parameter value AUTHORITY's modulus. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as the length of AUTHORITY's modulus (in bits). Algorithm parameter value AUTHORITY's modulus is 512 bits long. SECURITY RESULT Digital signature of the certificate VALIDATION RESULT Validation value qualifier Digital signature Validation value 512 Bit digital signature SECURITY TRAILER SECURITY REFERENCE NUMBER The reference of this security trailer is 1 SECURITY RESULT Digital signature of the message VALIDATION RESULT Validation value qualifier Digital signature Validation value 512 Bit digital signature E.3 Example 3: non-repudiation of origin, second technique E.3.1 Narrative Bank A wants the security service of non repudiation of origin on the payment order from Company A, performed by Mr. Smith. Company A requests a secured acknowledgement by Bank A (non repudiation of receipt) which will be conveyed in an AUTACK message. The interchange agreement between the parties establishes that the security service of non repudiation of origin shall be achieved for payment orders with the use of one digital signature. Both parties agree that this signature is computed by 512 bit RSA (asymmetric algorithm) upon a 64 bit-integrity value computed by CBC mode DES (symmetric algorithm).The certificate identifying the public key of Mr. Smith is issued by an authority trusted by both parties. E.3.2 Security details SECURITY HEADER SECURITY SERVICE Non repudiation of origin SECURITY REFERENCE NUMBER The reference of this header is 1 RESPONSE TYPE Acknowledgement required FILTER FUNCTION All binary values (signatures) are filtered by hexadecimal filter ORIGINAL CHARACTER SET The message was coded in ASCII 8 ENCODING bits when its signature was generated. SECURITY IDENTIFICATION DETAILS Message sender (party Mr. SMITH of Company A securing the message). SECURITY IDENTIFICATION DETAILS Message receiver (party Bank A verifying message security). SECURITY SEQUENCE NUMBER The security sequence number of this message is 001. SECURITY DATE AND TIME The security time stamp is : date: 1996 01 15 time: 10:05:30 SECURITY ALGORITHM Symmetric algorithm used to compute an integrity value. SECURITY ALGORITHM Use of algorithm An owner hashing algorithm is used. Cryptographic mode of Cipher Block Chaining; ISO 10116 (n- operation bits). A 64-bit integrity value is computed; initialization value is binary zero; a DEA secret-key is used. It is transmitted encrypted Algorithm under Bank A public key. DES block cipher algorithm is used. ALGORITHM PARAMETER Algorithm parameter Identifies the preceding algorithm qualifier parameter value as a symmetric key encrypted under a public key. Algorithm parameter value Symmetric key encrypted under Bank A public key. ALGORITHM PARAMETER Algorithm parameter Identifies the preceding algorithm qualifier parameter value as a clear text initialisation value. Algorithm parameter value Clear text initialisation value (all binary 0's). CERTIFICATE Certificate of Mr. SMITH (message sender) CERTIFICATE REFERENCE This certificate is referenced: 00000001, by AUTHORITY. SECURITY IDENTIFICATION DETAILS Mr. SMITH of Company A Certificate owner SECURITY IDENTIFICATION DETAILS Mr. SMITH's certificate was Certificate issuer generated by a certification authority called: AUTHORITY. Key name The Public Key of AUTHORITY used to generate Mr. SMITH's certificate is PK1. CERTIFICATE SYNTAX Version of certificate of UN/EDIFACT VERSION service segment directory. FILTER FUNCTION All binary values (keys and digital signatures) are filtered with hexadecimal filter. ORIGINAL CHARACTER SET The credentials of the certificate ENCODING were coded in ASCII 8 bits when the certificate was generated. SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is segment Service character for terminator. signature Value "'" (apostrophe). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is data element Service character for separator. signature Value "+" (plus sign). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is component data Service character for element separator. signature Value ":" (colon). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is repetition Service character for separator. signature Value "*" (asterisk). SERVICE CHARACTER FOR Service character used when SIGNATURE signature was computed Service character for signature qualifier Service character is release Service character for character. signature Value "?" (question mark). SECURITY DATE AND TIME Certificate generation time Date and time Mr. SMITH certificate was generated on 931215 at 14:12:00 SECURITY DATE AND TIME Certificate start of validity period Date and time Validity period of Mr. SMITH's starts: 1996 01 01 000000 SECURITY DATE AND TIME Certificate end of validity period Date and time Validity period of Mr. SMITH's ends: 1996 12 31 235959 SECURITY ALGORITHM Asymmetric algorithm used by Mr. SMITH to sign SECURITY ALGORITHM Use of algorithm An owner signing algorithm is used. Cryptographic mode of No mode of operation is relevant operation here. Algorithm RSA is the asymmetric algorithm. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a public exponent for signature verification. Algorithm parameter value Mr SMITH's public key. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a modulus for signature verification. Algorithm parameter value Mr SMITH's modulus. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as the length of Mr SMITH's modulus (in bits). Algorithm parameter value Mr SMITH's modulus is 512 bit long. SECURITY ALGORITHM Hash function used by AUTHORITY to generate Mr SMITH's certificate SECURITY ALGORITHM Use of algorithm An issuer hashing algorithm is used. Cryptographic mode of Square-mod n hash function for RSA. operation Annex D, CCITT X509. ISO 9594-8. RSA asymmetric algorithm. Algorithm SECURITY ALGORITHM Asymmetric algorithm is used by AUTHORITY to sign SECURITY ALGORITHM Use of algorithm An issuer signing algorithm is used. Cryptographic mode of No mode of operation is relevant operation here. Algorithm RSA is the asymmetric algorithm. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a public exponent for signature verification. Algorithm parameter value AUTHORITY's public key. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as a modulus for signature verification. Algorithm parameter value AUTHORITY's modulus. ALGORITHM PARAMETER Algorithm parameter Identifies this algorithm parameter qualifier as the length of AUTHORITY's modulus (in bits). Algorithm parameter value AUTHORITY's modulus is 512 bit long. SECURITY RESULT Digital signature of the certificate VALIDATION RESULT Validation value Digital signature qualifier 512 Bit digital signature Validation value CERTIFICATE Certificate of Bank A (message receiver) CERTIFICATE REFERENCE Bank A's public key related to certificate referenced 00001001 is used SECURITY TRAILER SECURITY REFERENCE NUMBER The reference of this security trailer is 1 SECURITY RESULT Digital signature of the message VALIDATION RESULT Validation value Digital signature qualifier 512 Bit digital signature Validation value ANNEX F (informative) UN/EDIFACT CHARACTER SET REPERTOIRE A FILTER FUNCTION: EDA F.1 Rationale Hexadecimal filtering doubles the number of characters required to represent binary data. This is a waste of space. Other existing and standardized filter functions are either not adequate for UN/EDIFACT character set repertoires A and B (ISO 646) because they map to almost the full printable ISO set (94 out of the 96 printable characters), or because they are not really more space- efficient than hexadecimal filtering (the Baudot filter). It is thus advisable to define a filter function which is sufficiently simple and which maps to (a subset of) the UN/EDIFACT level A character set repertoire, while being more efficient than the hexadecimal filter. F.2 UN/EDIFACT character set repertoires The character set repertoire A possesses 44 characters whose use is unrestricted. In addition to those 44, 4 service characters and 8 characters not allowed for TELEX transmissions are part of the set. All those characters are also part of the UN/EDIFACT character set repertoire B, which is not intended at all for TELEX transmission, and which possesses 82 normal characters and 3 non-printable service characters. F.3 3 by 2 filtering To represent 2 binary characters by 3 filtered characters a minimum of 41 characters are required in the set: 41 ** 3 = 68 921 > 65 536 > 64 000 = 40 ** 3 F.4 The EDA filter Having 44 allowed characters, let us avoid use of the space character part of those 44 and filter every pair of input characters (if odd, filter only the last character in 2 resulting ones) by: - considering the binary value of the unsigned integer formed by the pair of characters (this value depends naturally on the LITTLE_ENDIAN / BIG_ ENDIAN (either Least or Most Significant Byte first) nature of the computer in use. Standardize for BIG_ENDIANs: first byte most significant) - represent the value by a succession of 3 numbers (2 for last odd byte), in the range 0 to 42, which are: - the result of the division by 1849 (43 squared) (absent for last odd byte) - the value modulo 1849 divided by 43, - the value modulus 43. - to map each number in the UN/EDIFACT level A alphabet by the correspondence table: 0 to 9 are represented by0 to 9 A to Z are represented by10 to 35 ( ) , - . / = are represented by36 up to 42 in the given order. F.5 Defiltering To defilter: map each of the 43 characters back to its value between 0 and 42,if at least 3 filtered characters remain, compute: cl * 1849 + c2 *43 + c3 = short integer else at least 2 remain so compute: c1 * 43 + c2 = character value. Remarks: a. The short integer result should be < 65 536 b. The character result should be < 256 c. In a LITTLE_ENDIAN computer, switch the 2 characters of the short integer result. ANNEX G (informative) CODE LISTS 0501 Security service, coded Desc: Specification of the security service applied. Repr: an..3 1 Non-repudiation of origin The message includes a digital signature protecting the receiver of the message from the sender's denial of having sent the message. 2 Message origin authentication The actual sender of the message cannot claim to be some other (authorised) entity. 3 Integrity The message content is protected against the modification of data. 4 Confidentiality The message content is protected against the unauthorised reading, copying or disclosure of its content. 5 Non-repudiation of receipt Non-repudiation of receipt protects the sender of an object message from the receiver's denial of having received the message. 6 Receipt authentication Receipt authentication assures the sender that the message has been received by the authenticated recipient. 7 Referenced entity non-repudiation of origin The referenced entity is secured by a digital signature protecting the receiver of the message from the sender's denial of having sent the message. 8 Referenced entity origin authentication The actual sender of the referenced entity cannot claim to be some other (authorised) entity. 9 Referenced entity integrity The referenced entity content is protected against the modification of data. ------------------------------------------------------------------ 0503 Response type, coded Desc: Specification of the type of response expected from the recipient. Repr: an..3 1 No acknowledgement required No AUTACK acknowledgement message expected. 2 Acknowledgement required AUTACK acknowledgement message expected. ------------------------------------------------------------------ 0505 Filter function, coded Desc: Identification of the filtering function used to reversibly map any bit pattern on to a restricted character set. Repr: an..3 1 No filter No filter function is used. 2 Hexadecimal filter Hexadecimal filter. 3 ISO 646 filter ASCII filter as described in DIS 10126-1. 4 ISO 646 Baudot filter Baudot filter as described in DIS 10126-1. 5 UN/EDIFACT level A filter UN/EDIFACT level A filter function as described in Annex F of Part 5 of ISO 9735. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0507 Original character set encoding, coded Desc: Identification of the character set in which the secured entity was coded when security mechanisms were applied. Repr: an..3 1 ASCII 7 bit ASCII 7 bit code. 2 ASCII 8 bit ASCII 8 bit code. 3 EBCDIC IBM 360 IBM 360 machine EBCDIC code. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0509 Role of security provider, coded Desc: Identification of the function of the security provider in relation to the secured item. Repr: an..3 1 Issuer The security provider is the rightful issuer of the signed document. 2 Notary The security provider acts as a notary in relation to the signed document. 3 Contracting party The security provider endorses the content of the signed document. 4 Witness The security provider is a witness, but is not responsible for the content of the signed document. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0513 Security party code list qualifier Desc: Identification of the type of identification used to register the security parties. Repr: an..3 1 ACH Automated clearing house identification. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0515 Security party code list responsible agency, coded Desc: Identification of the agency in charge of registration of the security parties. Repr: an..3 1 UN United Nations. ------------------------------------------------------------------ 0517 Date and time qualifier Desc: Specification of the type of date and time. Repr: an..3 1 Security Timestamp Security timestamp of the secured message. 2 Certificate generation date and time Identifies the date and time of generation of the certificate by the Certification Authority. 3 Certificate start of validity period Identifies the date and time from which the certificate must be considered valid. 4 Certificate end of validity period Identifies the date and time until which the certificate must be considered valid. 5 Message generation date and time Date and time of generation of the secured entity. 6 Certificate revocation date and time Identifies the date and time of revocation of the certificate by the Certification Authority. ------------------------------------------------------------------ 0519 Compression function, coded Desc: Specification of compression function Repr: an..3 1 LZW J. Ziv, A. Lempel, T.A. Welch algorithm. 2 Compress Optimised LZW algorithm. 3 LZSS Optimised LZ77 of J. Ziv, A. Lempel algorithm. 4 LZHuf Haruyasu Yoshizaki algorithm. Combination of LZSS and Hufman coding. 5 ZIP PKZIP algorithm from PKWARE Inc. ------------------------------------------------------------------ 0523 Use of algorithm, coded Desc: Specification of the usage made of the algorithm. Repr: an..3 1 Owner hashing Specifies that the algorithm is used by the message sender to compute the hash function on the message. (as in the case of Non-repudiation of Origin identified in the security function qualifier of USH). 2 Owner symmetric Specifies that the algorithm is used by the message sender either for integrity or message origin authentication (specified by Security function qualifier in USH). 3 Issuer signing Specifies that the algorithm is used by the Certificate Issuer (CA) to sign the hash result computed on the certificate. 4 Issuer hashing Specifies that the algorithm is used by the Certificate Issuer (CA) to compute the hash result on the certificate. 5 Owner enciphering Specifies that the algorithm is used by the message sender to encrypt a symmetric key. 6 Owner signing Specifies that the algorithm is used by the message sender to sign either the hash result computed on the message or the symmetric keys. 7 Owner enciphering or signing Specifies that the algorithm is used by the message sender to encrypt a symmetric key or sign the hash result computed on the message. ------------------------------------------------------------------ 0525 Cryptographic mode of operation, coded Desc: Specification of the mode of operation used for the algorithm. Repr: an..3 1 ECB DES modes of operation, Electronic Code Book; FIPS Pub 81 (1981); ANSI X3.106; IS 8372 (64 bits); ISO 10116 (n-bits). 2 ECB DES modes of operation, Cipher Block Chaining; FIPS Pub 81 (1981); ANSI X3.106; IS 8372 (64 bits); ISO 10116 (n-bits). 3 CFB1 DES modes of operation, Cipher feedback; FIPS Pub 81 (1981); ANSI X3.106; IS 8372 (64 bits); ISO 10116 (n-bits). 4 CFB8 DES modes of operation, Cipher feedback; FIPS Pub 81 (1981); ANSI X3.106; IS 8372 (64 bits); ISO 10116 (n-bits). 5 OFB DES modes of operation. FIPS Pub 81 (1981); IS 8372 (64 bits); ISO 10116 (n-bits). 6 MAC Message Authentication Code ISO 8731-1, using DES CBC mode. 7 DIM1 Data integrity mechanism using a cryptographic check function; ISO DIS 9797, first method. 8 DIM2 Data integrity mechanism using a cryptographic check function; ISO DIS 9797, second method. 9 MDC2 Modification Detection Code - IBM System Journal, vol 30,no 2, 1991. 10 HDS1 Hash functions - Part 2 : Hash functions using a n- bit block cipher algorithm providing a single length hash code. ISO CD 10118-2. 11 HDS2 Hash functions - Part 2 : Hash functions using a n- bit block cipher algorithm providing a double length hash code. ISO CD 10118-2. 12 SQM Square-mod n hash function for RSA. Annex D, CCITT X 509. ISO 9594-8. 13 NVB7.1 Dutch Standard hash function for banking. 14 NVBAK Dutch Banking Standard, NVB Authenticity Mark, published by the NVB, May 1992. 15 MCCP Banking key management by means of asymmetric algorithms, Algorithms using the RSA cryptosystem. Signature construction by means of a separate signature. ISO CD 11166-2. 16 DSMR Digital Signature Scheme Giving message recovery. ISO 9796. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0527 Algorithm, coded Desc: Identification of the algorithm. Repr: an..3 Note: The presence of a particular algorithm in this list does not imply any endorsement of that algorithm. The following algorithms are those currently in common use (November 1995). It is expected that new algorithms will be added as they become available, and are generally accepted. 1 DES Data Encryption Standard. FIPS Pub 46 (January 1977). 2 MAA Message Authentication Algorithm. Banking-Approved Algorithms for message Authentication. ISO 8731-2. 3 FEAL FEAL Fast Data Encipherment Algorithm. 4 IDEA International Data Encryption Algorithm : Lai X., Massey J. "A Proposal for a New Block Encryption Standard", Proceedings of Eurocrypt'90, LNCS vol 473, Springer-Verlag, Berlin 1991, and Lai X., Massey J. "Markov Ciphers and Differential Cryptanalysis", Proceedings of Eurocrypt'91, LNCS vol 547, Springer- Verlag, Berlin 1991. 5 MD4 The MD4 Message digest algorithm. Rivest R. RSA Data Security Inc. (1990). 6 MD5 The MD5 Message digest algorithm. Rivest R. Dusse S. RSA Data Security Inc. (1991). 7 RIPEMD Extension of the MD4 - Ripe Report CS - R9324, April 93. 8 SHA Secure Hashing Algorithm. 9 AR/DFP Hash function of the German banking industry, submitted to ISO/IEC JTC 1/SC 27/WG 2, Doc N179. 10 RSA Rivest, Shamir, Adleman: A Method for obtaining Digital Signatures and Public Key Cryptosystems. Communications of the ACM, Vol.21(2), pp 120-126 (1978). 11 DSA Digital Signature Algorithm/Digital Signature Standard NIST Pub 1993 Draft. 12 RAB Rabin, "Digitalized signatures and public-key functions as intractable as factorization", MIT Laboratory for Computer Science Technical Report LCS/TR-212, Cambridge, Mass, 1979. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0529 Algorithm code list identifier Desc: Specification of the code list used to identify the algorithm. Repr: an..3 1 UN United Nations. ------------------------------------------------------------------ 0531 Algorithm parameter qualifier Desc: Specification of the type of parameter value. Repr: an..3 Note: The generic parameters are provided to allow the use of any algorithm requiring identification of parameters different from the parameters defined above. When the DSA algorithm (NIST, Pub 1993) is used, generic parameter 1 contains parameter "P", generic parameter 2 contains parameter "Q", generic parameter 3 contains parameter "G", generic parameter 4 contains parameter "Y". 1 Initialisation value, cleartext Identifies the algorithm parameter value as an unencrypted initialisation value. 2 Initialisation value, encrypted under a symmetric key Identifies the algorithm parameter value as an initialisation value which is encrypted under the symmetric data key. 3 Initialisation value, encrypted under a public key Identifies the algorithm parameter value as an initialisation value encrypted under the public key of the receiving entity. 4 Initialisation value, format mutually agreed Identifies the algorithm parameter value as an initialisation value in a format agreed between the two parties. 5 Symmetric key, encrypted under a symmetric key Identifies the algorithm parameter value as a symmetric key which is encrypted with a previously agreed algorithm under a previously exchanged symmetric key. 6 Symmetric key, encrypted under a public key Identifies the algorithm parameter value as a symmetric key encrypted under the public key of the receiving entity. 7 Symmetric key, signed and encrypted Identifies the algorithm parameter value as a symmetric key signed under the sender's secret key, then encrypted under the receiver's public key. 8 Symmetric key encrypted under an asymmetric key common to the sender and the receiver Identifies the algorithm parameter value as a symmetric key encrypted under an asymmetric key common to the sender and the receiver (use of Diffie and Hellmann scheme, for instance). 9 Symmetric key name Identifies the algorithm parameter value as the name of a symmetric key. This may be used in the case where a key relationship has already been established between the sender and receiver. 10 Key encrypting key name Identifies the parameter value as the name of a key encrypting key. 11 Symmetric key, format mutually agreed Identifies the algorithm parameter value as a symmetric key in a format agreed between the two parties. 12 Modulus Identifies the algorithm parameter value as the modulus of a public key which is to be used according to the function defined by the use of algorithm. 13 Exponent Identifies the algorithm parameter value as the exponent of a public key which is to be used according to the function defined by the use of algorithm. 14 Modulus Length Identifies the algorithm parameter value as the length of the modulus (in bits) of the public key used in the algorithm. The length is independent of whatever filtering function may be in use. 15 Generic parameter 1 Identifies the algorithm parameter value as the first generic parameter (see note). 16 Generic parameter 2 Identifies the algorithm parameter value as the second generic parameter (see note). 17 Generic parameter 3 Identifies the algorithm parameter value as the third generic parameter (see note). 18 Generic parameter 4 Identifies the algorithm parameter value as the fourth generic parameter (see note). 19 Generic parameter 5 Identifies the algorithm parameter value as the fifth generic parameter (see note). 20 Generic parameter 6 Identifies the algorithm parameter value as the sixth generic parameter (see note). 21 Generic parameter 7 Identifies the algorithm parameter value as the seventh generic parameter (see note). 22 Generic parameter 8 Identifies the algorithm parameter value as the eighth generic parameter (see note). 23 Generic parameter 9 Identifies the algorithm parameter value as the ninth generic parameter (see note). 24 Generic parameter 10 Identifies the algorithm parameter value as the tenth generic parameter (see note). ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0533 Mode of operation code list identifier Desc: Specification of the code list used to identify the cryptographic mode of operation. Repr: an..3 1 UN United Nations. ------------------------------------------------------------------ 0541 Scope of security application, coded Desc: Specification of the scope of application of the security service defined in the security header. Repr: an..3 1 Security header and message body The current security header and the object body itself, only. In this case no other security header or security trailer segment group shall be encompassed within this scope. 2 From security header to security trailer From the current security header, to the associated security trailer. In this case the current security header, the object body and all the other embedded security headers and trailers shall be encompassed within this scope. 3 Whole related message, group, or interchange From the first character of the message, group, or interchange to the last character of the message, group or interchange. ZZZ Mutually agreed The scope of security application is defined in an agreement between sender and receiver. ------------------------------------------------------------------ 0543 Certificate original character set repertoire, coded Desc: Identification of the syntax level used to create the certificate when it was signed. Repr: an..3 1 UN/ECE syntax level A As defined in ISO 9735. 2 UN/ECE syntax level B As defined in ISO 9735. 3 UN/ECE syntax level C As defined in ISO 8859-1 : Information processing - Part 1: Latin alphabet No. 1. 4 UN/ECE syntax level D As defined in ISO 8859-2 : Information processing - Part 2: Latin alphabet No. 2. 5 UN/ECE syntax level E As defined in ISO 8859-5 : Information processing - Part 5: Latin/Cyrillic alphabet. 6 UN/ECE syntax level F As defined in ISO 8859-7 : Information processing - Part 7: Latin/Greek alphabet. 7 UN/ECE syntax level G As defined in ISO 8859-3 : Information processing - Part 3: Latin alphabet. 8 UN/ECE level H As defined in ISO 8859-4 : Information processing - Part 4: Latin alphabet. 9 UN/ECE level I As defined in ISO 8859-6 : Information processing - Part 6: Latin/Arabic alphabet. 10 UN/ECE level J As defined in ISO 8859-8 : Information processing - Part 8: Latin/Hebrew alphabet. 11 UN/ECE level K As defined in ISO 8859-9 : Information processing - Part 9: Latin alphabet. 12 UN/ECE level X Code extension technique as defined by ISO 2022 utilising the escape techniques in accordance with ISO 2375. 13 UN/ECE level Y ISO 10646 2 octet without code extension technique. ------------------------------------------------------------------ 0545 Certificate syntax version, coded Desc: Coded identification of the syntax version used to create the certificate. Repr: an..3 1 Version 4 ISO 9735 version 4. ------------------------------------------------------------------ 0551 Service character for signature qualifier Desc: Identification of the type of service character used when the signature was computed. Repr: an..3 1 Segment terminator Specifies that this is the separator at the end of segments. 2 Component data element separator Specifies that this is the separator between component data elements. 3 Data element separator Specifies that this is the separator between data elements. 4 Release character Specifies that this is the release character. 5 Repetition separator Specifies that this is the separator between repeating data elements. ------------------------------------------------------------------ 0567 SECURITY STATUS, CODED Desc: Identification of the security element (key or certificate, for instance) status. Repr: an..3 1 Valid The security element is valid. 2 Revoked The security element has been revoked. 3 Unknown The status of the security element is unknown. 4 Discontinued The security element should not be used for 5 Alert The security element has been put on alert, but is not revoked yet. 6 Expired The validity period of the security element is expired. ------------------------------------------------------------------ 0569 REVOCATION REASON, CODED Desc: Identification of the reason why the certificate has been revoked. Repr: an..3 1 Owner key compromised The owner key linked to this certificate has been compromised. 2 Issuer key compromised The issuer key used to generate this certificate has been compromised. 3 Owner changed affiliation The identification details of the certificate are no longer valid. 4 Certificate superseded This certificate has been renewed and is superseded by an other certificate. 5 Certificate terminated This certificate has reached the end of its validity period and has not been renewed. ZZZ Mutually agreed Self explanatory. ------------------------------------------------------------------ 0577 Security party qualifier Desc: Specification of the role of the security party. Repr: an..3 1 Message sender Identifies the party which generates the security parameters of the message (i.e. security originator). 2 Message receiver Identifies the party which verifies the security parameters of the message (i.e. security recipient). 3 Certificate Owner Identifies the party which owns the Certificate. 4 Authenticating party Party which certifies that the document (i.e. the certificate) is authentic. ------------------------------------------------------------------