Draft
Digital certificates, or just certificates, are
computer-based files or structures used to convey information about a
user for identification purposes [Gerck 97]. Certificates are
based on the ITU-T Recommendation X.509 [ITU-T 97]. There are
a number of different certificates (called end-entity
certificates) defined in the X.509 specification:
- Personal certificates represent individuals, and are
typically used to secure e-mail and access to web servers.
- Server certificates indicate that a server belongs to
the company it claims to belong to.
- Developer certificates are used by developers to sign
software or other objects.
A certificate binds an identity (a name) to a public key. The
certificate includes the name of the person (e.g., Bob), their public
key (e.g., Bob's public key), and a digital signature sealing the
data. This information can be verified (authenticated) by validating
the digital signature.
Similar to the signature and stamp of a Notary Public, the digital
signature is added by a trusted third party known as a certificate
authority (CA). Certificate authorities confirm the relationship
between identities and their public keys. Certificate authorities
also publish public keys that then verify end-entity certificates.
This process uses the public key of the authority that issued the
certificate to validate the digital signature.
So, how do you get the public key of a certificate authority? In
addition to end-entity certificates, the X.509 specification defines
certificate authority certificates. These special
certificates identify third party organizations entrusted to validate
the identity of individuals requesting end-entity certificates.
Similar to end-entity certificates, CA certificates contain a name
(the name of the authority), a public key, and a digital signature
sealing the data. CA certificates are critical in obtaining
end-entity certificates and close the circle of trust.
Certificates are obtained by sending a request to a certificate
authority. Information about an individual (for personal
certificates) a site, or company is sent to a CA along with a public
key. The package sent to the CA is called a certificate signing
request and is also defined in the X.509 specification.
Upon receiving the request, the certificate authority validates
the contents through a process defined and published by the
authority. The authority validates the digital signature placed on
the signing request to ensure that it is a valid public key (i.e., it
is part of a public/private key pair). Ultimately, confidence in the
certificate is based on the trust you place on the certificate
authority's assurance mechanism.
If the information contained within the certificate request is
recognized as genuine, the authority generates the requested
certificate. In addition, the authority chains their
certificate to the new certificate. This allows an individual
receiving the certificate to identify the authority that issued it,
and to consider this information when deciding to accept or reject
the certificate.
As this discussion demonstrates, the mathematical sophistication
of public key encryption (PKI) ultimately rests upon a foundation of
public trust. That is, we trust that a public key belongs to a
particular individual, and this trust is vested in one or more
authorities. Alice believes she possesses Bob’s public key
because she trusts the authority that told her so.
Certificates are used when it is necessary to positively and
uniquely identify and bind an end-entity for the purposes of
non-repudiation, confidentiality, and integrity in public key
encryption systems.
In many cases use and application of public key cryptography
requires the use of certificates (such notable exceptions include PGP
[Pretty Good Privacy]) so that the owner of a public key can
be known. Certificates are supposed to follow the X.509 specification
which governs the format of certificates. X.509 is now in version 3
of the specification, commonly known as X.509v3. What is good about
version 3 of the specification is that it permits certificate
extensions - allowing application developers and system designers to
embed additional information within the certificate itself (such as
limitations on the specific use of a certificate). The X.509v3
specification is generally supported by all that report to support
certificates, but known cases of incompatibilities exist between
software that generates certificates and software that parses
certificates. In most cases, the incompatibilities have been traced
to poor implementation of the X.509v3 specification either in the
generation or parsing of X.509v3 certificates. Some maturation of
certificate technology should be expected.
See Costs and Limitations associated with public
key cryptography.
Although the specification of the base certificate (version 1 and
version 2) is fairly mature (as it is backwards compatible), X.509v3
extension can cause incompatibilities between applications that
generate and use certificates. Although many examples exist it is
recommended that those looking into the use of certificate technology
in public key cryptography systems learn about specific X.509v3
extension that are either required or expected to exist before
selecting certificate management software.
This technology is classified under the following categories.
Select a category for a list of related topics.
|
Name of technology
|
Certificates
|
|
Application category
|
Information
Security (AP.2.4)
|
|
Quality measures category
|
Security
(QM.2.1.5)
|
|
Computing reviews category
|
Operating Systems Security & Protection (D.4.6),
Security & Protection (K.6.5),
Computer-Communications Networks Security and Protection
(C.2.0)
|
