Internet.Security

certification paths in the Internet environment. Encryption and authentication rules are provided with well-known cryptographic algorithms.

X.500 specifies the directory service. X.509 describes the authentication service using the X.500 directory. A standard certificate format of X.509 which was defined by ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8 was first published in 1988 as part of the X.500 directory recommendations. 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), published in 1993, includes specifications for a PKI based on the X.509 v1 certificate (RFC 1422). Experience has shown that the X.509 v1 and v2 certificate formats are not adequate enough in several aspects. It was found that more fields were needed to contain necessary information for PEM design and implementation. In response to these new requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 v3 certificate format. It extends the v2 format by including additional fields. Standardisation of the basic format of X.509 v3 was completed in June 1996.

The standard extensions for use in the v3 extensions field can convey data such as subject identification information, key attribute information, policy information and certification path constraints. 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 for the Internet.

X.509 defines a framework for the provision of authentication services by the X.500 directory to its users. X.509 is an important standard because the certificate structure and authentication protocols defined in X.509 are used in a various areas. The X.509 certificate format is used in S/MIME for e-mail security, IPsec for network-level security, SSL/TLS for transport-level security, and SET for secure payment systems.

6.5.1 X.509 v1 Certificate Format

As stated above, the X.509 certificate format has evolved through three versions: version 1 in 1988, version 2 in 1993 and version 3 in 1996. We start by describing the v1 format.

This format contains information associated with the subject of the certificate and the CA who issued it. The certificate (value equals 0) contains a version number, a serial number, the CA signature algorithm, the names of the subject and issuer, a validity period, a public key associated with the subject, and a issuer’s signature. These basic fields are as shown in Figure 6.13. The certificate fields are interpreted as follows:

•Version: In this field the format of the certificate is identified as the indicator of version 1, 2 or 3 format. The 1988 X.509 certificate v1 format is used only when basic fields are present. The value of this field in a v1 format is assigned as ‘0’. The v2 certificate format is assigned the value ‘1’. The value of this field is 2, signifying a v3 certificate.

•Serial number: This is an integer assigned by the CA to each certificate. In other words, this field contains a unique identifying number for this certificate, assigned by the issuing CA. The issuer must ensure that it never assigns the same serial number to two distinct certificates.

224 INTERNET SECURITY

Figure 6.13 X.509 version 1 certificate format.

•Signature: The algorithm used by the issuer in order to sign the certificate is specified. The signature field contains the algorithm identifier for the algorithm used to sign the certificate.

•Issuer: This field provides a globally unique identifier of the authority signing the certificate. The syntax of the issuer name is an X.500 distinct name. This field contains the X.500 name of the issuer that generated and signed the certificate. The DN is composed of attribute type – attribute value pairs.

•Validity: This field denotes the start and expiry dates/times for the certificate. The validity field indicates the dates on which the certificate becomes valid (not before) and on which the certificate ceases to be valid (not after). In other words, it contains two time and date indications that denote the start and the end of the time period for which the certificate is valid. The validity field always uses UTCTime (Coordinated Universal Time) which is expressed in Greenwich Mean Time (Zulu).

•Subject : The purpose of the subject field is to provide a unique identifier of the subject of the certificate. The syntax of the subject name will be an X.500 DN. This field contains the name of the entity for whom the certificate is being generated. The field denotes the X.500 name of the holder of the private key, for which the corresponding public key is being certified.

•Subject public-key information: This field contains the value of a public key of the subject together with an identifier of the algorithm with which this public key is to be used. It includes the subject public-key field and an algorithm identifier field with algorithm and parameters subfields.

to make the issuer’s name unambiguous in the event that the same name has been reassigned to different entities over time.

•Subject unique identifier: This field is present in the certificate to deal with the possibility of reuse of subject names over time. This field is an optional bit string used to make the subject name unambiguous in the event that the same name has been reassigned to different entities over time.

Submissive CAs do not issue certificates that include these unique identifiers. Submissive PKI clients are not required to process certificates that include these unique identifiers. However, if they do not process these fields, they are required to reject certificates that include these fields.

6.5.3 X.509 v3 Certificate Format

The Internet PEM RFCs, published in 1993, include specifications for a PKI based on X.509 v1 certificates. The experience gained from RFC 1422 indicates that the v1 and v2 certificate formats are deficient in several respects. In response to the new requirements and to overcome the deficiencies, ISO/IEC/ITU and ANSI X9 developed the X.509 v3 certificate format. This format extends the v2 format by including provision for additional extension fields. The addition of these extension fields is the principal change introduced to the v3 certificate.

Although the revision to ITU-T X.509 that specifies the v3 format is not yet published, the v3 format has been widely adopted and is specified in ANSI X 9.55 – 1995, and the IETF’s Internet Public Key Infrastructure working document (PKIX1). In June 1996, standardisation of the basic X.509 v3 was completed. The v3 certificate includes the 11 fields as shown in Figure 6.15. The version field describes the version of the encoded certificate. The value of this field is 2, signifying a version 3 certificate.

ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use in the v3 extensions field. These extensions can convey data such as additional subject identification information, key attribute information, policy information and certification path constraints. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it will be necessary to specify a profile for use of the v3 extensions tailored for the Internet.

The extensions defined for the v3 certificates provide methods for associating additional attributes with users or public keys and for managing the certification hierarchy. The v3 format also allows communities to define private extensions to carry information unique to those communities.

Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 encoded structure is the value of the octet string extnValue.

Conforming CAs must support such extensions as authority and subject key identifiers, key usage, certification policies, subject alternative name, basic constraint, and name and policy constraints. The format and content of certificate extensions in the Internet PKI are described in the following.

The standard extensions can be divided into the following groups:

Figure 6.15 X.509 version 3 certificate format.

•Key and policy information

•Subject and issuer attributes

•Certification path constraints

•Extensions related to CRLs.

6.5.3.1Key and Policy Information Extensions

The key and policy information extensions convey additional information about the subject and issuer keys. The extensions also convey indicators of certificate policy. The extensions facilitate the implementation of PKI and allow administrators to limit the purposes for which certificates and certified keys are used.

Authority key identifier extension

The authority key identifier extension provides a mean of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys. The identification is based on either the subject key identifier in the issuer’s certificate or the issuer name and serial number.

The key identifier field of the authority key identifier extension must be included in all certificates generated by conforming CAs to facilitate chain building. The value of the key identifier field should be derived from the public key used to verify the certificate’s signature or a method that generates unique values. This field helps the correct certificate for the next certification authority in the chain to be found.

Subject key identifier extension

The subject key identifier extension provides a means of identifying certificates that contain a particular public key.

To facilitate chain building, this extension must appear in all conforming CA certificates including the basic constraints extension. The value of the subject key identifier is the value placed in the key identifier field of the authority key identifier extension of certificates issued by the subject of the certificate.

For CA certificates, subject key identifiers should be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are:

•The key identifier is composed of the 160-bit SHA-1 hash value of the bit string of the subject public key.

•The key identifier is composed of a four-bit-type field with 0100 followed by the least significant 60 bits of the SHA-1 hash value of the bit string of the subject public key.

For end entity certificates, the subject key identifier extension provides a means of identifying certificates containing the particular public key used in an application. For an end entity which has obtained multiple certificates from multiple CAs, the subject key identifier provides a mean to quickly identify the set of certificates containing a particular public key.

Key usage extension

This extension defines the key usage for encryption, signature and certificate signing with the key contained in the certificate. When a key which is used for more than one operation is to be restricted, the usage restriction is required to be employed. An RSA key should be used only for signing; the digital signature and/or non-repudiation bits would be asserted. Likewise, when an RSA key is used only for key management, the key encryption bit would be asserted. Bits in the key usage type are used as follows:

•The digital signature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than non-repudiation (bit 1), certificate signing (bit 5) or revocation information signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity.

•The non-repudiation bit (bit 1) is asserted when the subject public key is used to verify digital signatures used to provide a non-repudiation service. This service protects against the signing entity falsely denying some action, excluding certificate or CRL signing.

•The key encryption bit (bit 2) is asserted when the subject public key is used for key transport. For example, when an RSA key is used for key management, then this bit will be asserted.

•The data encryption bit (bit 3) is asserted when the subject public key is used to encipher user data, other than cryptographic keys.

•The key agreement bit (bit 4) is asserted when the subject public key is used for key agreement. For example, when Diffie – Hellman exchange is used for key management, then this bit will be asserted.

•The key certificate signing bit (bit 5) is asserted when the subject public key is used to verify a signature on certificates. This bit is only asserted in CA certificates.

•The CRL sign bit (bit 6) is asserted when the subject public key is used to verify a signature on revocation information.

•The encipher only bit (bit 7) is undefined in the absence of the key agreement bit. When this bit is asserted and the key agreement bit is also set, the subject public key can be used only to encipher data while performing key agreement.

•The decipher only bit (bit 8) is undefined in the absence of the key agreement bit. When the decipher only bit is asserted and the key agreement bit is also set, the subject public key can be used only to decipher data while performing key agreement.

This profile does not restrict the combinations of bits that may be set in an instantiation of the key usage extension.

Private-key usage period extension

This extension allows the certificate issuer to specify a different validity period for the private key than the certificate. The extension is intended for use with digital signature keys and consists of two optional components, ‘not before’ and ‘not after’. The private key associated with the certificate should not be used to sign objects before or after the times specified by the two components, respectively. CAs conforming to this profile must not generate certificates with private-key usage period extensions unless at least one of the two components is present.