Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION, Administration Manual

Page: 481 / 554

459
Appendix A. Certificate and CRL
Extensions
This appendix explains both the standard certificate extensions defined by X.509 v3 and the
extensions defined by Netscape that were used in versions of products released before X.509 v3
was finalized. It provides recommendations for extensions to use with specific kinds of certificates,
including PKIX Part 1 recommendations.
This appendix contains the following sections:
•
Section A.1, “Introduction to Certificate Extensions”
•
Section A.2, “Note on Object Identifiers”
•
Section A.3, “Standard X.509 v3 Certificate Extensions”
•
Section A.4, “Introduction to CRL Extensions”
•
Section A.5, “Standard X.509 v3 CRL Extensions”
A.1. Introduction to Certificate Extensions
An X.509 v3 certificate contains an extension field that permits any number of additional fields to be
added to the certificate. Certificate extensions provide a way of adding information such as alternative
subject names and usage restrictions to certificates. Older Netscape servers, such as Red Hat
Directory Server and Red Hat Certificate System, that were developed before PKIX part 1 standards
were defined require Netscape-specific extensions.
The X.509 v1 certificate specification was originally designed to bind public keys to names in an X.500
directory. As certificates began to be used on the Internet and extranets and directory lookups could
not always be performed, problem areas emerged that were not covered by the original specification.
•
Trust
. The X.500 specification establishes trust by means of a strict directory hierarchy. By contrast,
Internet and extranet deployments frequently involve distributed trust models that do not conform to
the hierarchical X.500 approach.
•
Certificate use
. Some organizations restrict how certificates are used. For example, some
certificates may be restricted to client authentication only.
•
Multiple certificates
. It is not uncommon for certificate users to possess multiple certificates with
identical subject names but different key material. In this case, it is necessary to identify which key
and certificate should be used for what purpose.
•
Alternate names
. For some purposes, it is useful to have alternative subject names that are also
bound to the public key in the certificate.
•
Additional attributes
. Some organizations store additional information in certificates, such as when it
is not possible to look up information in a directory.
•
Relationship with CA
. When certificate chaining involves intermediate CAs, it is useful to have
information about the relationships among CAs embedded in their certificates.