Using Certificate Extensions - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Chapter 5. Planning the Certificate System
SHA1withRSA is the default signing algorithm for CAs for RSA certificates. SHA1withEC is the default
signing algorithm for CAs for ECC certificates.
Along with a key type, each key has a specific bit length. Longer keys are considered cryptographically
stronger than shorter keys. However, longer keys require more time for signing operations.
The default RSA key length in the configuration wizard is 2048 bits; for certificates that provide access
to highly sensitive data or services, consider increasing the length to 4096 bits. ECC keys are much
stronger than RSA keys, so the recommended length for ECC keys is 256 bits, which is equivalent in
strength to a 2048-bit RSA key.

5.4.5. Using 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, require Netscape-specific extensions because they
were developed before PKIX part 1 standards were defined.
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.
• CRL checking. Since it is 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.
The X.509 v3 specification addressed these issues by altering the certificate format to include
additional information within a certificate by defining a general format for certificate extensions and
specifying extensions that can be included in the certificate. The extensions defined for X.509 v3
certificates enable additional attributes to be associated with users or public keys and manage
the certification hierarchy. The Internet X.509 Public Key Infrastructure Certificate and CRL Profile
recommends a set of extensions to use for Internet certificates and standard locations for certificate or
CA information. These extensions are called standard extensions.
68