Chapter: Cryptography and Network Security
X.509 Certificates
X.509 Certificates
1. Overview:
issued by a Certification Authority (CA),
containing:
version
(1, 2, or 3)
serial
number (unique within CA) identifying certificate
signature
algorithm identifier
issuer
X.500 name (CA)
period of
validity (from - to dates)
subject
X.500 name (name of owner)
subject
public-key info (algorithm, parameters, key)
issuer
unique identifier (v2+)
subject
unique identifier (v2+)
extension
fields (v3)
signature
(of hash of all fields in certificate)
notation CA<<A>> denotes certificate
for A signed by CA
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. Each
certificate 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
an important standard because the certificate structure and authentication
protocols
defined
in X.509 are used in a variety of contexts. For example, the X.509 certificate
format is
used in
S/MIME), IP Security and SSL/TLS and SET
2. 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.
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.
4. 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.
4. Issuer name:
X.500
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 is valid.
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 the issuing 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 the subject 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 3 and are
discussed later in this section.
Signature:
Covers
all of the other fields of the certificate; it contains the hash code of the
other fields, encrypted with the CA's private key. This field includes the
signature algorithm identifier.
The
standard uses the following notation to define a certificate:
CA<<A>> = CA {V, SN,
AI, CA, TA, A, Ap}
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 code appended
The CA
signs the certificate with its private key. If the corresponding public key is
known to a user, then that user can verify that a certificate signed by the CA
is valid.
3. Obtaining a User's Certificate
User
certificates generated by a CA have the following characteristics:
o
Any user with access to the public key of the CA
can verify the user public key that was certified.
o
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.
If there
is a large community of users, it may not be practical for all users to
subscribe to the same CA. Because it is the CA that signs certificates, each
participating user must have a copy of the CA's own public key to verify
signatures. This public key must be provided to each user in an absolutely
secure (with respect to integrity and authenticity) way so that the user has
confidence in the associated certificates. Thus, with many users, it may be
more practical for there to be a number of CAs, each of which securely provides
its public key to some fraction of the users.
Now
suppose that A has obtained a certificate from certification authority X1
and B has obtained a certificate from CA X2. If A does not securely
know the public key of X 2, then B's certificate, issued by X2,
is useless to A.
A can
read B's certificate, but A cannot verify the signature. However, if the two
CAs have securely exchanged their own public keys, the following procedure will
enable A to obtain B's public key:
o
A obtains, from the directory, the certificate of X2
signed by X1. Because A securely knows X1's public key, A
can obtain X2's public key from its certificate and verify it by
means of X1's signature on the certificate.
o
A then goes back to the directory and obtains the
certificate of B signed by X2 Because A now has a trusted copy of X2's
public key, A can verify the signature and securely obtain B's public key.
A has
used a chain of certificates to obtain B's public key. In the notation of
X.509, this chain is
expressed
as
X1<<X2>>
X2 <<B>>
In the
same fashion, B can obtain A's public key with the reverse chain:
X2<<X1>>
X1 <<A>>
This
scheme need not be limited to a chain of two certificates. An arbitrarily long
path of CAs can be followed to produce a chain. A chain with N elements would
be expressed as
X1<<X2>>
X2 <<X3>>... XN<<B>>
In this
case, each pair of CAs in the chain (Xi, Xi+1) must have
created certificates for each other.
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 another user's public-key
certificate. X.509 suggests that CAs be arranged in a hierarchy so that
navigation is straightforward.
From
X.509, is an example of such a hierarchy. 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:
o
Forward certificates: Certificates of X generated
by other CAs
o
Reverse certificates: Certificates generated by X
that are the certificates of other CAs
4. CA Hierarchy Use
In the
example given below , user A can acquire the following certificates from the
directory to establish a certification path to B:
X<<W>>
W <<V>> V <<Y>> <<Z>> Z <<B>>
When A
has obtained these certificates, it can unwrap the certification path in
sequence to recover a
trusted
copy of B's public key. Using this public key, A can send encrypted messages to
B. If A wishes to receive encrypted messages back from B, or to sign messages
sent to B, then B will require A's public key, which can be obtained from the
following certification path:
Z<<Y>>
Y <<V>> V <<W>> W <<X>>X <<A>>
B can
obtain this set of certificates from the directory, or A can provide them as
part of its initial message to B.
Certificate Revocation
o
certificates have a period of validity
o
may need to revoke before expiry, for the following
reasons eg:
§
user's private key is compromised
§
user is no longer certified by this CA
§
CA's certificate is compromised
o
CA‟s maintain list of revoked certificates
§
the Certificate Revocation List (CRL)
o
users should check certs with CA‟s CRL
Related Topics