 |
A certificate is a data package that completely identifies an entity,
and is issued by a Certification Authority (CA) only after that
authority has verified the entity's identity.
The data package includes the public key that belongs
to the entity. When the sender of a message signs the message with
its private key, the recipient of the message can use
the sender's public key (retrieved from the certificate either sent
with the message or available elsewhere on the network)
to verify that the sender is legitimate.
The X.509 protocol defines the following structure for public-key certificates:
Version |
Serial Number |
Signature Algorithm |
Issuer Name |
Period of Validity- Not Before Date
- Not After Date
|
Subject Name |
Subject's Public Key |
Extensions |
Signature |
The version field identifies the certificate format. The serial number
is unique within the CA. The Signature Algorithm identifies
the algorithm used to sign the certificate. Issuer is the name of the CA.
The period of validity is a pair of dates; the certificate is valid during the time
period between the two. Subject is the name of the user to whom the certificate
is issued. The subject's public key field includes the algorithm name
and the public key itself. The last field is the CA's signature.
In order for digital certificates to be effective,
the users of the network must have a high level of trust in the certificate.
But what happens if someone doesn't trust the CA
- perhaps the person has never heard of the CA before.
This problem is addressed in the certifying process by something
called the hierarchy of trust.
The concept of hierarchy of trust is simply that the
process must begin with some certifying authority that
everyone agrees is trustworthy.
This ultimate authority is called the root authority.
The root authority then can certify other CAs below it,
who can then certify CAs below them, etc. This is illustrated on the following
diagram:
When someone receives a certificate that has
been issued by a first- or second-tier CA, he or she can verify
that the CA that signed the certificate has been certified by a CA at
the tier above it and that, in turn, that CA has been certified
by the one above it, and so on until a chain of trust exists
between the lower level CA (or a user certificate) and the root CA.
For example, in the preceding diagram, it can be verified that
CA #4 was certified by CA #1 and that CA #1 was certified by the root CA.
This means that when a certificate from a lower-level CA is passed along
with the encrypted message, all of the certificates in
its chain of trust up to the root should be passed along with it.
A certificate request is a signed data package that contains a person's
information such as name, email address, company name etc, and
his/her public key. A certificate request is generated by a person
wishing to obtain a certificate from the CA. Certificate requests
are signed by the person's private key to prevent tampering
with during transmission.
When the CA receives a certificate request it extracts a person's
name and public key information and performs a certain procedure
aimed at verifying that the public key really belongs to the person
whose name is included in the certificate request. If the verification
process is successful, the CA issues the certificate and sends it to the
requestor.
Certificates can also be revoked, either because the user's key has been
compromised, the CA's key has been compromised, or because
the CA no longer wants to certify the user. Each CA maintains a list
of all revoked but not expired certificates. When Alice receives a new
certificate she should check to see if it has been
revoked. She can check a database of revoked keys on the network
or locally cached list or revoked certificates.
|
 |
|
|
 |