Ca Signing Certificate's Validity Period; Self-Signed Root Versus Subordinate Ca - Netscape MANAGEMENT SYSTEM 6.0 Installation And Setup Manual

Certificate Authority Decisions
Many people no longer consider an RSA key of length less than 1024 bits to be
cryptographically strong. Export and other regulations permitting, it may be a
good rule of thumb to start with 1024 bits and consider increasing the length to
2048 bits for certificates that provide access to highly sensitive data or services.
However, the question of key length has no simple answers. Every organization
must make its own decision based on its own security requirements. For more
information on key length and encryption strength, see Appendix D of Managing
Servers with Netscape Console.

CA Signing Certificate's Validity Period

Every certificate, including a Certificate Manager signing certificate, must have a
validity period. Certificate Management System does not restrict the validity
period you can specify. In general it's a good idea to specify as long a validity
period as possible, depending on your plans for certificate renewal, the place of the
CA in the certificate hierarchy, and the requirements of any public CAs that you
may want to include in your PKI.

Self-Signed Root Versus Subordinate CA

For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so
that you won't need to apply to a third party and wait for the certificate to be
issued. Before deploying a full-blown PKI, however, you will need to consider this
question carefully.
If you want your CA to chain up to a third-party public CA, you must carefully
consider the restrictions that public CAs place on the kinds of certificates your CA
can issue and the nature of the certificate chain. For example, a CA that chains up
to a third-party CA might be restricted to issuing only Secure Multipurpose
Internet Mail Extensions (S/MIME) and SSL client authentication certificates—not
SSL server certificates. In addition, a CA that chains up to a third-party CA might
not be allowed to have any subordinate CAs and might have to obey certain
restrictions on its use of certificate extensions. These and other restrictions may be
acceptable for some PKI deployments but not for others.
One benefit of chaining up to a public CA is that the third party is responsible for
getting the root CA certificate into the browser or other end-entity software. This
can be a major advantage if you are deploying an extranet that involves certificates
used by different companies whose browsers you cannot control. Alternatively, if
you create your own CA hierarchy from scratch, you are responsible for getting
Chapter 4 Planning Your Deployment 171