Cryptography: Module 4
MODULE 4:
X.509 CERTIFICATES
• X.509 is part of the X.500 series of recommendations that define a directory service, being
a server or distributed set of servers that maintains a database of information about users.
• X.509 defines a framework for the provision of authentication services by the X.500
directory to its users. The directory may serve as a repository of public-key certificates
• Eachcertificate contains the public key of a user and is signed with the private key of a
trusted certification authority. In addition, X.509 defines alternative authentication
protocols based on the use of public-key certificates. X.509 is based on the use of public-
key cryptography and digital signatures.
• The X.509 certificate format is widely used, in for example S/MIME, IP Security and
SSL/TLS and SET. X.509 was initially issued in 1988. The standard was ubsequently
revisedto address some of the security concerns; a revised recommendation was issued in
1993. A third version was issued in 1995 and revised in 2000.
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 1
Bengaluru
Cryptography: Module 4
Certificates
The heart of the X.509 scheme is the public-key certificate associated with each user.
These user certificates are assumed to be created by some trusted certification authority (CA)
and placed in the directory by the CA or by the user. The directory server itself is not
responsible for the creation of public keys or for the certification function; it merely provides
an easily accessible location for users to obtain certificates.
The standard uses the notation for a certificate of:
CA<<A>> where the CA signs the certificate for user A with its private key. In more
detail CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}.
If the corresponding public key is known to a user, then that user can verify that a
certificate signed by the CA is valid.
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 2
Bengaluru
Cryptography: Module 4
Version: Differentiates among successive versions of the certificate format; the default is
version 1. If the issuer unique identifier or subject unique identifier are present, the value must
be version 2. If one or more extensions are present, the version must be version 3.
Serial number: An integer value unique within the issuing CA that is unambiguously
associated with this certificate.
Signature algorithm identifier: The algorithm used to sign the certificate together with any
associated parameters. Because this information is repeated in the signature field at the end of
the certificate, this field has little, if any, utility.
Issuer name: X.500 is the name of the CA that created and signed this certificate.
Period of validity: Consists of two dates: the first and last on which the certificate isvalid.
Subject name: The name of the user to whom this certificate refers. That is, this certificate
certifies the public key of the subject who holds the corresponding private key.
Subject’s public-key information: The public key of the subject, plus an identifier of the
algorithm for which this key is to be used, together with any associated parameters.
Issuer unique identifier: An optional-bit string field used to identify uniquely theissuing CA
in the event the X.500 name has been reused for different entities.
Subject unique identifier: An optional-bit string field used to identify uniquely thesubject
in the event the X.500 name has been reused for different entities.
Extensions: A set of one or more extension fields. Extensions were added in version 3and
are discussed later in this section.
Signature: Covers all of the other fields of the certificate; it contains the hash code of theother
fields encrypted with the CA’s private key. This field includes the signature algorithm
identifier.
The unique identifier fields were added in version 2 to handle the possible reuse of subject
and/or issuer names over time. These fields are rarely used. The standard uses the following
notation to define a certificate:
CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}
where
Y<< X >> = the certificate of user X issued by certification authority Y
Y {I} = the signing of I by Y. It consists of I with an encrypted
hash
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 3
Bengaluru
Cryptography: Module 4
code appended
V = version of the certificate
SN = serial number of the certificate
AI = identifier of the algorithm used to sign the certificate
CA = name of certificate authority
UCA = optional unique identifier of the
CAA = name of user A
UA = optional unique identifier of the
user AAp = public key of user A
TA = period of validity of the certificate
Obtaining a Certificate
User certificates generated by a CA have the following characteristics:
• Any user with access to the public key of the CA can verify the user public keythat was certified.
• No party other than the certification authority can modify the certificate without this being
detected.
Because certificates are unforgeable, they can be placed in a directory without the need for
the directory to make special efforts to protect them.
If all users subscribe to the same CA, then there is a common trust of that CA. All user
certificates can be placed in the directory for access by all users. In addition, a user can transmit his
or her certificate directly to other users. In either case, once B is in possession of A’s certificate, B
has confidence that messages it encrypts with A’s public key will be securefrom eavesdropping and
that messages signed with A’s private key are unforgeable.
CA Hierarchy:
If both parties use the same CA, they know its public key and can verify others certificates.
If there is a large community of users, it may not be practical for all users to subscribe to the same
CA. Hence there has to be some means to form a chain of certificationsbetween the CA's used by
the two parties, by the use of client and parent certificates. All these certificates of CAs by CAs
need to appear in the directory, and the user needs to know how they are linked to follow a path to
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 4
Bengaluru
Cryptography: Module 4
another user's public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that
navigation is straightforward. It is assumed that each client trusts its parent’s certificates.
Above Figure illustrates the use of an X.509 hierarchy to mutually verify clients
certificates. The connected circles indicate the hierarchical relationship among the CAs; the
associated boxes indicate certificates maintained in the directory for each CA entry. The
directory entry for each CA includes two types of certificates:
Forward certificates: Certificates of X generated by other CAs,
Reverse certificates: Certificates generated by X that are the certificates of other CAs.
In this example, we can track chains of certificates as follows:
A acquires B certificate using chain
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
B acquires A certificate using chain:
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 5
Bengaluru
Cryptography: Module 4
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
Certificate Revocation:
A certificate includes a period of validity. Typically a new certificate is issued just
before the expiration of the old one.
In addition, it may be desirable on occasion to revoke a certificate before it expires,
for one of a range of following reasons:
1. The user’s private key is assumed to be compromised.
2. The user is no longer certified by this CA. Reasons for this include that the
subject’s name has changed, the certificate is superseded, or the certificate was not
issued in conformance with the CA’s policies.
3. The CA’s certificate is assumed to be compromised.
To support this, each CA must maintain a list consisting of all revoked but not expired
certificates issued by that CA, known as the certificate revocation list (CRL). Each certificate
revocation list (CRL) posted to the directory is signed by the issuer and includes the issuer's
name, the date the listwas created, the date the next CRL is scheduled to be issued, and an
entry for each revoked certificate. Each entry consists of the serial number of a certificate and
revocation date for that certificate. Because serial numbers are unique within a CA, the serial
number is sufficient to identify the certificate.
When a user receives a certificate in a message, the user must determine whether the
certificate has been revoked, by checking the directory CRL each time a certificate is
received, this often does not happen in practice.
X.509 Version 3
The X.509 version 2 format does not convey all of the information. Rather than
continue to add fields to a fixed format, standards developers felt that a more flexible
approach was needed. X.509 version 3 includes a number of optional extensions that may be
added to the version 2 format. Each extension consists of an extension identifier, a criticality
indicator, and an extension value. The criticality indicatorindicates whether an extension can
be safely ignored or not.
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 6
Bengaluru
Cryptography: Module 4
Certificate Extensions
The certificate extensions fall into three main categories:
• Key and policy information - convey additional information about the subject andissuer
keys, plus indicators of certificate policy. A certificate policy is a named set of rules that
indicates the applicability of a certificate to a particular community and/or class of
application with common security requirements.
• Subject and issuer attributes - support alternative names, in alternative formats, for a
certificate subject or certificate issuer and can convey additional information about the
certificate subject; eg. postal address, email address, or picture image
• Certification path constraints - allow constraint specifications to be included in
certificates issued for CA’s by other CA’s that may restrict the types of certificates that
can be issued by the subject CA or that may occur subsequently in a certification chain.
Dr. Nagamani N P, Dept. of ISE, JSSATE, Page : 7
Bengaluru