X500Standard.com

X.509 is part of the X.500 Series of Recommendations. However, X.509 is a subject of its own. It also has a life outside the remaining of X.500. It is the basis for many other specifications, such as the Secure Socket Layer (SSL) and the IETF PKIX specifications. X.509 is about message integrity, authentication and authorisation.

The X.509 specification covers the following aspects:

• Basic aspects as introduced by this page.
• Public-Key Certificates.
• Public-Key Infrastructure (PKI).
• Attribute Certificates.
• Privilege Management Infrastructure (PMI).
• How a directory may be protected using different techniques.

The basic aspects of X.509 considered here are:

• Message digest (hashing)
• Public-key encryption
• Digital signature
• Hashing, encryption and signature algorithms

Message digest (hashing)

Hashing is the transformation of a message into a usually shorter fixed-length string value called a message digest that represents the original string using some kind of hashing algorithm. To be useful, such an algorithm must have the following characteristics:

• The transformation must be irreversible, that is, it shall not be possible from the message digest to reconstruct the original message, even when the algorithm is known.
• Even a small change in the message shall change the corresponding message digest significantly.
• Given a specific message, it must be virtually impossible to create another message resulting in the same message digest. This property is sometimes referred to as weak collision resistance, and functions that lack this property are vulnerable to second-preimage attacks.
• It must be virtually impossible to create two messages resulting in the same message digest. Such a pair is called a hash collision. This property is sometimes referred to as strong collision resistance.

A message digest may be used to give some level of message integrity. If the message digest is attached a transmitted message together with an identification of the used hashing algorithm, the receiver can create its own message digest and compare it with the one attached. If different, the message has been changed during the transfer and should be discarded.

There are several hashing algorithm defined as exemplified later on this page.

Public-key encryption

Transmitting a message digest together with a message only gives limited protection. It only protect against modification during transfer, but is does not provide any authentication of the creator of the message. Authentication of the creator of a message may be accomplished by the the use of a so-called asymmetric encryption technique. This technique is described briefly in the following.

There are two distinct types of encryption:

• Symmetric encryption, where the same encryption key is used for encrypting and decrypting a message. This is less of a problem in a closed environment, However, if one entity encrypt a message and another entity decrypt the same message, and visa verso, they must trust each other to keep the key well protected. In a wider community, it becomes even more problematic. An entity may have several keys to protect, one for each communications partner.
• Asymmetric encryption, which is the subject for this section.

Asymmetric encryption requires the use of two related keys. Such a key-pair consists of a private key and a corresponding public key. A message encrypted using one of these keys can only be decrypted using the other key. Each key is the inverse function of the other; what one does, only the other one can undo. The owner of the key pair shall keep the private key in confidence. Copies of the public key may be distributed to several parties.

• A message encrypted using a public key can then only be decrypted using the corresponding private key. This may be used, as an example, to encrypt e-mails with a public key and then send it to the owner of the private key. Only the owner of the private key is able to decrypt this e-mail.
• A message encrypted using the private key can be decrypted by anyone holding a copy of the public key. If decryption is possible (and the result is sensible), only the holder of the private key could have sent this message. This technique is used to create digital signatures as discussed next.

Digital signature

A digital signature is like a handwritten signature. Only one specific entity can have created the signature.

The following steps are taken by the sender when creating a digitally signed message:

• A message digest is generated using some hashing algorithm.
• Using the private key, the message digest is encrypted to create the signature.
• The digital signature is appended the message.
• As illustrated in figure 2, the identification of the signing algorithm, that is, the combination of the hashing algorithm and the encryption algorithm, is also attached. The signing algorithm is identified by an ASN.1 object identifier.

The following steps are taken by the receiver of a digitally signed message:

• The signature is decrypted using the public key to restore the message digest as generated by the sender.
• A local message digest of the message is generated.
• The two message digests are compared for equality. If identical, the receiver knows that the message has been transmitted unchanged and that the sender's identity is known with a high level of certainty. This gives an end-to-end security also in a distributed environment.

Hashing, encryption and signature algorithms

A hashing, an encryption or a signature algorithm is identified by an object identifier. Some algorithms, but not all, require some parameters to be applied by the algorithm. These parameters are supplied as part of the algorithm identifier. The fact the the parameters are not always there (OPTIONAL in ASN.1 sense), is indicated by square bracket in figure 3.

 AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
   algorithm   ALGORITHM.&id ({SupportedAlgorithms}),
   parameters  ALGORITHM.&Type ({SupportedAlgorithms}{@algorithm}) OPTIONAL }

In the ASN.1 notation, the algorithm identifier is written as as parametrized data type, where the components are fields of the ALGORITHM ASN.1 information object class. This parametrized data type take as argument (also called a parameter) the set of supported algorithms.

There has been some confusion about the above ASN.1 specification. At one time this resulted in the parameters component being mandatory. If an AlgorithmIdentifier instance did not require the parameters component, this field was given the ASN.1 NULL value. This notation is still in use in many documents. It is recommended not to specify NULL for the parameters component, but the leave out the component. However, an implementation evaluating an AlgorithmIdentifier instance should accept a NULL value and consider that as equivalent to the component being absent.

Hashing algorithms

Several hashing algorithm have been defined for use in an X.509 environment. RFC 3279 describes the following hashing algorithm together with their identifying object identifiers:

• MD2 - This is a hashing algorithm not recommended anymore, as some weaknesses have been identified. It is fully described in RFC 1319.
• MD5 - This hashing algorithm has also shown some weakness. It is fully described in RFC 1321.
• SHA-1 - This hashing algorithm produces a 160-bit hash of the input. It can handle a message of any length less than 2⁶⁴ bits. It is widely used. It is further described in RFC 3174. A sample code in programming language C for generate an SHA-1 is also provided by this RFC. The official specification is given in FIPS 180-3.

RFC 4055 list the algorithm identifier for a SHA-2 series of hashing algorithms, while FIPS 180-3 gives the official specifications.

• SHA-224 and SHA-256 - These algorithms can handle a message of any length less than 2⁶⁴ bits. The final result of SHA-256 is a 256-bit message digest. The procedure to generate a SHA-224 is almost exactly the same as for SHA-256, but the resulting message digest is truncated to 224 bits.
• SHA-384 and SHA-512 - These algorithms can handle a message of any length less than 2¹²⁸ bits. The final result of SHA-512 is a 512-bit message digest. The procedure to generate a SHA-384 is almost exactly the same as for SHA-512, but the resulting message digest is truncated to 384 bits.

RFC 4491 introduces GOST R 34.11-94 developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". The algorithm GOST R 34.11-94 produces a 256-bit hash value of an arbitrary finite bit length input.

Encryption algorithms

RFC 5480

There are different public-key (asymmetric) algorithms available. So, presenting an encryption key is not enough for an entity to encrypt or decrypt. The type of encryption algorithm for which the key is constructed must also be known by the user of the key.

RFC 3279 describes the following encryption algorithms together with their identifying object identifiers:

• RSA - This algorithm is widely used in within an X.509 environment. There are no parameters associated with this algorithm.
• DSA - Digital Signature Algorithm is a United States Federal Government standard or FIPS for digital signatures. It is fully described in FIPS 186-3. It has associated parameter as described in RFC 3279.
• Diffie-Hellman - This algorithm is further described in RFC 2631.

RFC 2528

Signature algorithms

A signature algorithm is a combination of a hashing algorithm and an encryption algorithm identified by a single object identifier.

RFC 3279 describes the following encryption together with their identifying object identifiers:

• Md2 with RSA
• Md5 with RSA
• SHA-1 with RSA
• SHA-1 with DSA