Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping

Transcription

1 Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping Montserrat Rubia, UPC Juan Carlos Cruellas, UPC Manel Medina, UPC Isabel Gallego, UPC Damian Rodríguez, INDRA Fritz Bausspieá, R3 Petra Gloeckner, GMD Technical Report UPC-DAC , July 1997

2 Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping Montserrat Rubia, UPC Juan Carlos Cruellas, UPC Manel Medina, UPC Isabel Gallego, UPC Damian Rodríguez, INDRA Fritz Bausspieá, R3 Petra Gloecknet, GMD Departament of Computer Architecture Universitat Politècnica de Catalunya Barcelona, Spain Abstract EDI users require the use of security services, like non-repudiation of origin, data integrity, and even confidentiality of the interchanged messages. These functions require the use of electronic digital signatures, based on public key infrastructure, in order to allow the certification of the users s public keys. The current security messages developed within UN/EDIFACT include a specification of a public key certificate format that is not compatible with the X.509 certificate format. In the minutes of the SJWG (Security Joint Working Group) meeting of april 95, the requirement of allowing EDI users the use of X.509 certificate has been identified. The possibility of using the X.509 Certification Authority (CA) infrastructure existing in Europe to check the digital signatures of the EDI messages, looks extremely interesting to the EDI user organisations, since it avoids the need for two parallel infrastructures, with all the associated compatibility problems, maintenance costs, etc. This advantage is interesting mainly to SMEs with needs to use secure , but seldom use of EDIFACT. Despite the incompatibility of X509 and UN/EDIFACT certificates, the most important fields of them contain information referring to the same entities and aspects: certificate identification, involved parties -subject certified and Certification Authority which issues the certificate-, algorithms identification and validity period. The main reason for the incompatibility could be summarised in the fact that UN/EDIFACT certificates and X.509 certificates use different encoding rules to be built : X509 certificate is encoded using ASN.1 and BER, and UN/EDIFACT certificate is encoded in (printable) 8 bit characters. Besides that other aspects have to be taken into account. The first one is the special naming system that has to be followed in X.509 certificates (the one imposed by the entries name construction mechanism in X.500 Directory), which usually makes these names quite long, in front of the usually shorter names and with different construction mechanisms in EDIFACT. The second one is the fact that UN/EDIFACT certificate can contain a certain amount of optional information that does not appear in X.509 certificates. This problem can however be addressed by using the new "extensions" field defined in the X.509 version 3 syntax. In order to allow certified users to generate secure EDIFACT messages, and to verify the security data elements included in the received EDIFACT messages using the standard X.509 based security verification tools, it is necessary a translation tool from X.509 certificates to EDIFACT certificates This Technical Report is the first of a sequence of five reports that analyse the problem of the interoperability between the EDI and X.509 worlds, and specify one possible solution in order to eliminate the barriers of communication between both certification infrastructures. This sequence of works have been structured in two parts. The first part is concentrated in the incompatibility between the UN/EDIFACT and X.509 certificates, and the second in the interoperability between certification services. 2

3 The part related to the incompatibility between the UN/EDIFACT and X.509 certificates is made up by the three first Technical Reports of this sequence (UPC-DAC , UPC-DAC , UPC-DAC ). The main purpose of these works are to report a technical analysis of the X.509 and UN/EDIFACT certificates, identify the incompatibilities between them, and to bring a possible solution to this incompatibility specifying a mapping of each one of the certificate elements in both senses (from UN/EDIFACT to X.509 and from UN/EDIFACT to X.509). The part related to the interoperability between certification services in the EDI and X.509 worlds is composed of the fourth and fifth Technical Report of the sequence (UPC-DAC , UPC-DAC ). In the fourth Technical Report (UPC-DAC ) a functional specification of a mapping entity between UN/EDIFACT certification functionalities (KEYMAN message) and X.500 Directory Service. The detailed specification of the conversion rules of this entity are brought in the fifth Technical Report (UPC-DAC ). The main objective of this Technical Report is to perform a careful study of the X.509 and UN/EDIFACT certificates, and to specify the information that has to be managed in order to allow a conversion between these two formats of certificates (that will be applicable, for example, in a translation tool of both certificates ). This Technical Report will give a sound basis for all subsequent documents in this area which need to make references to both types of public key certificate. It also defines a possible profile for the two types of certificates. Careful analysis of the optional (conditional) data elements that can be present in UN/EDIFACT certificate and their relationship with the fields in the X.509 certificate will be carried out in order to fix the information that will be managed in a translation process. Afterwards, those data elements that have to be included in X.509 certificate will be identified. Since the X.509 (v1 92) does not provide means to allocate all the semantic information contained in the UN/EDIFACT certificate, it will be necessary to take some compromise about the most suitable way to encode the information in the available data types. One of the approaches taken will be to define X.509v3 extensions fields which can carry this data. 3

4 Table of contents 1. INTRODUCTION TECHNICAL ANALYSIS OF THE X.509 CERTIFICATE X.509 CERTIFICATE VERSION 1 AND X.509 CERTIFICATE VERSION Basic Certificate Fields Version Serial number Signature Issuer Name Validity Subject Name Subject Public Key Info Unique Identifiers Certificate Extension Fields Standard Extensions Key and policy information Authority key identifier Subject key identifier Key usage Private key usage period Certificate policies Policy mappings Certificate subject and certificate issuer attributes Subject alternative name Issuer alternative name Subject directory attributes Certification path constraints Basic constraints Name constraints Policy constraints CRL distribution points Private Extensions Subject Information Access Authority Information Access CA Information Access TECHNICAL ANALYSIS OF THE UN/EDIFACT CERTIFICATE NOTATIONS UN/EDIFACT VERSION 3 CERTIFICATE General Structure Segment USC - Certificate Segment USA - Security Algorithm Segment USR - Security Result UN/EDIFACT VERSION 4 CERTIFICATE General Structure Segment USC - Certificate Segment USA - Security Algorithm Segment USR - Security Result CODING OF THE DATA ELEMENTS USC - Certificate USC.0536 Certificate Reference USC.S Security Party Qualifier USC.S Key Name USC.S Party Id Identification USC.S Security Party Identification USC.S Code List Qualifier USC.S Security Party Code List Qualifier USC.S Code List Responsible Agency USC.S Security Party Code List Responsible Agency, Coded USC.S Party Name USC.S Security Party Name USC.0544 Format Certificate Version USC.0505 Filter Function, Coded

5 USC.0507 Character Set Encoding, Coded USC.0507 Original Character Set Encoding, Coded USC.0543 Character Set Repertoire, Coded USC.0543 Certificate Original Character Set Repertoire, Coded USC.0546 User Authorisation Levels USC.S Separator for Signature USC.S Separator for Signature USC.S Separator for Signature Qualifier USC.S Date and Time Qualifier, Coded USC.S Date and Time Qualifier USC.S Date USC.S Date, Extended USC.S Time USC.S Event Time USC.S UTC Offset USC.S Time Offset USC.0567 Security Status, Coded USC.0569 Revocation Reason Coded USA - Security Algorithm USA.S Use of Algorithm, Coded USA.S Cryptographic Mode of Operation, Coded USA.S Mode of Operation Code List Identifier USA.S Algorithm, Coded USA.S Algorithm Code List Qualifier USA.S Algorithm Parameter Value USA.S Algorithm Parameter Qualifier, Coded USR - Security Result USR.S Validation value qualifier USR.S Validation Value COMPARISON UN/EDIFACT CERTIFICATES PROFILES INTRODUCTION. DESCRIPTIVE TECHNIQUE USED UN/EDIFACT CERTIFICATE PROFILE Conventions Tabular description USC Segment USA Segments USR Segment FreeForm Description USC Segment USA Segment USR Segment X.509 CERTIFICATES PROFILES PROFILE OF THE INITIAL X.509 CERTIFICATE PROFILE OF THE DERIVED X.509 CERTIFICATE Fields of a Derived X.509 certificate Extensions of a Derived X.509 certificate INTRODUCTION...I 2. CONTENTS OF THE DESCRIPTION...I 2.1 SET SECTION... I 2.2 ALISASES SECTION... I 2.3 DESCRIPTIVE SECTION... I Identification mechanisms...ii General mechanism...ii Mechanisms for repeated structures...ii Mechanisms for data elements composites...ii STATUS...II VALUE...III IF THEN ELSE...III 5

6 1. Introduction EDI users require the use of security services, like non-repudiation of origin, data integrity, and even confidentiality of the interchanged messages. These functions require the use of electronic digital signatures, based on public key infrastructure, in order to allow the certification of the users' public keys. The current security messages developed within UN/EDIFACT include a specification of a public key certificate format that is not compatible with the X.509 certificate format. In the minutes of the SJWG (Security Joint Working Group) meeting of april '95, the requirement of allowing EDI users the use of X.509 certificates has been identified. The possibility of using the X.509 Certification Authority (CA) infrastructure existing in Europe to check the digital signatures of the EDI messages, looks extremely interesting to the EDI user organisations, since it avoids the need for two parallel infrastructures, with all the associated compatibility problems, maintenance costs, etc. This advantage is interesting mainly to SMEs with needs to use secure , but seldom use of EDIFACT. This need has also arisen in several conferences in the last months: EDITT (Barcelona Feb. '95) and EUROSEC'95 (Paris). And the architectural element that will perform this function is also recognised as a need in the draft of the EPHOS security provision recommendations. Another requirement from the users (Swiss and Greek banks, ministry of finance of Netherlands, and other public administration entities, etc.) is the need to share authentication credentials (public key certificate) between the different Telematics applications, to validate them in all these applications (electronic mail, EDI, work-flow, etc.). As a consequence of that, it will be possible to share the infrastructure needed to verify these credentials by the agents of these standard distributed applications in an European wide scenario. Given that digital signatures verification and certification infrastructure tools are already available for the electronic mail users, the possibility to share them with the EDI users will in fact provide these with the available infrastructure, and so will give them the opportunity to use security services immediately, without the need to wait until private or public initiatives set up a parallel infrastructure of digital signatures verification and certification. This will give the electronic commerce the needed impulse to take-off, since most companies hesitate due to the legal and security problems of electronic data transmission. User communities specially sensitive to these problems, like financial institutions and administrations will, once convinced of the availability and usefulness of the services, push their clients and administered citizens to use these communication means with full legal acceptance. Currently there are several implementations and experimental pilot services of Certification Authorities based on the X.500 implementations available in Europe, like OSISec, distributed by UCL, SecuDE, distributed by GMD, and SESAME distributed by the SESAME partners (GMD, ICL, Siemens/SSE). The first two rely on ISODE directory (QUIPU), distributed by the ISODE Consortium, but could interwork with other X.500 implementations using strong (3 way) authentication like Torquemada, distributed by INRIA. These implementations are used in Electronic Mail and X.509 certificates management. The SESAME certification infrastructure is used with X.400 mail and with the SESAME GSS-API implementation. On the other hand, the current security messages developed within UN/EDIFACT include a specification of the certificate format that is not compatible with the X.509 format. Despite of this incompatibility, the most important fields of both certificates contain information referring to the same entities and aspects: certificate identification, involved parties -subject certified and Certification Authority which issues the certificate-, algorithms identification and validity period. The main reason for the incompatibility could be summarised in the fact that UN/EDIFACT certificates and X.509 certificates use different encoding rules to be built. X509 certificate is encoded using ASN.1 and BER. UN/EDIFACT certificate is encoded in (printable) 8 bit characters. However, other aspects have to be taken into account. The first one is the special naming system that has to be followed in X.509 certificates (the one imposed by the entries name construction mechanism in X.500 Directory), which usually makes these names quite long, in front of the usually shorter names and with different construction mechanisms in EDIFACT. The second one is the fact that UN/EDIFACT certificate can contain a certain amount of optional information that does not appear in X.509 certificates. This problem can however be addressed by using the new "extensions" field defined in the X.509 version 3 syntax. 6

7 Intensive studies on information exchange security have been developed in the European context. These studies have been focused first on theoretical considerations on how should be an European infrastructure: use of public-key cryptography, structure and organisation of Certification Authorities, etc. Afterwards, work has been carried out on building modules that performed security functions. This is what PASSWORD project (under the VALUE Programme) has done. Born as a piloting project, their partners built a security toolkit capable of providing authentication, integrity checks and confidentiality, based on the use of X.509 certificates generated by CAs. Products like SecuDE and OSISEC provide these tools. The partners offered as well secured applications: X.400 (88), X.500, ODA ACSE (ODA Application Control Service Entity) and PEM (Privacy Enhanced Mail). The partner UPC participated as pilot site in the last phase of the project. The SESAME project has developed the X.509 certification infrastructure required to support security in a distributed clientserver environment. In this certification infrastructure is necessary to support asymmetric cryptographic mechanisms through the Generic Security Services API (GSS-API). Concerning to UN/EDIFACT, the TEDIS project SAM -Security Administration and Management- (three of whose partners were CRYPTOMATHIC, r3 and UPC) has designed a first generic service message (KEYMAN) to allow certificates and keys management. The UN/EDIFACT Security Joint Working Group has begun to work on it with the intention of standardise it. After the development of both theoretical studies and basic modules implementation, work is being focused on the set up of an effective European security infrastructure. The European Union will fund the ICE-TEL project (Provision of Infrastructure of Certification Authorities in Europe). One of its objectives is to provide a large scale public key certification infrastructure in Europe, for the use of X.509 certificate-based security services. This project will cover the provision of the service in most of the EU countries, and a few non-eu ones. The TERENA organisation is considering the possibility to support the TWICE project, that would provide the minimum funds needed to extend the service to the missing countries in Europe. In UN/EDIFACT world, the TEDIS project FAST (First Attempt to Secure Trade) -where CRYPTOMATHIC and r3 are partners, among others- is a test pilot on Certification Authorities for Trade using EDI. Chambers of Commerce act as CAs in each country, and form in this way the EDI certification infrastructure. The INFOSEC project BOLERO has as main purpose to introduce secure EDI in trade of Bills of Landing and Sea Waybills. The project is developing infrastructure including Registration Authorities and CAs. From the previous examples it can be concluded that nowadays, efforts are focused in developing security infrastructures to really provide certificate-based security to electronic information exchange. This is happening in both worlds, X.509 world and UN/EDIFACT world, which implies a real need for tools that allow interactions among users of them. An example that shows this need is the work done in the Customs Data Interchange Project in Italy. In this country, a system is being tested which will permit EDI secure interchanges among Custom Operators and Custom Administration. As at the moment when the project started, security in EDIFACT was not developed enough, they are using security tools provided by PEM (which uses X.509 certificates). EDIFACT messages secured in this way are transported by using one of the common transport systems X.400, FTAM or FTP. People involved in this project think that it should be added to this system tools to implant UN/EDIFACT security services, which will imply the coexistence of X.509 and UN/EDIFACT certificates in the same system. The need to manage simultaneously both types of certificates is obvious. So, in order to allow certified users to generate secure EDIFACT messages, and to verify the security data elements included in the received EDIFACT messages using the standard X.509 based security verification tools, it is necessary a translation tool from X.509 certificates to EDIFACT certificates The main objective of this Technical Report is to perform a careful study of the X.509 and UN/EDIFACT certificates, and to specify the information that has to be managed in order to allow a conversion between these two formats of certificates (that will be applicable, for example, in a translation tool of both certificates ) Careful analysis of the optional (conditional) data elements that can be present in UN/EDIFACT certificate and their relationship with the fields in the X.509 certificate will be carried out in order to fix the information that will be managed in a translation process. Afterwards, those data elements that have to be included in X.509 certificate will be identified. Since the X.509 ( 92) does not provide means to allocate all the semantic information contained in the UN/EDIFACT certificate, it will be necessary to take some compromise about the most suitable way to encode the information in the available data types. One of the approaches taken will be to define X.509v3 extensions fields which can carry this data. This document is mainly devoted to provide user the information contained in X509 and UN/EDIFACT certificates in order to identify the relevant information to be involved in the conversion process from one kin of certificate to the other. This Technical Report will give a sound basis for all subsequent documents in this area which need to make references to both types of public key certificate. It also defines a possible profile for the two types of certificates. Its contents are the following ones: 7

8 A technical analysis of the X.509 certificate A short review of X.509 Version 1 and Version 2 Certificates appears first, but the aim of this part of the Technical Report is to introduce the X.509 Version 3 Certificates. This report is based on the second draft of the Internet Public Key Infrastructure X.509 Certificate and CRL Profile [PKIX] and on the final ISO document [X.509-AM]. The Version 3 Certificate extends the Version2 Certificate by adding provision for additional extension fields. There are standard extensions defined by the ISO document [X.509-AM], but any other extension fields may be defined and registered by any organisation or community (there are some examples given in section 2.2.2). The standard extensions are very broad in their applicability. Therefore it's necessary to specify a profile for use of the X.509v3 extensions to develop inter-operable implementations of X.509v3 systems. Such a profile is for example specified by the Internet Public Key Infrastructure (IETF-PKIX) working group[pkix]. A lot of their recommendations are integrated in this document. A technical analysis of the UN/EDIFACT certificate The technical specification of the UN/EDIFACT certificates is also analysed. It contains the description of both the version 3 and the version 4 certificate and includes a comparison of these two versions. Users functional requirements The first ideas on users s functional requirements are after presented in form of a list. These functional requirements will condition the certificates profiles. 8

9 2. TECHNICAL ANALYSIS OF THE X.509 CERTIFICATE 2.1 X.509 Certificate Version 1 and 2 Application of public key technology requires the user of a public key to be confident that the public key belongs to the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subject identities. The binding is achieved by having a trusted certification authority (CA) digitally sign each certificate. A certificate has a limited valid lifetime which is indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems. The standard known as ITU-T X.509 (formerly CCITT X.509) or ISO/IEC , which was first published in 1988 as part of the X.500 Directory recommendations, defines a standard certificate format. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format. These two fields are used to support directory access control. The Internet Privacy Enhanced Mail (PEM) proposals, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates [RFC 1422]. The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats are deficient in several respects: The pure top-down hierarchy, with all certification paths starting from the root, is too restrictive for many purposes. For some applications, verification of certification paths should start with a public key of a CA in a user's own domain, rather than mandating that verification commence at the top of a hierarchy. In many environments, the local domain is often the most trusted. Also, initialisation and key-pair-update operations can be more effectively conducted between an end entity and a local management system. The name subordination rule introduces undesirable constraint upon the X.500 naming system an organisation may use. Use of the PCA (Policy Certification Authority) concept requires knowledge of individual PCAs to be built into certificate chain verification logic. In the particular case of Internet mail, this is not a major problem -- the PCA name can always be displayed to the human user who can make a decision as to what trust to imply from a particular chain. However, in many commercial applications, such as electronic commerce or EDI, operator intervention to make policy decisions is impractical. The process needs to be automated to a much higher degree. In fact, the full process of certificate chain processing needs to be implementable in trusted software. 2.2 X.509 Certificate Version 3 The main reason for the structural restrictions imposed by RFC 1422 was the restricted certificate format provided with X.509 v1. With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. 9

10 In response to these new requirements, ISO/IEC and ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organisation or community. In June 1996, standardisation of the basic v3 format was completed [X.509-AM]. ISO/IEC and ANSI X9 have also developed a set of standard extensions for use in the v3 extensions field [X.509-AM]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints. However, the ISO/IEC and ANSI standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. For example the Internet Public Key Infrastructure (IETF-PKIX) working group [PKIX] has specified a profile for Internet WWW, electronic mail, and IPSEC applications. Environments with additional requirements may build on this profile or may replace it Basic Certificate Fields The basic certificate fields of a v3 certificate are mainly the same than of a v2 certificate. New is only the extensions field. The X.509 v3 certificate basic syntax is as follows: Certificate ::= SEQUENCE { tbscertificate signaturealgorithm signature } TBSCertificate, AlgorithmIdentifier, BIT STRING TBSCertificate ::= SEQUENCE { version [0] Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, If present, version must be v2 or v3 subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, If present, version must be v2 or v3 extensions [3] Extensions OPTIONAL If present, version must be v3 } Version The ASN.1 definition of the version type is as follows: Version ::= INTEGER{ v1(0), v2(1), v3(2) } The version field is 0 by default which indicates that certificate version 1 (1988) is used. It can be 0, 1 or 2 (depending on the version number, v1 corresponds to 0, v2 corresponds to 1 and v3 corresponds to 2). If either the issueruniqueidentifier or subjectuniqueidentifier fields are present, the version must be v2 or v3. If any extension field is present, the version must be v3. 10

11 Implementations should be prepared to accept any version certificate. In particular, at a minimum, implementations should recognise v3 certificates; determine whether any critical extensions are present; and accept certificates without critical extensions even if they don't recognise any extensions. A certificate with an unrecognised critical extension must always be rejected Serial number The ASN.1 definition of the CertificateSerialNumber type is as follows: CertificateSerialNumber ::= INTEGER The serial number is an integer assigned by the certification authority to each certificate. It must be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate) Signature The ASN.1 definition of the AlgorithmIdentifier type is as follows: AlgorithmIdentifier ::= SEQUENCE{ algorithm ALGORITHM.&id({SupportedAlgorithms}), parameters ALGORITHM.&Type ({SupportedAlgorithms}{@algorithm})OPTIONAL } SupportedAlgorithms ALGORITHM ::= {...} ALGORITHM ::= TYPE-IDENTIFIER This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate Issuer Name The ASN.1 definition of the Name type is given as follows: NAME ::= CHOICE{ distinguishedname RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeValueAssertion AttributeValueAssertion ::= SEQUENCE{ AttributeType, AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY The issuer name identifies the entity who has signed (and issued the certificate). The syntax of the issuer name is an X.500 distinguished name. The issuer identity may be carried in the issuer name field and/or the issueraltname extension. If identity information is present only in the issueraltname extension, then the issuer name may be an empty sequence and the 11

12 issueraltname extension must be critical. According to v1 and v2 certificates the issuer name must be present, only in a v3 certificate it may be left empty Validity The ASN.1 definition of the Validity type is given as follows: Validity ::= SEQUENCE{ notbefore UTCTime, notafter UTCTime } The elements notbefore and notafter indicate the first and last date of which the certificate is valid respectively. The validity period is given in universal time encoding (UTC) or Greenwich Mean Time (GMT). It is strongly recommended by the IETF-PKIX working group that UTCTime values be expressed Greenwich Mean Time and not use seconds, i.e., times are YYMMDDHHMMZ where : YY is the least significant two digits of the year MM is the month (01 to 12) DD is the day (01 to 31) HH is the hour (00 to 23) MM are the minutes (00 to 59) Z indicates that local time is GMT If seconds are used, a value of 00 seconds should never be encoded Subject Name The subject field is of the same type (Name) as the issuer identifier and the definition is given above. The purpose of the subject name is to provide a unique identifier of the subject of the certificate. The syntax of the subject name is an X.500 distinguished name. The subject identity may be carried in the subject field and/or the subjectaltname extension. If identity information is present only in the subjectaltname extension, then the subject name may be an empty sequence and the subjectaltname extension must be critical. According to v1 and v2 certificates the subject name must be present, only in a v3 certificate it may be left empty Subject Public Key Info The ASN.1 definition of the SubjectPublicKeyInfo type is given as follows: SubjectPublicKeyInfo ::= SEQUENCE{ algorithm AlgorithmIdentifier, subjectpublickey BITSTRING } 12

13 This field is used to carry the public key and identify the algorithm with which the key is used Unique Identifiers The ASN.1 definition of the UniqueIdentifier type is given as follows: UniqueIdentifier::= BITSTRING The subject and issuer unique identifier are present in the certificate to handle the possibility of reuse of subject and/or issuer names over time. It's recommended by the IETF-PKIX working group that names not be reused and that Internet certificates not make use of unique identifiers. CAs should not generate certificates with unique identifiers. Applications should be capable of parsing unique identifiers and making comparisons Certificate Extension Fields The ASN.1 definition of the Extensions type is given as follows: authoritykeyidentifier EXTENSION ::= { Extensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE{ extnid EXTENSION.&id({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnvalue OCTETSTRING } EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE &ExtnType } WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id } The extension field allows addition of new fields to the structure without modification of the ASN.1 definition. An extension field consists of an extension identifier, a critically flag and a canonical encoding of a data value of an ASN.1 type associated with the identified extension Standard Extensions The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys, for managing the certification hierarchy, and for managing CRL (Certificate Revocation List) distribution. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities (see section Private Extensions). Each extension in a certificate may be designated as critical or non-critical. A certificate using system (an application validating a certificate) must reject the certificate if it encounters a critical extension it does not recognise. A non-critical extension may be ignored if it is not recognised. Either critical or non-critical at the 13

14 option of the certificate issuer are Key usage, Certificate policies, Subject alternative names, Issuer alternative names, Basic constraints, Name constraints and Policy constraints. All other extensions are always non-critical. The X.509v3 standard defines the following certificate extensions: I. Key and policy information a) Authority key identifier b) Subject key identifier c) Key usage d) Private key usage period e) Certificate policies f) Policy mappings II. Certificate subject and certificate issuer attributes a) Subject alternative name b) Issuer alternative name c) Subject directory attributes III. Certification path constraints a) Basic constraints b) Name constraints c) Policy constraints IV. CRL distribution points Key and policy information The following extensions are defined: a) Authority key identifier b) Subject key identifier c) Key usage d) Private key usage period e) Certificate policies f) Policy mappings Authority key identifier The ASN.1 definition of the authoritykeyidentifier type is given as follows: 14

15 authoritykeyidentifier EXTENSION ::= { SYNTAX AuthorityKeyIdentifier IDENTIFIED BY { id-ce 35 } } AuthorityKeyIdentifier ::= SEQUENCE { keyidentifier [0] KeyIdentifier OPTIONAL, authoritycertissuer [1] GeneralNames OPTIONAL, authoritycertserialnumber [2] CertificateSerialNumber OPTIONAL } ( WITH COMPONENTS {..., authoritycertissuer PRESENT, authoritycertserialnumber PRESENT} WITH COMPONENTS {..., authoritycertissuer ABSENT, authoritycertserialnumber ABSENT} ) KeyIdentifier ::= OCTET STRING The authority key identifier extension provides a means of identifying the particular public key used to sign a certificate. The identification can be based on either the key identifier (the subject key identifier in the issuer's certificate) or on the issuer name and serial number. The key identifier method is recommended by the IETF-PKIX working group. If both are used then the certificate issuer shall ensure they are consistent. This extension would be used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). In general, this extension should be included in certificates. This extension is always non-critical. A key identifier must be unique with respect to all key identifiers for the subject with which it is used Subject key identifier The ASN.1 definition of the Subject key identifier type is given as follows: subjectkeyidentifier EXTENSION ::= { SYNTAX SubjectKeyIdentifier IDENTIFIED BY { id-ce 14 } } SubjectKeyIdentifier ::= KeyIdentifier The subject key identifier extension provides a means of identifying the particular public key used in an application. It enables distinct keys used by the same subject to be differentiated (e.g., as key updating occurs). This extension is always non-critical. A key identifier shall be unique with respect to all key identifiers for the subject with which it is used Key usage The ASN.1 definition of the Key usage type is given as follows: keyusage EXTENSION ::= { SYNTAX KeyUsage IDENTIFIED BY { id-ce 15 } } KeyUsage ::= BIT STRING { 15

16 digitalsignature (0), nonrepudiation (1), keyencipherment (2), dataencipherment (3), keyagreement (4), keycertsign (5), crlsign (6) } Bits in the KeyUsage type are as follows: a) digitalsignature: for verifying digital signatures that have purposes other than those identified in b), f), or g) below; b) nonrepudiation: for verifying digital signatures used in providing a nonrepudiation service which protects against the signing entity falsely denying some action (excluding certificate or CRL signing, as in f) or g) below); c) keyencipherment: for enciphering keys or other security information, e.g., for key transport; d) dataencipherment: for enciphering user data, but not keys or other security information as in c) above; e) keyagreement: for use as a public key agreement key; f) keycertsign: for verifying a CA s signature on certificates; g) crlsign: for verifying a CA s signature on CRLs. This field indicates the purpose for which the certified public key is used. This extension may, at the option of the certificate issuer, be either critical or non-critical. The IETF-PKIX working group recommends that when used, this extension be marked as a critical extension. If the extension is flagged critical, then the certificate shall be used only for a purpose for which the corresponding key usage bit is set to one. If the extension if flagged non-critical, then it indicates the intended purpose or purposes of the key, and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. It is an advisory field and does not imply that usage of the key is restricted to the purpose indicated. A bit set to zero indicates that the key is not intended for that purpose. If all bits are zero, it indicates the key is intended for some purpose other than those listed Private key usage period The ASN.1 definition of the Private key usage period type is given as follows: privatekeyusageperiod EXTENSION ::= { SYNTAX PrivateKeyUsagePeriod IDENTIFIED BY { id-ce 16 } } PrivateKeyUsagePeriod ::= SEQUENCE { notbefore [0] GeneralizedTime OPTIONAL, notafter [1] GeneralizedTime OPTIONAL } ( WITH COMPONENTS {..., notbefore PRESENT} WITH COMPONENTS {..., notafter PRESENT} ) This field indicates the period of use of the private key corresponding to the certified public key. It is applicable only for digital signature keys. The period of valid use of the private key may be different from the certified validity of the public 16

17 key as indicated by the certificate validity period. With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key. The IETF-PKIX working group recommends against the use of this extension. This extension is always non-critical Certificate policies The ASN.1 definition of the Certificate policies type is given as follows: certificatepolicies EXTENSION ::= { SYNTAX CertificatePoliciesSyntax IDENTIFIED BY { id-ce 32 } } CertificatePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation PolicyInformation ::= SEQUENCE { policyidentifier CertPolicyId, policyqualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL } CertPolicyId ::= OBJECT IDENTIFIER PolicyQualifierInfo ::= SEQUENCE { policyqualifierid CERT-POLICY-QUALIFIER.&id ({SupportedPolicyQualifiers}), qualifier CERT-POLICY-QUALIFIER.&Qualifier ({SupportedPolicyQualifiers}{@policyQualifierId}) OPTIONAL } SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= {... } The certificate policies extension contains a sequence of policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. These policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. The IETF-PKIX working group strongly recommends that a simple OID be present in this field. Optional qualifiers which may be present are expected to provide information about obtaining CA rules, not change the definition of the policy. Applications are expected to have a list of those policies which they will accept and to compare the policy OIDs in the certificate to that list. This extension may, at the option of the certificate issuer, be either critical or non-critical. If the extension is flagged critical, it indicates that the certificate shall only be used for the purpose, and in accordance with the rules implied by one of the indicated certificate policies. If the extension is flagged non-critical, use of this extension does not necessarily constrain use of the certificate to the policies listed. However, a certificate user may require a particular policy to be present in order to use the certificate. Policy qualifiers may, at the option of the certificate user, be processed or ignored. 17

18 Certificate policies and certificate policy qualifier types may be defined by any organisation with a need. Object identifiers used to identify certificate policies and certificate policy qualifier types shall be assigned in accordance with CCITT Rec. X.660 ISO/IEC The following ASN.1 object class is used in defining certificate policy qualifier types: CERT-POLICY-QUALIFIER ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Qualifier OPTIONAL } WITH SYNTAX { POLICY-QUALIFIER-ID &id [QUALIFIER-TYPE &Qualifier] } Policy mappings The ASN.1 definition of the Policy mappings type is given as follows: policymappings EXTENSION ::= { SYNTAX PolicyMappingsSyntax IDENTIFIED BY { id-ce 33 } } PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { issuerdomainpolicy CertPolicyId, subjectdomainpolicy CertPolicyId } This field, which shall be used in CA-certificates only, allows a certificate issuer to indicate that, for the purposes of the user of a certification path containing this certificate, one of the issuer's certificate policies can be considered equivalent to a different certificate policy used in the subject CA's domain. This extension is always non-critical Certificate subject and certificate issuer attributes The following extensions are defined: a) Subject alternative name b) Issuer alternative name c) Subject directory attributes Subject alternative name The ASN.1 definition of the Subject alternative name type is given as follows: subjectaltname EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY { id-ce 17 } } 18

19 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { othername [0] INSTANCE OF OTHER-NAME, rfc822name [1] IA5String, dnsname [2] IA5String, x400address [3] ORAddress, directoryname [4] Name, edipartyname [5] EDIPartyName, uniformresourceidentifier [6] IA5String, ipaddress [7] OCTET STRING, registeredid [8] OBJECT IDENTIFIER } OTHER-NAME ::= TYPE-IDENTIFIER EDIPartyName ::= SEQUENCE { nameassigner [0] DirectoryString {ub-name} OPTIONAL, partyname [1] DirectoryString {ub-name} } This field contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the CA to the certified public key. This extension may, at the option of the certificate issuer, be either critical or non-critical. Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name should be empty (an empty sequence), the subjectaltname extension should be used, and the subjectaltname extension must be marked critical Issuer alternative name The ASN.1 definition of the Issuer alternative name type is given as follows: issueraltname EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY { id-ce 18 } } This field contains one or more alternative names, using any of a variety of name forms, for the certificate or CRL issuer. This extension may, at the option of the certificate or CRL issuer, be either critical or non-critical. As with the Subject alternative name, this extension is used to associate Internet style identities with the certificate issuer. If the only issuer identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the issuer distinguished name should be empty (an empty sequence), the issueraltname extension should be used, and the issueraltname extension must be marked critical Subject directory attributes The ASN.1 definition of the Subject directory attributes type is given as follows: subjectdirectoryattributes EXTENSION ::= { SYNTAX AttributesSyntax IDENTIFIED BY { id-ce 9 } } 19

20 AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute This field conveys any desired Directory attribute values for the subject of the certificate. This extension is always non-critical Certification path constraints The following extensions are defined: a) Basic constraints b) Name constraints c) Policy constraints Basic constraints The ASN.1 definition of the Basic constraints type is given as follows: basicconstraints EXTENSION ::= { SYNTAX BasicConstraintsSyntax IDENTIFIED BY { id-ce 19 } } BasicConstraintsSyntax ::= SEQUENCE { ca BOOLEAN DEFAULT FALSE, pathlenconstraint INTEGER (0..MAX) OPTIONAL } This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. If so, a certification path length constraint may also be specified. This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise an entity which is not authorised to be a CA may issue certificates and a certificate-using system may unwittingly use such a certificate Name constraints The ASN.1 definition of the Name constraints type is given as follows: nameconstraints EXTENSION ::= { SYNTAX NameConstraintsSyntax IDENTIFIED BY { id-ce 30 } } NameConstraintsSyntax ::= SEQUENCE { permittedsubtrees [0] GeneralSubtrees OPTIONAL, excludedsubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, 20

21 minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } BaseDistance ::= INTEGER (0..MAX) The name constraints extension, which shall be used only in a CA-certificate, provides permitted and excluded sub-trees that place restrictions on names that may be included within a certificate issued by a given CA. Restrictions may apply to the subject distinguished name or subject alternative names. Any name matching a restriction in the excluded sub-trees field is invalid regardless of information appearing in the permitted sub-trees. This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise a certificate user may not check that subsequent certificates in a certification path are located in the name space intended by the issuing CA. If this extension is present and is flagged critical then a certificate-using system shall check that the certification path being processed is consistent with the value in this extension Policy constraints The ASN.1 definition of the Policy constraints type is given as follows: policyconstraints EXTENSION ::= { SYNTAX PolicyConstraintsSyntax IDENTIFIED BY { id-ce 34 } } PolicyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { policyset [0] CertPolicySet OPTIONAL, requireexplicitpolicy [1] SkipCerts OPTIONAL, inhibitpolicymapping [2] SkipCerts OPTIONAL } SkipCerts ::= INTEGER (0..MAX) CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId The policy constraints extension may be used by CAs to specify constraints which may require explicit certificate policy identification or inhibit policy mapping for the remainder of the certification path. This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise a certificate user may not correctly interpret the stipulation of the issuing CA CRL distribution points The ASN.1 definition of the CRL Distribution Points type is given as follows: crldistributionpoints EXTENSION ::= { SYNTAX CRLDistPointsSyntax IDENTIFIED BY { id-ce 31 } } CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint 21

22 DistributionPoint ::= SEQUENCE { distributionpoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, crlissuer [2] GeneralNames OPTIONAL } DistributionPointName ::= CHOICE { fullname [0] GeneralNames, namerelativetocrlissuer [1] RelativeDistinguishedName } ReasonFlags ::= BIT STRING { unused (0), keycompromise (1), cacompromise (2), affiliationchanged (3), superseded (4), cessationofoperation (5), certificatehold (6) } The CRL distribution points extension associates every certificate with a CRL distribution point which is either: or - a Directory entry whose CRL attribute will contain a revocation entry for that certificate, if it has been revoked; - a location such as an electronic mail address or Internet Uniform Resource Identifier from which the applicable CRL can be obtained The CRL distribution points extension may be used in both CA-certificates and end-entity certificates. A certificate user can obtain a CRL from an applicable distribution point or it can obtain a current complete CRL from the CA directory entry. The IETF-PKIX working group recommends support for this extension by CAs and applications This extension may, at the option of the certificate issuer, be either critical or non-critical. interoperability, it is recommended that it be flagged non-critical. In the interests of Private Extensions The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. The IETF-PKIX working group for example has defined the following private extensions: a) Subject Information Access b) Authority Information Access c) CA Information Access Subject Information Access The ASN.1 definition of the Subject Information Access type is given as follows: subjectinfoaccess EXTENSION ::= { 22

23 SYNTAX SubjectInfoAccessSyntax IDENTIFIED BY { TBD-OID-1 } } SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription AccessDescription ::= SEQUENCE { accessmethod OBJECT IDENTIFIER, accesslocation GeneralName } The name information in the certificate identifies the entity to which the public key is bound. In some instances, it may also be necessary to know where to find additional information about the named entity. In the case of X.500 names, this relationship is automatic. The subject information access extension provides a means of identifying where and how to find information about the subject. The extension specifies a method of obtaining information and a general name form indicating where. This extension should always be non-critical Authority Information Access The ASN.1 definition of the Authority Information Access type is given as follows: authorityinfoaccess EXTENSION ::= { SYNTAX AuthorityInfoAccessSyntax IDENTIFIED BY { TBD-OID-2 } } AuthorityInfoAccessSyntax ::= SEQUENCE { certstatus [0] SEQUENCE OF AccessDescription, certretrieval [1] SEQUENCE OF AccessDescrip capolicy [2] SEQUENCE OF AccessDescription, cacerts [3] SEQUENCE OF AccessDescription } The authority information access extension indicates how to access CA information and services for the issuer of the certificate in which the extension appears. Information and services include certificate status or on-line validation services, certificate retrieval, CA policy data, and CA certificates (certificates certifying the target CA to aid in certification path navigation). This extension may be included in subject or CA certificates and may be critical or non-critical CA Information Access The ASN.1 definition of the CA Information Access type is given as follows: cainfoaccess EXTENSION ::= { SYNTAX CAInfoAccessSyntax IDENTIFIED BY { TBD-OID-2 } } CAInfoAccessSyntax ::= SEQUENCE { certstatus [0] SEQUENCE OF AccessDescription, certretrieval [1] SEQUENCE OF AccessDescription, capolicy [2] SEQUENCE OF AccessDescription, cacerts [3] SEQUENCE OF AccessDescription } The CA information access extension indicates how to access CA information and services for the subject of the certificate in which the extension appears. Information and services include certificate status or on-line validation services, certificate retrieval, CA policy data, and CA certificates (certificates certifying the target CA to aid in cert path navigation). CA 23

24 certificates may include both an authority and a cainfoaccess extension to describe access methods for both the CA and its issuer. This extension may be included only in CA certificates and may be critical or non-critical. 24

25 3. TECHNICAL ANALYSIS OF THE UN/EDIFACT CERTIFICATE 3.1 Notations The following notation is used to describe the UN/EDIFACT certificate structure: Label Pos Tag Name S R Repr. Description The sequential position number of the segment, stand-alone data element or composite data element in the segment table (only used in version 4). The tag for the segment or data element. All composite data elements are preceded by the letter "S" and all simple data elements start with the figure "0". Name of a segment, composite data element or stand-alone data element in capital letters. Name of a component data element in small letters. The status of the segment or data element: M C mandatory conditional Repetitions: The maximum number of occurrences of the segment in the structure or of the data element in the segment (only version 4, repetitions are not available for version 3) Data value representation of the data element: a n an a3 n3 an3 a..3 n..3 an..3 alphabetic characters numeric characters alphanumeric characters 3 alphabetic characters, fixed length 3 numeric characters, fixed length 3 alphanumeric characters, fixed length up to 3 alphabetic characters up to 3 numeric characters up to 3 alphanumeric characters 25

26 3.2 UN/EDIFACT Version 3 Certificate General Structure A UN/EDIFACT version 3 certificate group consists of a sequence of five UN/EDIFACT segments: USC USA USA USA USR "Certificate", contains the credentials of the certificate owner and (optional) of the certificate issuer. "Security Algorithm", the hash algorithm used by the certificate issuer to compute the hash value of the certificate. Hashing starts with the first character of the USC segment (namely the U ) and ends with the last character of the last USA segment inluding the separator following this segment. "Security Algorithm", the signature algorithm used to sign the hash value computed by the hash function designated in the aforementioned USA segment. "Security Algorithm", the algorithm applied to secure corresponding messages. This is either the signature algorithm used with the privat key corresponding to this certificate for signing messages (the algorithm for hashing the message will be given in the USH segment of the message) or the (asymmetric) encryption algorithm used with the public key of this certificate to encrypt the message encryption key for messages (the encryption algorithm using this message encryption key will be specified in the USH segment of the individual message) "Security Result", the result of applying the hash function given in the USA segment for issuer hashing (Element USA.S , Value: 4 - IHA) and the signature algorithm given in the USA segment for issuer signature (Element USA.S , Value: 3 - ISG) to the certificate, i.e. to the segments USC-USA-USA-USA. Computation of the security result starts with the first character of the USC segment (namely the U ) and ends with the last character of the last USA segment inluding the separator following. 26

27 3.2.2 Segment USC - Certificate Function: To convey the public key and the credentials of its owner. TAG Name S Repr CERTIFICATE REFERENCE C an..35 S500 SECURITY IDENTIFICATION DETAILS C 0577 Security party qualifier M an Key name C an Party Id identification C an Code list qualifier C an Code list responsible agency C an Party name C an Party name C an Party name C an..35 S500 SECURITY IDENTIFICATION DETAILS C 0577 Security party qualifier M an Key name C an Party Id identification C an Code list qualifier C an Code list responsible agency C an Party name C an Party name C an Party name C an FORMAT CERTIFICATE VERSION C an FILTER FUNCTION, CODED C an CHARACTER SET ENCODING, CODED C an CHARACTER SET REPERTOIRE, CODED C an USER AUTHORISATION LEVELS C an..35 S505 SEPARATOR FOR SIGNATURE C 0548 Separator for signature C an Separator for signature qualifier C an..3 S505 SEPARATOR FOR SIGNATURE C 0548 Separator for signature C an Separator for signature qualifier C an..3 S505 SEPARATOR FOR SIGNATURE C 0548 Separator for signature C an Separator for signature qualifier C an..3 S505 SEPARATOR FOR SIGNATURE C 0548 Separator for signature C an Separator for signature qualifier C an..3 S501 SECURITY DATE AND TIME C 0515 Date and time qualifier, coded M an Date C n Time C n UTC offset C an..5 27

28 S501 SECURITY DATE AND TIME C 0515 Date and time qualifier, coded M an Date C n Time C n UTC offset C an..5 S501 SECURITY DATE AND TIME C 0515 Date and time qualifier, coded M an Date C n Time C n UTC offset C an Segment 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 S502 SECURITY ALGORITHM M 0523 Use of algorithm, coded M an Cryptographic mode of operation, coded C an Mode of operation code list identifier C an Algorithm, coded C an Algorithm code list identifier C an..3 S503 ALGORITHM PARAMETER C 0532 Algorithm parameter value C an Algorithm parameter qualifier, coded C an..3 S503 ALGORITHM PARAMETER C 0532 Algorithm parameter value C an Algorithm parameter qualifier, coded C an..3 S503 ALGORITHM PARAMETER C 0532 Algorithm parameter value C an Algorithm parameter qualifier, coded C an..3 S503 ALGORITHM PARAMETER C 0532 Algorithm parameter value C an Algorithm parameter qualifier, coded C an..3 S503 ALGORITHM PARAMETER C 0532 Algorithm parameter value C an Algorithm parameter qualifier, coded C an Segment USR - Security Result Function: To contain the result of the security mechanisms. Pos TAG Name S R Repr. Notes S508 VALIDATION RESULT M 0560 Validation value M an Validation value C an

29 3.3 UN/EDIFACT Version 4 Certificate General Structure A UN/EDIFACT version 4 certificate group consists of a sequence of five UN/EDIFACT segments: USC USA USA USA USR "Certificate", contains the credentials of the certificate owner and (optional) of the certificate issuer. "Security Algorithm", the hash algorithm used by the certificate issuer to compute the hash value of the certificate. Hashing starts with the first character of the USC segment (namely the U ) and ends with the last character of the last USA segment inluding the separator following this segment. "Security Algorithm", the signature algorithm used to sign the hash value computed by the hash function designated in the aforementioned USA segment. "Security Algorithm", the algorithm applied to secure corresponding messages. This is either the signature algorithm used with the privat key corresponding to this certificate for signing messages (the algorithm for hashing the message will be given in the USH segment of the message) or the (asymmetric) encryption algorithm used with the public key of this certificate to encrypt the message encryption key for messages (the encryption algorithm using this message encryption key will be specified in the USH segment of the individual message) "Security Result", the result of applying the hash function given in the USA segment for issuer hashing (Element USA.S , Value: 4 - IHA) and the signature algorithm given in the USA segment for issuer signature (Element USA.S , Value: 3 - ISG) to the certificate, i.e. to the segments USC-USA-USA-USA. Computation of the security result starts with the first character of the USC segment (namely the U ) and ends with the last character of the last USA segment inluding the separator following. 29

30 3.3.2 Segment USC - Certificate Function: To convey the public key and the credentials of its owner. Pos TAG Name S R Repr. Notes CERTIFICATE REFERENCE C 1 an S500 SECURITY IDENTIFICATION DETAILS C Security party qualifier M an Key name C an Security party identification C an Security party code list qualifier C an Security party code list responsible agency, coded C an Security party name C an Security party name C an Security party name C an FORMAT CERTIFICATE VERSION C 1 an FILTER FUNCTION, CODED C 1 an ORIGINAL CHARACTER SET ENCODING, CODED C 1 an CERTIFICATE ORIGINAL CHARACTER SET REPERTOIRE, CODED C 1 an USER AUTHORISATION LEVELS C 1 an S505 SEPARATOR FOR SIGNATURE C Separator for signature M an Separator for signature qualifier M an S501 SECURITY DATE AND TIME C Date and time qualifier M an Date, extended C n Event time C n Time offset C n SECURITY STATUS, CODED C 1 an REVOCATION REASON, CODED C 1 an..3 1 DEPENDENCY NOTES: 1. If Pos. 110 given then Pos. 100 must be given. NOTES: 2. S500. Two occurrences of S500 are possible: one for the certificate owner, one for the certificate issuer. 3. S , identifies the public key , filter function used for the binary fields of the USA and USR segments , character set encoding used when the certificate was signed, if different from current , character set repertoire used when the certificate was signed, if different from current.. 7. S505, identification of the characters used as syntactical separators between all components or within composite components in the USC segment when the signature was computed, if different from current 8. S501, dates and times involved in the certification process. Four occurrences of this composite data element are possible: certificate generation date and time 30

31 certificate start of validity period certificate end of validity period revocation date and time 9. S , a Z as last character indicates UTC time. (ISO 8601) 10. S , if used, offset from UTC (ISO 8601) NOTE: 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 Segment 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 Use of algorithm, coded M an Cryptographic mode of operation, coded C an Mode of operation code list identifier C an Algorithm, coded C an Algorithm code list identifier C an S503 ALGORITHM PARAMETER C Algorithm parameter value M an Algorithm parameter qualifier M an Segment USR - Security Result Function: To contain the result of the security mechanisms. Pos TAG Name S R Repr. Notes 010 S508 VALIDATION RESULT M Validation value qualifier M an Validation value C 1 an

32 3.4 Coding of the Data Elements The following coding descriptions are based on the specifications for UN/EDIFACT certificates version 3. Changes with version 4 are noted at the end of each description. Note: Coding for version 4 is still under construction USC - Certificate USC.0536 Certificate Reference Alphanumeric string for reference to the complete certificate if not conveyed in the given segments. USC.0536 "Certificate Reference" and USC.S500 "Security Identification Details" identifying the certificate issuer together uniquely identfy the certificate to be referenced USC.S Security Party Qualifier Code Meaning Description 3 OW Certificate Owner 4 AX Authenticating Party, i.e. corresponding certfication authority for certificate owner USC.S Key Name Name of the public key of the certificate owner or the certificate issuer, depending on USC.S "Security Party Qualifier" USC.S Party Id Identification USC.S Security Party Identification Code identifying either the certificate owner or the certificate issuer, depending on USC.S "Security Party Qualifier", based on a defined registry of security parties USC.S Code List Qualifier USC.S Security Party Code List Qualifier Code identifying the code list used for USC.S "Party Id Identification" USC.S Code List Responsible Agency USC.S Security Party Code List Responsible Agency, Coded Code identifying the agency responsible for administering the code list referenced under USC.S "Code List Qualifier" Version 4: Code Meaning Description 1 UN United Nations USC.S Party Name USC.S Security Party Name Name of the security party. 32

33 USC.0544 Format Certificate Version Version number of certificate version, identified by year and status of the UN/EDIFACT service segment directory USC.0505 Filter Function, Coded Code Meaning Description 1 NUL No filter 2 HEX Hexadecimal filter 3 ASC ASCII filter, ISO DIS , referenced for completeness but nor compliant with requirements of UN/EDIFACT level A or B syntax. 4 BAU Baudot filter, ISO DIS EDA UN/EDIFACT level A filter, TRADE/WP.4/R.1026/Add.2, Annex A Version 4: ISO , Annex F 999 ZZZ Mutually agreed Version 4: Code ZZZ is used instead of USC.0507 Character Set Encoding, Coded USC.0507 Original Character Set Encoding, Coded Code Meaning Description 1 AS7 ASCII 7-Bit 2 AS8 ASCII 8-Bit 3 EBC IBM EBCDIC 4 IPC IBM PC ASCII Code 5 VAX DEC VAX ASCII 8-Bit Code 999 ZZZ Mutually agreed Version 4: Code ZZZ is used instead of USC.0543 Character Set Repertoire, Coded USC.0543 Certificate Original Character Set Repertoire, Coded Code Meaning Description 1 UNOA UN/EDIFACT syntax level A, Version 4: ISO UNOB UN/EDIFACT syntax level B, Version 4: ISO UNOC UN/EDIFACT syntax level C, Version 4: ISO "Latin alphabet No. 1" 4 UNOD UN/EDIFACT syntax level D, Version 4: ISO "Latin alphabet No. 2" 5 UNOE UN/EDIFACT syntax level E, Version 4: ISO "Latin/Cyrillic alphabet" 33

34 6 UNOF UN/EDIFACT syntax level F, Version 4: ISO "Latin/Greek alphabet" Version 4 additional codes: Code Meaning Description 7 UN/EDIFACT syntax level G, ISO "Latin alphabet" 8 UN/EDIFACT syntax level H, ISO "Latin alphabet" 9 UN/EDIFACT syntax level I, ISO "Latin/Arabic alphabet" 10 UN/EDIFACT syntax level J, ISO "Latin/Hebrew alphabet" 11 UN/EDIFACT syntax level K, ISO "Latin alphabet" 12 UN/EDIFACT syntax level X, ISO 2022 (code extension techniques) and ISO 2375 (escape techniques) 13 UN/EDIFACT syntax level Y, ISO octet without code extension technique USC.0546 User Authorisation Levels Specification of the privileges, authorisation level, etc. associated with the owner of the certificate USC.S Separator for Signature USC.S Separator for Signature Seperator character used for the separator type specified in S "Separator for Signature Qualifier" when computing the certificate s signature. Value coded according to USC.0507 "Character Set Encoding, Coded" USC.S Separator for Signature Qualifier Code Meaning Description 1 SEG Segment separator 2 DAT Data separator 3 COM Composite separator 4 REL Release character Version 4 additional codes: Code Meaning Description 5 Repeating composite separator USC.S Date and Time Qualifier, Coded USC.S Date and Time Qualifier Code Meaning Description 34

35 2 CGT Certificate generation time 3 CSV Certificate start of validity 4 CEV Certificate end of validity Version 4 additional codes: Code Meaning Description 6 Certificate revocation time USC.S Date USC.S Date, Extended Date in format YYYYMMDD Version 4 supplies the same date format but also allows for leaving out the century, i.e. YYMMDD is also possible USC.S Time USC.S Event Time Time format HHMMSS, HH in 24 hour clock format Version 4 supplies the sime time format but allows for up to 9 more digits of precision. A Z as the last character indicates UTC time (ISO8601) USC.S UTC Offset USC.S Time Offset Offset from UTC standard time. Either XHHMM with X being P for plus and M for minus followed by offset in hours and minutes, or XY with X one from (C=Central, E=Eastern, M-Mountain, P=Pacific) and Y one from (D=Daylight Time, S=Standard Time, T=Time). Version 4: Time Offset must be given in the format HHMM. Shall be prefixed with "-" for negative offsets USC.0567 Security Status, Coded Not present in Version 3. Version 4: Code Meaning Description 1 Regular certificate 2 Revocated certificate USC.0569 Revocation Reason Coded Not present in Version 3. Version 4: Code Meaning Description 0 Valid 35

36 1 Owner key compromised 2 Issuer key compromised 3 Owner changed affiliation 4 Certificate superseded 5 Certificate terminated 999 Undefined This is taken from [SJWG95], so finally probably "ZZZ" will be used instead of "999" in the final version USA - Security Algorithm USA.S Use of Algorithm, Coded Code Meaning Description 3 ISG Issuer signing - algorithm to be used by the certficate issuer to sign the hash value computed on the certificate 4 IHA Issuer hashing - algorithm to be used by the certificate issuer to hash the certificate 5 OCF Owner encipering - algorithm used by the message sender to encrypt a symmetric key 6 OSG Owner signing - algorithm used by the message sender to sign either the hash results computed on the message or the symmetric message key 7 OCS Owner enciphering or signing - algorithm used by the message sender to encrypt a symmetric key or sign the hash result computed on the message USA.S Cryptographic Mode of Operation, Coded Code Meaning Description 0 NUL Mode of operation meaningless 9 MDC2 Modification Detection Code, IBM System Journal, V.30 N HDS1 ISO CD , Hash functions using a n-bit block cipher algorithm providing a single length hash code 11 HDS2 ISO CD , Hash functions using a n-bit block cipher algorithm providing a double length hash code 12 SQM Square-mod-n hash function, CCITT X.509 Annex D, ISO MCCP ISO CD , Banking key management, Algorithms using RSA, Signature construction by means of a seperate signature 16 DSMR ISO 9796, Digital Signature Scheme giving Message Recovery 999 ZZZ Mutually agreed Version 4: Code ZZZ is used instead of

37 USA.S Mode of Operation Code List Identifier Specification of the code list used to identify the cryptographic mode of operation. Must be 1 for the codelist specified under USA.S USA.S Algorithm, Coded Code Meaning Description 1 DES Data Encryption Standard, FIPS Pub 46 5 MD4 MD4 Message Digest Algorithm 6 MD5 MD5 Message Digest Algorithm 7 RIPEMD RIPEMD, Extension of MD4, RIPE Report CS-R9324, April 93 8 SHA Secure Hash Algorithm 9 AR/DFP Hash function of the German banking industry 10 RSA RSA-Cryptosystem 11 DSA Digital Signature Algorithm 12 RAB Rabin "Digitalized signatures and public-key functions as intractable as factorization, MIT, Report LCS/TR-212, ZZZ Mutually agreed Version 4: Code ZZZ is used instead of USA.S Algorithm Code List Qualifier Specification of the code list used to identify the algorithm. Must be 1 for the code list specified under USA.S USA.S Algorithm Parameter Value Parameter value for the algorithm specified under USA.S May be filtered by "Filter Funcion, Coded" in the USC segment (USC.0505) USA.S Algorithm Parameter Qualifier, Coded Code Meaning Description 12 MOD Modulus 13 EXP Exponent 14 MLN Modulus Length 15 PR1 Generic Parameter 1 (see Note) 16 PR2 Generic Parameter 2 (see Note) 17 PR3 Generic Parameter 3 (see Note) 18 PR4 Generic Parameter 4 (see Note) 37

38 19 PR5 Generic Parameter 5 (see Note) 20 PR6 Generic Parameter 6 (see Note) 21 PR7 Generic Parameter 7 (see Note) 22 PR8 Generic Parameter 8 (see Note) 23 PR9 Generic Parameter 9 (see Note) 24 PRA Generic Parameter 10 (see Note) 999 ZZZ Parameter value mutually agreed Note: The generic parameters are provided to allow the use of any algorithm requiring identification of parameters different from the parameters definde above. For DSA: PR1 Parameter P PR2 Parameter Q PR3 Parameter G PR4 Parameter Y Version 4: Code ZZZ is used instead of USR - Security Result USR.S Validation value qualifier Qualifies the result from signing the hashed certificate by the user USR.S Validation Value Result from signing the hashed certificate by the issuer. This value is calculated with respect to the hash and signature algorithm given for the issuer in the certificate (USA segment) and with respect to the data representation and filtering parameters given in the USC segment (USC.0505, USC.0507, USC.0543). 38

39 3.5 Comparison The UN/EDIFACT version 3 and version 4 certificates are very similar. Nevertheless there are some minor differences between them that are to be given in this section for the readers convenience. 1. One of the most striking differences is the availability of repeating elements and segments, especially of repeating composites in the version 4 certificates. 2. The differences in segments and data elements can be listed as follows: Data Element Version 3 Certificate Version 4 Certificate USC.S505 SEPARATOR FOR SIGNATURE up to 4 occurrences up to 5 occurrences due to additional repetition character USC.S Separator for signature USC.S Separator for signature USC.S Separator for signature qualifier Status: Conditional Status: Conditional Status: Mandatory Status: Mandatory USC.S501 Security Date and Time up to 3 occurrences up to 4 occurrences due to additional option for revocation time ("revocation certificate") USC.S Date USC.S Date, extended USC.S Time USC.S Event time USC.S UTC offset USC.S Time offset Type: n8 Type: n6 Type: an..5 Type: n..8 Type: n..15 Type: n4 USC.0567 SECURITY STATUS, CODED not available available USC.0569 REVOCATION REASON, CODED not available available USA.S Algorithm parameter value USA.S Algorithm parameter value Status: Conditional Status: Mandatory USA.S Algorithm parameter qualifier Status: Conditional Status: Mandatory USR.S Validation value qualifier Status: Not existent Status: Mandatory 3. Coding of data elements differs very little between version 3 and 4: Coding item Version 3 Certificate Version 4 Certificate Standard value for "Mutually agreed" 999 ZZZ USC.S /USC.S Date YYYYMMDD YYYYMMDD or YYMMDD USC.S /USC.S Time HHMMSS HHMMSS plus up to 9 more digits of precision USC.S /USC.S Offset {P M}HHMM [-]HHMM USC.0567 SECURITY STATUS, CODED no such field Coding defined in [SJWG95] USC.0569 REVOCATION REASON, CODED no such field Coding defined in [SJWG95] 39

40 5. UN/EDIFACT CERTIFICATES PROFILES 5.1 Introduction. Descriptive Technique Used. An objective of this Technical Report is to specify the information that has to be managed in order to allow a conversion between the two formats of certificates. This clause presents a propose profile of the UN/EDIFACT certificate to be used in a translation tool of both certificates. The EWOS Expert Group on EDI has raised the EWOS Technical Guide (ETG) on a descriptive technique for EDI Message Profiles [EWOS-ETG]. This document proposes a set of guidelines on the structure and contents of EDI message profiles, including notations for the description of profiles. In this clause, the guidelines proposed in the aforementioned ETG have been followed to describe the profile of, not a message, but of the UN/EDIFACT certificate, which, when complete, includes five segments: USC, three USA and one USR. A short description of the more relevant points of the technique for the UN/EDIFACT certificate profiling can be found in Annex I of this Technical Report. 5.2 UN/EDIFACT Certificate Profile,Two main types of certificates will appear, depending on the entity who has issued them: Initial certificates: certificates issued by usual Certification Authorities in both worlds, UN/EDIFACT and X.509. Derived Certificates: certificates generated by converesion rules between the two formats of certificates. They are called derived certificates because, they are built using the information contained in an initial certificate issued by a usual CA. It is clear that there will be initial and derived UN/EDIFACT certificates and initial and derived X.509 certificates. Besides these two types of certificates, it will be necessary to manage also References to Certificates. The profiling process must, in consequence, to take in account the three items aforementioned. The initial requirements of the certificate profile are: For initial UN/EDIFACT certificates, the profile defined must allow to take in account the possible combinations of conditional segments and data elements that can be present in them. Some of these combinations can be out of the scope of the mapping process in a first phase and for piloting purposes (some hashing and signature algorithms for example). For derived UN/EDIFACT certificates, the profile defined must allow to map the as many fields and extensions of the X.509 certificates as possible. For derived UN/EDIFACT certificates, the profile must allow to them to have identifiers values which are as closely related to the identifiers (Distinguished Names or Alternative Names) as possible. The profile has to contemplate not only the complete certificates, but also the references to them. It is quite clear, then, the profiling process must, in consequence, to take in account the all that has been said before Conventions The following conventions will be used in order to make the statements shorter: Initial certificate or derived certificate The key INITIAL stands for the meaning initial certificate. The key DERIVED stands for derived certificate. Certificate complete and reference to a certificate The key COMPLETE stands for the meaning complete certificate. The key REFERENCE stands for reference to a certificate. The formal definition of the both keys would be as follow: 40

41 COMPLETE = USC PRESENT AND USA(3) PRESENT AND USR PRESENT. REFERENCE = USC PRESENT AND USA(3) NOT PRESENT AND USR NOT PRESENT Conventions for the status of the data element Following the guidelines of the EWOS ETG, the profiling process will determine, status of certain data elements depending on several conditions. The notation for the status value is the one adopted in the UNSM guide: R required the data must be present. D dependent present if a condition o set of conditions apply O optional the presence is at the discretion of the sender X not used the data element must not be present N nor for use the method of use has not been agreed, and not should be present Mapping dependant Some data elements in the derived certificate will be present or not depending on the initial certificate corresponding and the mapping rules. These data elements will be O (optional) but the key MD (Mapping Dependant) will be added. The information concerning to the conditions under which they will appear and the values that will take can be found in the UPC-DAC Technical Report Tabular description In the following sub-clauses, the tabular description of the profile for the UN/EDIFACT certificate, is shown. Each table will consist of six columns, indicated below: No. Data element Usa ge Repr. Status and dependency Comments Where: No. indicates the tag of the data element. Data element indicates the name of the data element. Usage indicates what in the UN/EDIFACT terminology is known as status of the data element. Repr. indicates the representation of the data element. Status and dependency is the column that develops the profile, indicating under which conditions the data element must be present, which values can take, etc. Comments. This column is used to add explanatory comments to the profiling process USC Segment Function: To convey the public key and the credentials of its owner. The O status after the condition IF INITIAL indicates that the mapping entity must be able to manage UN/EDIFACT certificates issued by CAs that can or not contain the corresponding data element. 41

42 No. Data element Usa ge Repr. Status and dependency Comments 0536 CERTIFICATE REFERENCE S500 SECURITY IDENTIFICATION DETAILS C an..35 STATUS IF REFERENCE THEN R STATUS IF INITIAL THEN O STATUS IF DERIVED THEN R C STATUS IF REFERENCE THEN.S500(1) R ELSE S500(2) R If a reference, must be present. In a complete derived certificate must be present If a certificate complete and initial then optional If a reference only one S500 must be present. If a complete certificate, two S500 must be present 0577 Security party qualifier M an..3 VALUE 4 IF REFERENCE IF COMPLETE THEN R 0538 Key name C an..35 STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN D (MD) 0511 Security party identification 0513 Security party code list qualifier 0515 Security party code list responsible agency, coded 0586 Security party name 0586 Security party name 0586 Security party name C an..17 STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0586(3) NOT PRESENT.THEN R ELSE O STATUS IF DERIVED THEN X C an..3 STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN X C an..3 STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN R C an..35 STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R C an..35 STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R C an..35 STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R If a reference the value must be 4. If a certificate complete, must be present If a certificate derived, the presence of the data element is mapping dependent. In a derived certificate, it will not be present. In an initial certificate, if the data elements for name do not exist, this data element will identify the party. In a derived certificate, it will not be used. In a derived certificate, it will identify the mapper entity In a derived certificate, the content of it is mapping dependent. In an initial certificate, if security aprty identification exists then at least one of these data elements must be present In a derived certificate, the content of it is mapping dependent. In a derived certificate, the content of it is mapping dependent. 42

43 0545 CERTIFICATE SYNTAX VERSION, CODED 0505 FILTER FUNCTION, CODED 0507 ORIGINAL CHARACTER SET ENCODING, CODED 0543 CERTIFICATE ORIGINAL CHARACTER SET REPERTOIRE, CODED 0546 USER AUTHORISATION LEVEL S505 SERVICE CHARACTER FOR SIGNATURE 0551 Service character for signature qualifier 0548 Service character for signature S501 SECURITY DATE AND TIME 0517 Date and time qualifier C an..3 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O VALUE {CODE VERSION 3} IF DERIVED C an..3 STATUS IF REFERENCE THEN X VALUE {2,5,6} IF DERIVED OR INITIAL C an..3 STATUS IF REFERENCE THEN X VALUE 2 IF DERIVED OR INITIAL C an..3 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN R C an..35 STATUS IF REFERENCE OR DERIVED THEN X STATUS IF INITIAL THEN O C STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN.S505(5) X M an..3 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X M an..4 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X C STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN.S501(2..3) R STATUS IF DERIVED THEN.S501(2) R M an..3 STATUS IF REFERENCE THEN X VALUE {2,3,4,5}IF INITIAL VALUE {3,4} IF DERIVED 0338 Event date C n..8 STATUS IF REFERENCE THEN X ELSE R In a derived certificate, the UN/EDIFACTsyntax will be the version 3 and data elements of UN/EDIFACT version 4 will be added. 1 =No filter. 2 =Hexadecimal filter. 3 =ISO =ISO 646 baudot filter. 5 =EDA filter. 6 =EDC filter. In this profile only filters EDA and EDC will be used in derived certificates. 2 =ASCII 8 bits. In a derived certificate it will not be present. In a derived certificate, the separators will be the default service characters defined in ISO In a derived certificate, two occurrences must be present. 2 =certificate generation time 3 =certificate start of validity period 4 =certificate end of validity period 5 =certificate revocation time In a derived certificate, only the validity period will be included. 43

44 0314 Event time C an..15 STATUS IF REFERENCE THEN X ELSE R 0336 Time offset C n4 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN D (MD) 0567 SECURITY STATUS, CODED 0569 REVOCATION REASON, CODED C an..3 STATUS IF REFERENCE OR DERIVED THEN X VALUE {1,2} IF INITIAL AND PRESENT C an..3 STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X In a derived certificate, if there is offset UTCTime in the X.509 initial certificate, this element will be present 0 =valid. 1 =revoked Certificates revoked will not be mapped Some comments to the profile for USC segment follow, for references, initial and derived UN/EDIFACT certificates: References to Certificates Only USC.0536 and USC.S data elements will be required. The rest of identification information (in USC.S500 composite data element) will be optional. Initial Certificates. For certificates generated by UN/EDIFACT CAs, the following applies: 1. USC.0536 and USC.S data elements will be required. 2. At least one of the data elements types security party identification and security party name will have to exist in an initial certificate, as they are the only means to identify the security party. 3. No revoked certificates will be managed as initial certificates. This implies that only certificate with 2 or 3 security date and time will be allowed. These data elements will correspond to the starting date and time of the validity period, the end of this period and, if present, to the generation time of the certificate. The data elements corresponding to the revocation time and the revocation reason will not appear in these certificates. 4. The rest of the data elements will optionally appear as the corresponding CAs have determined. However, and looking into the pilot of the project, the possible values of some data elements have been restricted as it is indicated in the table above (filter functions and character set encoding). Derived Certificates.. A X.509 initial certificate will be taken, and looking into his contents, an UN/EDIFACT certificate will be generated. The following remarks apply for this kind of certificates: 1. The USC.0536 (reference) data element will always be present.a reference for each detived certificate that is produced, will be generated. 2. Two USC.S500 composite data elements will always be present. 3. If in the X.509 initial certificate there exists an identifier of the public key certified (see the clause on the technical analysis of the X.509 certificate), then the USC.S will also be present in the derived UN/EDIFACT certificate. 4. The 3 USC.S (name) data elements to identify the security party will be used.the reason for this is that this approach will be to have identifiers in the X.509 initial certificate and the derived UN/EDIFACT certificate as close as possible. The three data elements sum 105 characters, which can, in some occasions contain a string representation of the Distinguished Names used to identify the owner and the issuer in the X.509 certificate. This decision is aligned with the third requirement for the profile. 5. The USC.S data elements will contain the identifier of the entity that perform the conversion between these two formats of certificates as assigned by EDIRA.. 44

45 6. The other data elements that could be used to identify the security parties will not be used in the derived UN/EDIFACT certificates. 7. The service characters for the signature will be the default ones, explicited in UN/EDIFACT CD 9735 part 1, and in consequence, no data elements for them will appear in the derived certificates. 8. Only two occurrences of security date and time composite data elements will appear in the derived UN/EDIFACT certificate: the two indicating the validity period of the initial X.509 certificate. 9. No revocation reason will be present in any derived UN/EDIFACT certificate, as the entity that performs the conversion of certificate will not generate any derived UN/EDIFACT certificate from a initial X.509 revoked certificate. However, this entity can have to manage a revoked initial UN/EDIFACT certificate. This can happen when from an initial UN/EDIFACT certificate a X.509 certificate is derived. Later on, a request for verifying the validity of this derived X.509 certificate can arrive to the entity. In the meanwhile, the initial UN/EDIFACT certificate can have been revoked. Then the entity that performs the conversion between the certificates gets the initial revoked certificate and answers to the request made. 45

46 USA Segments This clause shows the tabular form of the USA segments profile in the mapper entity. No. Data element Usa ge Repr. Status and dependency Comments S502 SECURITY ALGORITHM 0523 Use of algorithm, coded 0525 Cryptographic mode of operation, coded 0533 Mode of operation code list identifier 0527 Algorithm, coded 0529 Algorithm code list identifier S503 ALGORITHM PARAMETER 0531 Algorithm parameter qualifier 0554 Algorithm parameter value M STATUS IF REFERENCE THEN S502(3) X STATUS IF COMPLETE S502(3) R M an..3 VALUE {3,4,5,6,7} 3 = Issuer signing 4 = Issuer hashing 5 = Owner enciphering 6 = Owner signing 7 = Owner enciphering and signing C an..3 STATUS X In the piloting phase of the project no cryptographic mode of operation will be needed C an..3 STATUS X C an..3 VALUE{6,9} IF.0523=4 VALUE {10} IF.0523 = {3,5,6,7} C an..3 VALUE 1 C STATUS R IF USA.S = {5,6,7} AND COMPLETE ELSE X M an..3 VALUE {12,13,14} IF.S = {5,6,7} AND COMPLETE ELSE X M an..512 STATUS IF.0531 PRESENT THEN R ELSE X 6 = MD5 9 = SHA 10 = RSA 12 = Modulus of public key 13 = Exponent 14 = Modulus length All the complete certificates will include the public key Again, some comments to the profile for USC segment follow, for references, initial and derived UN/EDIFACT certificates: References to Certificates No USA segment will appear in a reference to a certificate. Initial Certificates and Derived Certificates 1. Looking in the piloting phase of the project, the algorithms to be allowed for the initial and derived UN/EDIFACT certificate, have been restricted to that ones that are wide spread and commonly used. This will be enough for the purposes of the project. MD4 and MD5 algorithms for hashing and RSA for signatures are the choices made USR Segment 46

47 No. Data element Usa ge Repr. Status and dependency Comments S508 VALIDATION RESULT 0563 Validation value qualifier M STATUS IF COMPLETE THEN USR.S508(1) ELSE X M an..3 STATUS IF COMPLETE THEN R 0560 Validation value C an..256 STATUS IF.COMPLETE THEN R In a complete certificate the signature must appear FreeForm Description In this sub-clause the free form description of the certificate profile is shown. It is added only for completeness as there is no additional information to the tabular description USC Segment USC.0536 = STATUS IF REFERENCE THEN S502(3) X STATUS IF COMPLETE S502(3) R USC.S500 = STATUS IF REFERENCE THEN.S500(1) R ELSE S500(2) R USC.S = VALUE 4 IF REFERENCE IF COMPLETE THEN R USC.S = STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN D (MD) USC.S = STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0586(3) NOT PRESENT.THEN R ELSE O STATUS IF DERIVED THEN X USC.S = STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN X USC.S = STATUS IF REFERENCE OR INITIAL THEN O STATUS IF DERIVED THEN R USC.S = STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R USC.S = STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R USC.S = STATUS IF REFERENCE THEN O STATUS IF INITIAL AND.0511 NOT PRESENT.THEN.0586(..3) R ELSE O STATUS IF DERIVED THEN R USC.0545 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O VALUE {CODE VERSION 3} IF DERIVED USC.0505 = STATUS IF REFERENCE THEN X VALUE {2,5,6} IF DERIVED OR INITIAL USC.0507 = STATUS IF REFERENCE THEN X VALUE 2 IF DERIVED OR INITIAL USC.0543 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN R USC.0546 = STATUS IF REFERENCE OR DERIVED THEN X STATUS IF INITIAL THEN O 47

48 USC.S505 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN USC.S505(5) X USC.S = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X USC.S = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X USC.S501 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN USC.S501(2..3) R STATUS IF DERIVED THEN USC.S501(2) R USC.S = STATUS IF REFERENCE THEN X VALUE {2,3,4,5}IF INITIAL VALUE {3,4} IF DERIVED USC.S = STATUS IF REFERENCE THEN X ELSE R USC.S = STATUS IF REFERENCE THEN X ELSE R USC.S = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN O (MD) USC.0567 = STATUS IF REFERENCE OR DERIVED THEN X VALUE {1,2} IF INITIAL AND PRESENT USC.0569 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN X USA Segment USA.S502 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN R USA.S = VALUE {3,4,5,6,7} USA.S = STATUS X USA.S = STATUS X USA.S = VALUE{6,9} IF.0523=4 VALUE {10} IF.0523 = {3,5,6,7} USA.S = VALUE 1 USA.S503 = STATUS R IF USA.S = {5,6,7} AND COMPLETE ELSE X USA.S = VALUE {12,13,14} IF USA.S = {5,6,7} AND COMPLETE ELSE X USA.S = STATUS IF.0531 PRESENT THEN R ELSE X USR Segment USR.S508 = STATUS IF COMPLETE THEN USR.S508(1) ELSE X USR.S = STATUS IF COMPLETE THEN R USR.S = STATUS IF.COMPLETE THEN R 6. X.509 CERTIFICATES PROFILES Two main types of X.509 certificates will appear: 48

49 Certificates issued by X.509 Certification Authorities. X.509 users can request the generation of an UN/EDIFACT certificate following mapping rules These X.509 certificates will be known as initial certificates. Certificates generated as result of the application of the mapping rules to an UN/EDIFACT certificate issued by a X.509 Certification Authority. These X.509 certificates will be known as derived certificates. The type of certificate will be taken in account in the profiling process. It has to be taken in account that standard extensions defined in X.509 v3 certificate, contain information concerning to roles of the certificate owner and other attributes. UN/EDIFACT certificates can not include this information. This will imply that whenever an derived UN/EDIFACT certificate is requested from an initial X.509 v3 certificate, there will be extensions whose information will be lost in the UN/EDIFACT derived certificate. 6.1 Profile of the Initial X.509 certificate A entity that converts both formats of certificate must be able to accept any fields and extensions of an Initial X.509 certificate, but it only handles certains fields and extensions of this certificate, mapping these fields and extensions to the elements of the UN/EDIFACT certificate, according to a mapping rules In this way, information in the initial X.509 v3 certificate can be lost in the derived UN/EDIFACT certificate. 6.2 Profile of the Derived X.509 certificate A Derived X.509 certificate is generated as result of the application of the mapping rules to an UN/EDIFACT certificate. Therefore, this X.509 certificate only will contain the fields and extensions that are shown in the next subclauses : Fields of a Derived X.509 certificate In this clause, fields and extensions in the X.509 certificates will be identified in the following way: All the fields included in the tbscertificate field, that is, the fields of X.509 v1 and v2 certificates that have to be signed by the CA will be identified by their direct names, instead of concatenating the tbscertificate to them. In this way, issuer will appear instead of tbscertificate.issuer. The only exception to this rule will be the field tbscertificate.signature, which identifies the algorithm used to compute the signature of the certificate. If his complete name was not used, there would be a collision with the signature field containing the actual digital signature. The extensions will appear denoted with their corresponding names. - version. - serial number. It must contain the identifier assigned by the entity that performs the conversion of the certificates in the generation of this X.509 certificate. -tbscertificate.signature. This field identifies the algorithm used to sign the certificate. In a first phase this field must contain one of the following Objects Identifiers : - sha1withrsasignature_oid {1,2,840,113549,1,5} or - md5withrsa_oid ( ). In this first phase no cryptographic mode of operation will be used. - issuer. This field will identify the entity that performs the conversion of certificates ( which generates this derived X.509 certificate). - validity. This field indicates the time during the certificate is valid. 49

50 - subject. This fields identifies the certificate owner, and it is generated as result of the application of the names mapping rules to an Edi Name. - subjectpublickeyinfo. This field contains information about the public key used by the owner of the certificate. Because in the first phase, only the RSA algorithm will be supported, the only value that this field can contain is the Object Identifier rsa_oid ( ) - signaturealgorithm.algorithm (macro expansion). This field identifies the algorithm used to sign the certificate. In a first phase this field must contain one of the following Objects Identifiers : - sha1withrsasignature_oid {1,2,840,113549,1,5} or - md5withrsa_oid ( ). In this first phase no cryptographic mode of operation will be used. - signature. This field contains the signature computed by the Certification Authority by signing the hash result computed on the data of the credentials Extensions of a Derived X.509 certificate A derived certificate can contain only the following extensions : - KeyUsage. This field indicates the purpose for which the certified public key is used. This extension can contain two possibles values : - digitalsignature : to verify digital signatures, or - keyencipherment : to encipher keys or other security information. - authoritykeyidentifier.keyidentifier. This extension identifies the CA s key used to sign this derived X.509 certificate. - subjectkeyidentifier. This extension identifiese the public key being certified. - subjectaltname.edipartyname. This extension contains the Edi Name of the owner of the Initial UN/EDIFACT certificate. 50

51 References [EWOS-ETG].M.Levilion (Ed.): EWOS Technical Gude on a descriptive technique for EDI Messages Profiles [ISO9735] International Organization for Standardization: ISO 9735, Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) - Application Level Syntax Rules, 01. November [PKIX] Russel Housley, Warwick Ford, Stephen Farrell, David Solo, IETF PKIX Working Group: Internet Public Key Infrastructure. June 1996, Internet Draft: draft-ietf-pkix-ipki-part1-02.txt [RFC 1422] Steve Kent, IETF PEM Network Working Group: RFC 1442: Private Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. Feb.1993, Request for Comments [SJWG93a] Security Joint Working Group: Committee Draft UN/EDIFACT CD 9735, Syntax Element Directory - Syntax Code List Directory, 31. January [SJWG95] Security Joint Working Group: Proposed Draft of a MIG Handbook UN/EDIFACT Message KEYMAN, 30. June [SJWG9735-5] Security Joint Working Group: Committee Draft UN/EDIFACT CD , 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, Release 1, 14. December [UN-R1026-2] United Nations, Economic and Social Council, Economic Commission for Europe, Committtee on the Development of Trade: TRADE/WP.4/R.1026/Add.2, EDIFACT Security Implementation Guidelines, 22. February [UN-R1026-3] United Nations, Economic and Social Council, Economic Commission for Europe, Committtee on the Development of Trade: TRADE/WP.4/R.1026/Add.3, AUTACK: Secure Authentification and Acknowledgement Message, 23. February [X.509-AM] ISO/IEC JTC 1/SC 21/WG 4 and ITU-T Q15/7: Draft Amendment 1 to ITU-T Rec. X.509 (1993) ISO/IEC : April

52 TE2005/UPC/DAC/PI/I/010a1 WP03.DST1 Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping Annex I EWOS-ETG descriptive Technique for EDI messages profile 1. INTRODUCTION The EWOS Expert Group on EDI has produced the EWOS Technical Guide (ETG) on a descriptive technique for EDI Message Profiles [1]. This document proposes a set of guidelines on the structure and contents of EDI message profiles, including notations for the description of profiles. In this clause, a short description of the relevant points of the technique for the UN/EDIFACT certificate profile description is shown. This annex is added for completeness of the Technical Report. The ETG proposes to structure the description of a message profile in several parts: identification of the profile, set definitions, aliases definitions and descriptive expressions. 2. CONTENTS OF THE DESCRIPTION 2.1 SET section The set definitions part allows to specify values for code sets for data elements in the messages. In the tabular representation, the code references and code definitions are presented in the column of Comment. Any further reference to a subset of this complete set is indicated, if needed, by the list of codes, without listing again the code definitions. Example: No. Data element Usa ge Repr. Status and dependency Comments 0531 Algorithm parameter qualifier M an..3 VALUE {12,13,14} IF.S = {5,6,7} AND COMPLETE ELSE X 12 = Modulus of public key 13 = Exponent 14 = Modulus length All the complete certificates will include the public key In the column Comments, the complete set of codes (references and definitions) is listed, whereas in the column Status and dependency, only the list of codes are used. 2.2 ALISASES Section This section is used to define aliases for message structures (data elements, segments or groups) near the end of long nested structures, in order to avoid the retyping of long identifiers in the description. In this document, the nesting level is small, which avoids the need of such a feature. 2.3 DESCRIPTIVE Section This part contains sentences built with a descriptive language. For the purposes of this document, the following constructs of this language are the most relevant: Identification mechanisms: to univocally identify groups, segments and data elements inside a message. Status clause: to specify the status of data elements. Value clause: to specify the value of data elements. I

53 TE2005/UPC/DAC/PI/I/010a1 WP03.DST1 Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping Conditional expressions: to profile the status and values of data elements, segments and groups. The following sub-clauses show short descriptions of each one Identification mechanisms Several identification mechanisms are allowed, depending on the type of structure to be identified General mechanism Path names consisting of the tags of the structures above the identified one, separated by dot character. are used to identify any structure in the segment. Example: USC.S identifies the security party qualifier data element in the security identification details composite data element Mechanisms for repeated structures For repeated structures it is possible to use one of the three following mechanisms: The path name identifies all the occurrences of the structure. The path name followed by a number inside round brackets identifies only this number of structures. Example: USC.S500(1) stands for one occurrence of USC.S500 composite element, and any inclusion of such identification in a rule would imply that this rule will apply only to that unique occurrence. The path name followed by (..n) being n a number, identifies up to and including occurrences of the identified structure. These identification mechanisms do not contemplate any ordering in the repeated structures Mechanisms for data elements composites When in a composite data element or segment, more than one occurrence of a data element is present, the ordering is important. The identification mechanism for these data elements uses the square brackets with a number (index) inside, to denote the first, second, etc. occurrence of the data element. Example: USC.S [2] identifies the second security party name data element present in the security identification details composite data element of the USC segment STATUS As it has been said before, the following notation for the status of the data elements, adopted in the UNSM guide, will be followed: R required the data must be present. D dependent present if a condition o set of conditions apply O optional the presence is at the discretion of the sender X not used the data element must not be present N nor for use the method of use has not been agreed, and not should be present II

54 TE2005/UPC/DAC/PI/I/010a1 WP03.DST1 Technical description of X.509 and UN/EDIFACT certificates. Specific user requirements on certificate data elements mapping The status can be conditioned to a certain condition. In these cases, the conditional construct will appear after the STATUS clause. Example: STATUS IF REFERENCE OR DERIVED THEN X VALUE The VALUE clause, used with the rest of constructs of the language is used to specify the value or set of possible values that a data element can have in the profile. This clause is usually followed by a simple value in colons or a set of values. It can also be followed by conditional constructs. Example: VALUE {3,4} IF DERIVED VALUE {3,4}IF INITIAL IF THEN ELSE The usual conditional construct is used to build sentences informing of the status and the value of the data element. These status and values usually depend on conditions more or less complex. In our case, the more important is the fact of the certificate being what we have denoted as INITIAL certificate or a DERIVED one. Additional conditions are the values or certain qualifiers data elements. Example: USA.S502 = STATUS IF REFERENCE THEN X STATUS IF INITIAL THEN O STATUS IF DERIVED THEN R This sentence is indicating that the composite element USA.S502 will: Not exist if the entity that converts formats of certificates is presented a reference to a certificate. Will exist in a derived certificate from a X.509 certificate. Its existence will depend of the corresponding CA for an initial UN/EDIFACT certificate. III