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