Netscape Certificate Management System 6.1, Руководство администратора

Страница: 718 / 840

Introduction to Certificate Extensions
718 Netscape Certificate Management System Administrator’s Guide • February 2003
• 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 may wish to restrict the use of certificates
for policy reasons. For example, some certificates may be restricted to client
authentication only.
• Multiple certificates—It’s not uncommon for certificate users to possess
multiple certificates with identical subject names but different key material. In
this case, it’s 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 may find it convenient to store
additional information in certificates, for example for situations in which it’s
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.
• CRL checking—Since it’s not always possible to check a certificate’s revocation
status against a directory or with the original certificate authority, it is useful
for certificates to include information about where to check CRLs.
Eventually, the X.509 v3 specification addressed many of these issues by amending
the certificate format to include additional information within a certificate—the
version 3 format defines a general format for certificate extensions and specifies a
number of standard extensions that can be included the certificate. Thus, the
extensions defined for X.509 v3 certificates enable you to associate additional
attributes with users or public keys and manage the certification hierarchy. The
Internet X.509 Public Key Infrastructure Certificate and CRL Profile (see
http://www.ietf.org/rfc/rfc2459.txt
, http://www.ietf.org/rfc/rfc3280.txt
and
http://www.ietf.org/rfc/rfc3279.txt
) for the RFCs that describe
extensions) recommends a set of extensions to be used in Internet certificates (and
standard locations for certificate or CA information). These extensions are called
standard extensions.
The X.509 v3 standard for certificates also suggests that you can define your own
extensions and include them in certificates you issue. These extensions are called
private, proprietary, or custom extensions and they carry information unique to your
organization or business. Keep in mind that applications may not able to validate
certificates that contain private, critical extensions, thus preventing the use of these
certificates in a general context.