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-1997-37, July 1997
Technical description of X.509 and UN/EDIFACT certificates.
Specific user requirements on certificate data elements
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 e-mail, 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 e-mail 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.
Technical description of X.509 and UN/EDIFACT certificates.
Specific user requirements on certificate data elements
mapping
Departament of Computer Architecture Universitat Politècnica de Catalunya 08034 Barcelona, Spain
{montser,cruellas,medina,isabel}@ac.upc.es, [email protected], [email protected]
Montserrat Rubia, UPC Juan Carlos Cruellas, UPC Manel Medina, UPC Isabel Gallego, UPC Damian Rodríguez, INDRA Fritz Bausspieá, R3 Petra Gloecknet, GMD
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-1997-37, UPC-DAC-1997-38, UPC-DAC-1997-39). 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-1997-40, UPC-DAC-1997-41). In the fourth Technical Report (UPC-DAC-1997-40) 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-1997-41).
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.
Table of contents
1. INTRODUCTION... 6
2. TECHNICAL ANALYSIS OF THE X.509 CERTIFICATE... 9
2.1 X.509 CERTIFICATE VERSION 1 AND 2 ... 9
2.2 X.509 CERTIFICATE VERSION 3 ... 9
2.2.1 Basic Certificate Fields...10
2.2.1.1 Version ...10 2.2.1.2 Serial number...11 2.2.1.3 Signature...11 2.2.1.4 Issuer Name ...11 2.2.1.5 Validity...12 2.2.1.6 Subject Name...12
2.2.1.7 Subject Public Key Info ...12
2.2.1.8 Unique Identifiers ...13
2.2.2 Certificate Extension Fields ...13
2.2.2.1 Standard Extensions ...13
2.2.2.1.1 Key and policy information...14
2.2.2.1.1.1 Authority key identifier...14
2.2.2.1.1.2 Subject key identifier ...15
2.2.2.1.1.3 Key usage ...15
2.2.2.1.1.4 Private key usage period ...16
2.2.2.1.1.5 Certificate policies ...17
2.2.2.1.1.6 Policy mappings...18
2.2.2.1.2 Certificate subject and certificate issuer attributes ...18
2.2.2.1.2.1 Subject alternative name ...18
2.2.2.1.2.2 Issuer alternative name ...19
2.2.2.1.2.3 Subject directory attributes ...19
2.2.2.1.3 Certification path constraints...20
2.2.2.1.3.1 Basic constraints ...20
2.2.2.1.3.2 Name constraints ...20
2.2.2.1.3.3 Policy constraints...21
2.2.2.1.4 CRL distribution points...21
2.2.2.2 Private Extensions...22
2.2.2.2.1 Subject Information Access...22
2.2.2.2.2 Authority Information Access ...23
2.2.2.2.3 CA Information Access ...23
3. TECHNICAL ANALYSIS OF THE UN/EDIFACT CERTIFICATE...25
3.1 NOTATIONS...25
3.2 UN/EDIFACT VERSION 3 CERTIFICATE...26
3.2.1 General Structure...26
3.2.2 Segment USC - Certificate ...27
3.2.3 Segment USA - Security Algorithm ...28
3.2.4 Segment USR - Security Result ...28
3.3 UN/EDIFACT VERSION 4 CERTIFICATE...29
3.3.1 General Structure...29
3.3.2 Segment USC - Certificate ...30
3.3.3 Segment USA - Security Algorithm ...31
3.3.4 Segment USR - Security Result ...31
3.4 CODING OF THE DATA ELEMENTS...32
3.4.1 USC - Certificate ...32
3.4.1.1 USC.0536 Certificate Reference...32
3.4.1.2 USC.S500.0577 Security Party Qualifier ...32
3.4.1.3 USC.S500.0538 Key Name ...32
3.4.1.4 USC.S500.0511 Party Id Identification USC.S500.0511 Security Party Identification ...32
3.4.1.5 USC.S500.0513 Code List Qualifier USC.S500.0513 Security Party Code List Qualifier ...32
3.4.1.6 USC.S500.0515 Code List Responsible Agency USC.S500.0515 Security Party Code List Responsible Agency, Coded ...32
3.4.1.7 USC.S500.0586 Party Name USC.S500.0586 Security Party Name ...32
3.4.1.8 USC.0544 Format Certificate Version ...33
3.4.1.10 USC.0507 Character Set Encoding, Coded USC.0507 Original Character Set Encoding, Coded ...33
3.4.1.11 USC.0543 Character Set Repertoire, Coded USC.0543 Certificate Original Character Set Repertoire, Coded ...33
3.4.1.12 USC.0546 User Authorisation Levels ...34
3.4.1.13 USC.S505.0548 Separator for Signature USC.S505.0550 Separator for Signature ...34
3.4.1.14 USC.S505.0551 Separator for Signature Qualifier ...34
3.4.1.15 USC.S501.0515 Date and Time Qualifier, Coded USC.S501.0517 Date and Time Qualifier ...34
3.4.1.16 USC.S501.0502 Date USC.S501.0338 Date, Extended ...35
3.4.1.17 USC.S501.0504 Time USC.S501.0314 Event Time ...35
3.4.1.18 USC.S501.0506 UTC Offset USC.S501.0336 Time Offset ...35
3.4.1.19 USC.0567 Security Status, Coded...35
3.4.1.20 USC.0569 Revocation Reason Coded ...35
3.4.2 USA - Security Algorithm ...36
3.4.2.1 USA.S502.0523 Use of Algorithm, Coded...36
3.4.2.2 USA.S502.0525 Cryptographic Mode of Operation, Coded ...36
3.4.2.3 USA.S502.0533 Mode of Operation Code List Identifier...37
3.4.2.4 USA.S502.0527 Algorithm, Coded...37
3.4.2.5 USA.S502.0529 Algorithm Code List Qualifier...37
3.4.2.6 USA.S503.0532 Algorithm Parameter Value ...37
3.4.2.7 USA.S503.0531 Algorithm Parameter Qualifier, Coded ...37
3.4.3 USR - Security Result ...38
3.4.3.1 USR.S508.0563 Validation value qualifier ...38
3.4.3.2 USR.S508.0560 Validation Value ...38
3.5 COMPARISON...39
5. UN/EDIFACT CERTIFICATES PROFILES...40
5.1 INTRODUCTION. DESCRIPTIVE TECHNIQUE USED. ...40
5.2 UN/EDIFACT CERTIFICATE PROFILE...40
5.2.1 Conventions ...40 5.2.2 Tabular description ...41 5.2.2.1 USC Segment...41 5.2.2.2 USA Segments ...46 5.2.2.3 USR Segment...46 5.2.3 FreeForm Description...47 5.2.3.1 USC Segment...47 5.2.3.2 USA Segment...48 5.2.3.3 USR Segment...48 6. X.509 CERTIFICATES PROFILES ...48
6.1 PROFILE OF THE INITIAL X.509 CERTIFICATE...49
6.2 PROFILE OF THE DERIVED X.509 CERTIFICATE...49
6.2.1 Fields of a Derived X.509 certificate...49
6.2.2 Extensions of a Derived X.509 certificate...50
1. INTRODUCTION... I
2. CONTENTS OF THE DESCRIPTION ... I 2.1 SET SECTION... I 2.2 ALISASES SECTION... I 2.3 DESCRIPTIVE SECTION... I
2.3.1 Identification mechanisms ...II
2.3.1.1 General mechanism...II 2.3.1.2 Mechanisms for repeated structures...II 2.3.1.3 Mechanisms for data elements composites ...II
2.3.2 STATUS ...II 2.3.3 VALUE...III 2.3.4 IF THEN ELSE ...III
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 e-mail, 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.
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 client-server 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 e-mail 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.
• 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.
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 9594-8, 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.
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 inter-operable 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.
2.2.1 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 TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature 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 }
2.2.1.1 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.
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.
2.2.1.2 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).
2.2.1.3 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.
2.2.1.4 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
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.
2.2.1.5 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.
2.2.1.6 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.
2.2.1.7 Subject Public Key Info
The ASN.1 definition of the SubjectPublicKeyInfo type is given as follows:
SubjectPublicKeyInfo ::= SEQUENCE{ algorithm AlgorithmIdentifier, subjectPublicKey BITSTRING
This field is used to carry the public key and identify the algorithm with which the key is used.
2.2.1.8 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.
2.2.2 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.
2.2.2.1 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 1.2.2 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
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
2.2.2.1.1 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
2.2.2.1.1.1 Authority key identifier
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.
2.2.2.1.1.2 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.
2.2.2.1.1.3 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 {
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.
2.2.2.1.1.4 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
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.
2.2.2.1.1.5 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.
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 9834-1. 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] }
2.2.2.1.1.6 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.
2.2.2.1.2 Certificate subject and certificate issuer attributes
The following extensions are defined:
a) Subject alternative name b) Issuer alternative name c) Subject directory attributes
2.2.2.1.2.1 Subject alternative name
The ASN.1 definition of the Subject alternative name type is given as follows:
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
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.
2.2.2.1.2.2 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.
2.2.2.1.2.3 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 } }
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.
2.2.2.1.3 Certification path constraints
The following extensions are defined:
a) Basic constraints b) Name constraints c) Policy constraints
2.2.2.1.3.1 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.
2.2.2.1.3.2 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 {
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.
2.2.2.1.3.3 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.
2.2.2.1.4 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 } }
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:
- a Directory entry
whose CRL attribute will contain a revocation entry for that certificate, if it has been revoked; or
- 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. In the interests of interoperability, it is recommended that it be flagged non-critical.
2.2.2.2 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
2.2.2.2.1 Subject Information Access
The ASN.1 definition of the Subject Information Access type is given as follows:
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.
2.2.2.2.2 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 AccessDescription, 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.
2.2.2.2.3 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
certificates may include both an authority and a caInfoAccess extension to describe access methods for both the CA and its issuer.
3. TECHNICAL ANALYSIS OF THE UN/EDIFACT CERTIFICATE
3.1 Notations
The following notation is used to describe the UN/EDIFACT certificate structure: Label Description
Pos The sequential position number of the segment, stand-alone data element or composite data element in the segment table (only used in version 4).
Tag 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 Name of a segment, composite data element or stand-alone data element in capital letters.
Name of a component data element in small letters. S The status of the segment or data element:
M mandatory C conditional
R 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)
Repr. Data value representation of the data element: a alphabetic characters
n numeric characters an alphanumeric characters
a3 3 alphabetic characters, fixed length n3 3 numeric characters, fixed length an3 3 alphanumeric characters, fixed length a..3 up to 3 alphabetic characters
n..3 up to 3 numeric characters an..3 up to 3 alphanumeric characters
3.2 UN/EDIFACT Version 3 Certificate
3.2.1 General Structure
A UN/EDIFACT version 3 certificate group consists of a sequence of five UN/EDIFACT segments:
USC "Certificate", contains the credentials of the certificate owner and (optional) of the certificate issuer.
USA "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.
USA "Security Algorithm", the signature algorithm used to sign the hash value computed by the hash function designated in the aforementioned USA segment.
USA "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)
USR "Security Result", the result of applying the hash function given in the USA segment for issuer hashing (Element USA.S502.0523, Value: 4 - IHA) and the signature algorithm given in the USA segment for issuer signature (Element USA.S502.0523, 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.
3.2.2 Segment USC - Certificate
Function: To convey the public key and the credentials of its owner.
TAG Name S Repr.
0536 CERTIFICATE REFERENCE C an..35
S500 SECURITY IDENTIFICATION DETAILS C
0577 Security party qualifier M an..3
0538 Key name C an..35
0511 Party Id identification C an..17
0513 Code list qualifier C an..3
0515 Code list responsible agency C an..3
0586 Party name C an..35
0586 Party name C an..35
0586 Party name C an..35
S500 SECURITY IDENTIFICATION DETAILS C
0577 Security party qualifier M an..3
0538 Key name C an..35
0511 Party Id identification C an..17
0513 Code list qualifier C an..3
0515 Code list responsible agency C an..3
0586 Party name C an..35
0586 Party name C an..35
0586 Party name C an..35
0544 FORMAT CERTIFICATE VERSION C an..3
0505 FILTER FUNCTION, CODED C an..3
0507 CHARACTER SET ENCODING, CODED C an..3 0543 CHARACTER SET REPERTOIRE, CODED C an..3 0546 USER AUTHORISATION LEVELS C an..35
S505 SEPARATOR FOR SIGNATURE C
0548 Separator for signature C an..4
0551 Separator for signature qualifier C an..3
S505 SEPARATOR FOR SIGNATURE C
0548 Separator for signature C an..4
0551 Separator for signature qualifier C an..3
S505 SEPARATOR FOR SIGNATURE C
0548 Separator for signature C an..4
0551 Separator for signature qualifier C an..3
S505 SEPARATOR FOR SIGNATURE C
0548 Separator for signature C an..4
0551 Separator for signature qualifier C an..3
S501 SECURITY DATE AND TIME C
0515 Date and time qualifier, coded M an..3
0502 Date C n8
0504 Time C n6
S501 SECURITY DATE AND TIME C
0515 Date and time qualifier, coded M an..3
0502 Date C n8
0504 Time C n6
0506 UTC offset C an..5
S501 SECURITY DATE AND TIME C
0515 Date and time qualifier, coded M an..3
0502 Date C n8
0504 Time C n6
0506 UTC offset C an..5
3.2.3 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..3
0525 Cryptographic mode of operation, coded C an..3 0533 Mode of operation code list identifier C an..3
0527 Algorithm, coded C an..3
0529 Algorithm code list identifier C an..3
S503 ALGORITHM PARAMETER C
0532 Algorithm parameter value C an..512 0531 Algorithm parameter qualifier, coded C an..3
S503 ALGORITHM PARAMETER C
0532 Algorithm parameter value C an..512 0531 Algorithm parameter qualifier, coded C an..3
S503 ALGORITHM PARAMETER C
0532 Algorithm parameter value C an..512 0531 Algorithm parameter qualifier, coded C an..3
S503 ALGORITHM PARAMETER C
0532 Algorithm parameter value C an..512 0531 Algorithm parameter qualifier, coded C an..3
S503 ALGORITHM PARAMETER C
0532 Algorithm parameter value C an..512 0531 Algorithm parameter qualifier, coded C an..3
3.2.4 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..256
3.3 UN/EDIFACT Version 4 Certificate
3.3.1 General Structure
A UN/EDIFACT version 4 certificate group consists of a sequence of five UN/EDIFACT segments:
USC "Certificate", contains the credentials of the certificate owner and (optional) of the certificate issuer.
USA "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.
USA "Security Algorithm", the signature algorithm used to sign the hash value computed by the hash function designated in the aforementioned USA segment.
USA "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)
USR "Security Result", the result of applying the hash function given in the USA segment for issuer hashing (Element USA.S502.0523, Value: 4 - IHA) and the signature algorithm given in the USA segment for issuer signature (Element USA.S502.0523, 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.
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
010 0536 CERTIFICATE REFERENCE C 1 an..35
020 S500 SECURITY IDENTIFICATION DETAILS C 2 2
0577 Security party qualifier M an..3
0538 Key name C an..35 3
0511 Security party identification C an..17 0513 Security party code list qualifier C an..3 0515 Security party code list responsible agency, coded C an..3
0586 Security party name C an..35
0586 Security party name C an..35
0586 Security party name C an..35
030 0544 FORMAT CERTIFICATE VERSION C 1 an..3
040 0505 FILTER FUNCTION, CODED C 1 an..3 4
050 0507 ORIGINAL CHARACTER SET ENCODING, CODED C 1 an..3 5 060 0543 CERTIFICATE ORIGINAL CHARACTER SET
REPERTOIRE, CODED
C 1 an..3 6 070 0546 USER AUTHORISATION LEVELS C 1 an..35
080 S505 SEPARATOR FOR SIGNATURE C 5 7
0550 Separator for signature M an..4
0551 Separator for signature qualifier M an..3
090 S501 SECURITY DATE AND TIME C 4 8
0517 Date and time qualifier M an..3
0338 Date, extended C n..8
0314 Event time C n..15 9
0336 Time offset C n4 10
100 0567 SECURITY STATUS, CODED C 1 an..3 1
110 0569 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. S500.0538, identifies the public key.
4. 0505, filter function used for the binary fields of the USA and USR segments.
5. 0507, character set encoding used when the certificate was signed, if different from current. 6. 0543, 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
• certificate start of validity period • certificate end of validity period • revocation date and time
9. S501.0314, a ‘Z’ as last character indicates UTC time. (ISO 8601) 10. S501.0336, 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.
3.3.3 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 1
0523 Use of algorithm, coded M an..3
0525 Cryptographic mode of operation, coded C an..3 0533 Mode of operation code list identifier C an..3
0527 Algorithm, coded C an..3
0529 Algorithm code list identifier C an..3
020 S503 ALGORITHM PARAMETER C 5
0530 Algorithm parameter value M an..512 0531 Algorithm parameter qualifier M an..3
3.3.4 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 1
0563 Validation value qualifier M an..3
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.
3.4.1 USC - Certificate
3.4.1.1 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