X.509 Certificates
Transcript of X.509 Certificates
-
7/30/2019 X.509 Certificates
1/25
X.509 CERTIFICATES
R.Muthukkumar
Asst.Prof. (SG) /IT
NEC, Kovilpatti
-
7/30/2019 X.509 Certificates
2/25
Introduction
ITU-T recommendation X.509 is part of the
X.500 series of recommendations that
define a directory service.
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 of the type
-
7/30/2019 X.509 Certificates
3/25
Each certificate contains thepublic key of a
userand is signed with the private keyof atrusted certification authority.
In addition, X.509 defines alternative
authentication protocols based on the use
of public-key certificates.
X.509 certificate format is used in S/MIME,
IP Securityand SSL/TLS.
X.509 is based on the use ofpublic-key
cryptographyand digital signatures.
-
7/30/2019 X.509 Certificates
4/25
Certificates
The heart of the X.509 scheme is the public-keycertificate 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 certificationfunction; it merely provides an easily accessible
location for users to obtain certificates.
-
7/30/2019 X.509 Certificates
5/25
Public-Key Certificate Use
-
7/30/2019 X.509 Certificates
6/25
X.509 Formats
-
7/30/2019 X.509 Certificates
7/25
Version: Differentiates among successiveversions of the certificate format; the default isversion 1. If the issuer unique identifierorsubjectunique identifier are present, the value must beversion 2. If one or more extensions are present,the version must be version 3.
Serial number: An integer value unique withinthe issuing CA that is unambiguously associatedwith this certificate.
Signature algorithm identifier: The algorithmused to sign the certificate together with anyassociated parameters. Because this informationis repeated in the signature field at the end of thecertificate, this field has little, if any, utility.
-
7/30/2019 X.509 Certificates
8/25
Issuer name: X.500 is the name of the CA thatcreated and signed this certificate.
Period of validity: Consists of two dates: the firstand last on which the certificate is valid.
Subject name: The name of the user to whom thiscertificate refers. That is, this certificate certifies thepublic key of the subject who holds thecorresponding private key.
Subjects public-key information: The public keyof the subject, plus an identifier of the algorithm forwhich 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 theevent the X.500 name has been reused for
different entities.
-
7/30/2019 X.509 Certificates
9/25
Subject unique identifier: An optional-bit string
field used to identify uniquely the subject in theevent 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 andare discussed later in this section.
Signature: Covers all of the other fields of the
certificate; it contains the hash code of the otherfields encrypted with the CAs private key. This
field includes the signature algorithm identifier.
-
7/30/2019 X.509 Certificates
10/25
The unique identifier fields were added in
version 2 to handle the possible reuse ofsubject and/or issuer names over time.
These fields are rarely used.
The standard uses the following notation
to define a certificate:
-
7/30/2019 X.509 Certificates
11/25
-
7/30/2019 X.509 Certificates
12/25
The CA signs the certificate with its private
key.
If the corresponding public key is known toa user, then that user can verify that a
certificate signed by the CA is valid.
-
7/30/2019 X.509 Certificates
13/25
Obtaining A Users 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 key that wascertified.
No party other than the certification authority
can modify the certificate without this being
detected
-
7/30/2019 X.509 Certificates
14/25
Now suppose that A has obtained a
certificate from certification authority X1and B has obtained a certificate from CA
X2 .
If A does not securely know the public
key of X2, then Bs certificate, issued by
X2, is useless to A.
A can read Bs certificate, but A cannotverify the signature. However, if the two
CAs have securely exchanged their own
public keys
-
7/30/2019 X.509 Certificates
15/25
The following procedure will enable A to obtain
Bs public key.
Step 1: A obtains from the directory the
certificate of X2 signed by X1 . Because A
securely knows s X1public key, A can obtain s
X2 public key from its certificate and verify it bymeans ofs X1 signature on the certificate.
Step 2: A then goes back to the directory and
obtains the certificate of B signed by X2.
Because A now has a trusted copy of X2s publickey, A can verify the signature and securely
obtain Bs public key.
-
7/30/2019 X.509 Certificates
16/25
A has used a chain of certificates to obtain
Bs public key. In the notation of X.509,this chain is expressed as
In the same fashion, B can obtain Aspublic key with the reverse chain:
-
7/30/2019 X.509 Certificates
17/25
This scheme need not be limited to achain of two certificates. An arbitrarily long
path of CAs can be followed to produce a
chain. A chain with elements would beexpressed as
-
7/30/2019 X.509 Certificates
18/25
-
7/30/2019 X.509 Certificates
19/25
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: Certificatesgenerated by X that are the certificates of
other CAs
-
7/30/2019 X.509 Certificates
20/25
In this example, user A can acquire the
following certificates from the directory toestablish a certification path to B:
-
7/30/2019 X.509 Certificates
21/25
When A has obtained these certificates, it can
unwrap the certification path in sequence to
recover a trusted copy of Bs 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, thenB will require As public key, which can be
obtained from the following certification path:
B can obtain this set of certificates from the
directory, or A can provide them as part of its
initial message to B.
-
7/30/2019 X.509 Certificates
22/25
Revocation of Certificates
1. The users private key is assumed to becompromised.
2. The user is no longer certified by this
CA. Reasons for this include that thesubjects name has changed, thecertificate is superseded, or the certificatewas not issued in conformance with the
CAs policies. 3. The CAs certificate is assumed to be
compromised.
-
7/30/2019 X.509 Certificates
23/25
Each CA must maintain a list consisting of all
revoked but not expired certificates issued by
that CA, including both those issued to usersand to other CAs. These lists should also be
posted on the directory.
Each certificate revocation list (CRL) postedto the directory is signed by the issuer and
includes the issuers name, the date the list
was created, the date the next CRL is
scheduled to be issued, and an entry for each
revoked certificate.
-
7/30/2019 X.509 Certificates
24/25
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.
The user could check the directory eachtime a certificate is received
-
7/30/2019 X.509 Certificates
25/25
To avoid the delays (and possible costs)
associated with directory searches, it is
likely that the user would maintain a localcache of certificates and lists of revoked
certificates.