|
Chapter 18
Extension-Specific Policy Modules
Certificate Management System comes with a set of extension-specific policy plug-in modules that enable you to add X.509 certificate extensions to the certificates the server issues. This chapter explains those modules--it lists and briefly describes the modules that are installed with a Certificate Manager and Registration Manager, and then explains each one in detail.
The chapter has the following sections:
|
 Certificate Extensions |
|
Since its initial publication, the X.509 standard for certificate formats has been amended to include additional information within a certificate. Version 3, the latest version, allows you to add additional information as certificate extensions. For example, Netscape applications (Netscape Navigator 3.0 or higher, and Enterprise Server 2.01 or higher) support an extension that specifies the type of certificate issued (such as client, server, or object signing).
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) 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 standard 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.
Note
Some explanations in this chapter make reference to Abstract Syntax Notation
One (ASN.1) and Distinguished Encoding Rules (DER). These are specified in
the CCITT Recommendations X.208 and X.209. For a quick summary of ASN.1
and DER, see A Layman's Guide to a Subset of ASN.1, BER, and DER, which is
available at RSA Laboratories' web site (http://www.rsa.com).
Structure of Certificate Extensions
In RFC 2459, an X.509 certificate extension is defined as follows:
Extension ::= SEQUENCE {
Which means, a certificate extension consists of the following:
Examples of standard extensions defined in the X.509 v3 standard include the following:
Note that not all applications support certificates with version 3 extensions. Applications that do support these extensions may not be able to interpret some or all of these specific extensions.
Sample Certificate Extensions
The following is an example of the section of a certificate containing X.509 v3 extensions. (Certificate Management System can display certificates in human-readable format, as shown here.) As shown in the example, certificate extensions appear in sequence and only one instance of a particular extension may appear in a particular certificate; for example, a certificate may contain only one subject key identifier extension. Note that certificates that support these extensions have the version 0x2 (which corresponds to version 3).
Certificate:
Data:
Version: v3 (0x2)
...
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL CA
Identifier: Subject Key Identifier
Critical: no
Value:
2c:22:c6:ae:4e:4b:91:c7:fb:4c:cc:ae:84:e8:aa:5b:46:6a:a0:ad
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
2c:22:c6:ae:4e:4b:91:c7:fb:4c:cc:ae:84:e8:aa:5b:46:6a:a0:ad
Object Identifier
An object identifier (OID) is a string of numbers identifying a unique object, for example, a certificate extension or a company's certificate practice statement. For general information on OIDs, see the information at this URL:
http://www.alvestrand.no/objectid/
OIDs are controlled by the International Standards Organization (ISO) registration authority. In some cases, this authority is delegated by ISO to regional registration authorities. For example, in the United States, the American National Standards Institute (ANSI) manages this registration.
Registration of Object Identifiers
To promote interoperatability, the PKIX standard recommends that all objects (such as extensions and policy statements) that appear in certificates that will be used in networks shared by other organizations should be included in the form of OIDs. If you plan to issue certificates that will be used in such networks, you should register your object identifier prefixes with the appropriate registration authority. For example, assume you want to add a custom extension that points to a certificate practice statement (CPS) of your company. To implement this, you need to compose the policy statement you want to include in the extension, define an OID for the policy statement, and configure Certificate Management System with the OID so that it can add that to the certificate it issues.
The use of an OID registered to another organization or the failure to register an OID may carry legal consequences, depending on context. Registration may be subject to fees. For more information, you should contact the appropriate registration authority.
To define or assign OIDs for your objects, you must know your company's arc, which is an OID for a private enterprise. If your company doesn't have an arc, it needs to get one. This URL contains information on registering for a company arc:
http://www.isi.edu/cgi-bin/iana/enterprise.pl
To understand why you need to have a company arc, check the information at this site:
http://www.alvestrand.no/objectid/2.16.840.1.113730.1.13.html
The site contains information on Netscape-defined OID for an extension named Netscape Certificate Comment. Note that the OID assigned to this extension is hierarchical and it includes the Netscape company arc, which is 2.16.840.1.113730. Every OID Netscape owns has this prefix.
When determining whether to add custom extension to certificates, keep in mind that if the extension exists in a certificate and if it is marked critical, the application validating the certificate must be able to interpret the extension (including the optional qualifiers, if any), or else it must reject the certificate. Since it's unlikely that all applications will be able to interpret your company's extensions (embedded in the form of OIDs), the PKIX standard recommends that the extension be always marked noncritical. For general guidelines on setting extensions in certificates, see "Certificate Extensions" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
|
| Overview of Extension-Specific Policy Modules |
|
To enable you to add standard and private extensions to end-entity certificates, Certificate Management System provides a set of policy plug-in modules; each module enables you to add a particular extension to a certificate request. Plug-in modules are implemented as Java classes and are registered in the CMS policy framework. The Policy Plugin Registration tab of the CMS window (Figure 18.1) lists all the modules that are registered with a CMS instance.
When deciding whether to add any of the X.509 v3 certificate extensions, keep in mind that not all applications support X.509 v3 extensions. Among the applications that do support extensions, not all applications will recognize every extension. For general guidelines on using extensions in certificates, see "Certificate Extensions" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
Figure 18.1 Extension policy modules registered with a Certificate Manager 
Table 18.1 lists extension-specific policy modules that are installed with a Certificate Manager. A Registration Manager installation also includes all the modules, expect for the ones noted below:
You can use these modules to configure a Certificate Manager and Registration Manager to add extensions to certificates. Both subsystems add extensions to a certificate request when it undergoes policy processing (see "Policy Processor"). Keep in mind that the changes made to a request by a Registration Manager may be overwritten by a Certificate Manager when it subjects the request to its own policy checks.
As indicated in Table 18.1, Certificate Management System enables you to add almost all of the extensions defined in the PKIX standard RFC 2459 (http://www.ietf.org/rfc/rfc2459.txt). All modules have three features in common, enabling you to specify these:
Additionally, the server also provides a module for adding any custom, ASN.1 type extensions. If you determine that the default policy modules do not meet your requirements entirely, you can develop a custom module using CMS SDK. It is available in the form of Java Docs at this location:
<server_root>/cms_sdk/sdkdocs
For general guidelines on developing custom policy modules and adding them to the CMS policy framework, take a look at the samples installed at these locations:
<server_root>/cms_sdk/samples/policy and
<server_root>/cms_sdk/samples/exttools
For instructions to configure a Certificate Manager and Registration Manager to use one or more of the policy modules, see "Configuring a Subsystem's Policies".
|
| Authority Information Access Extension Policy |
|
The AuthInfoAccessExt plug-in module implements the authority information access extension policy. This policy enables you to configure Certificate Management System to add the Authority Information Access Extension defined in X.509 and PKIX standard RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt) to certificates. The extension specifies how the application validating the certificate can access information, such as on-line validation services and CA policy statements, about the CA that has issued the certificate in which the extension appears. Note that this extension should not be used to point directly to the CRL location maintained by the CA; the CRL Distribution Points extension explained in "CRL Distribution Points Extension Policy" allows you to reference to CRL locations.
The PKIX standard recommends that you may include the authority information access extension in end-entity and CA certificates and that the extension be marked noncritical. For general guidelines on setting the authority information access extension, see "authorityInfoAccess" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
The authority information access extension policy in Certificate Management System allows you to set the authority information access extension as defined in its X.509 definition. The policy enables you to specify any number of access points for CA information. For each access point, you can specify the access method, actual location that contains the additional information about the CA, and the mechanism for retrieving the information. The location can be specified in any of the following general-name forms: an rfc822name, a directory name, a DNS name, an EDI party name, a uniform resource indicator (URI), an IP address, an object identifier (OID), and any other name.
By default, the policy supports two access methods:
The built-in support for the ocsp access method and a URI value for the access location in the extension conform to the profile defined in RFC 2560 (see http://www.ietf.org/rfc/rfc2560.txt) for CAs that support the OCSP service. For details about OCSP support in Certificate Management System, see "Supported Methods for Verifying Revocation Status of Certificates".
If you configure a Certificate Manager to publish CRLs to an OCSP responder and want to include the authority information access extension referencing to the responder, you should configure an instance of this policy as follows: access method is set to ocsp, name type is set to URI, and name value is set to the URL at which the OCSP responder listens to OCSP requests. This way, OCSP-compliant applications can verify the revocation status of certificates issued by the Certificate Manager by accessing the validation authority using the OCSP method.
Unlike some of the other policy modules, Certificate Management System does not create an instance of the AuthInfoAccessExt module during installation. If you want the server to add this extension to certificates, you must create an instance of the said module and configure it. For instructions, see "Step 4. Add New Policy Rules").
AuthInfoAccessExt Module
The Java class that implements the authority information access extension policy is as follows:
com.netscape.certsrv.policy.AuthInfoAccessExt
Figure 18.2 shows how the configurable parameters for the AuthInfoAccessExt module are displayed in the CMS window.
Figure 18.2 Parameters defined in the AuthInfoAccessExt module 
The configuration shown in Figure 18.2 creates a policy rule named AuthInfoAccessExtForClientCert, which enforces a rule that the server should add the authority information access extension to client certificates. The extension indicates that the online validation service (or the OSCSP responder) for the CA that has issued these certificates is at this URL:
http://ocspResponder.siroe.com:8000
The extension is marked noncritical (to comply with the PKIX recommendation).
Table 18.2 gives details about the configurable parameters defined in the AuthInfoAccessExt module.
|
| Authority Key Identifier Extension Policy |
|
The AuthorityKeyIdentifierExt plug-in module implements the authority key identifier extension policy. This policy enables you to configure Certificate Management System to add the Authority Key Identifier Extension defined in X.509 and PKIX standard RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt) to certificates. The extension is used to identify the public key that corresponds to the private key used by a CA to sign certificates.
You should consider adding this extension to all certificates, especially CA certificates, issued by Certificate Management System. The reason is, in certain situations, a CA's public key may change (for example, when the key gets updated) or the CA may have multiple signing keys (either due to multiple concurrent key pairs or due to key changeover). In these cases, the CA ends up with more than one distinct key. When verifying a signature on a certificate, other applications need to know which key was used in the signature. The extension, if present in a certificate, enables applications (those that can use the extension) to identify the correct key to use in situations when multiple keys exist; the extension specifies the public key to be used to verify the signature on the certificate.
For general guidelines on setting the authority key identifier extension, see "authorityKeyIdentifier" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
The authority key identifier extension policy in Certificate Management System allows setting of the authority key identifier extension as defined in its X.509 definition with key identifiers. The policy enables you to specify what is to be done if the CA certificate does not have a subject key identifier extension--whether to use the a SHA-1 hash of the CA's subject public key information (carries the public key and identifies the algorithm with which the key is used) or skip adding the authority key identifier extension itself. For information on setting the subject key identifier extension in certificates, see "Subject Key Identifier Extension Policy".
Note that PKIX and Federal PKI standards recommend against the use of authorityCertIssuer and authorityCertSerialNumber fields of the X.509 definition.
If enabled, the policy does the following:
During installation, Certificate Management System automatically creates an instance of the authority key identifier extension policy. See "AuthorityKeyIdentifierExt Rule".
AuthorityKeyIdentifierExt Module
The Java class that implements the authority key identifier extension policy is as follows:
com.netscape.certsrv.policy.AuthorityKeyIdentifierExt
Figure 18.3 shows how the configurable parameters for the AuthorityKeyIdentifierExt module are displayed in the CMS window.
Figure 18.3 Parameters defined in the AuthorityKeyIdentifierExt module 
The configuration shown in Figure 18.3 creates a policy rule named AuthKeyIDExtForCACert, which enforces a rule that the server should set the authority key identifier extension in all CA certificates.
Table 18.3 gives details about each of these parameters.
AuthorityKeyIdentifierExt Rule
The rule named AuthorityKeyIdentifierExt is an instance of the AuthorityKeyIdentifierExt module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:
For details on individual parameters defined in the rule, see Table 18.3. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Basic Constraints Extension Policy |
|
The BasicConstraintsExt plug-in module implements the basic constraints extension policy. This policy enables you to configure Certificate Management System to add the Basic Constraints Extension defined in X.509 and PKIX standard RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt) in certificates. The extension identifies whether the Certificate Manager is a CA. In addition, the extension is also used during the certificate chain verification process to identify CA certificates and to apply certificate chain-path length constraints.
You should consider adding this extension to all CA certificates (root as well as subordinate) issued by Certificate Management System. The current PKIX standard requires that this extension be marked critical and that it appear in all CA certificates. The standard also recommends that the extension should not appear in end-entity certificates. For general guidelines on setting the basic constraints extension, see "basicConstraints" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
Because the basic constraints extension is a critical extension and is used by applications to determine the path length during certificate validation to chain up to the trusted CA, it's important that you set this extension correctly.
Also note that when a user submits a certificate request using the manual-enrollment method, the basic constraints extension is set on that request as per the configured policy, and then the request is queued for agent approval. When an agent approves the request, it is subjected to the configured policy again. If there's a change in the configuration of the basic constraints extension, the server may reject the agent-approved request. For the server to approve the request, the user will have to resubmit the request.
During installation, Certificate Management System automatically creates an instance of the basic constraints extension policy. See "BasicConstraintsExt Rule".
BasicConstraintsExt Module
The Java class that implements the basic constraints extension policy is as follows:
com.netscape.certsrv.policy.BasicConstraintsExt
Figure 18.4 shows how the configurable parameters for the BasicConstraintsExt module are displayed in the CMS window.
Figure 18.4 Parameters defined in the BasicConstraintsExt module 
The configuration shown in Figure 18.4 creates a policy rule named BasicConsExtForCACert, which enforces a rule that the server should set the basic constraints extension in all CA certificates.
Table 18.4 gives details about each of these parameters.
BasicConstraintsExt Rule
The rule named BasicConstraintsExt is an instance of the BasicConstraintsExt module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:
For details on individual parameters defined in the rule, see Table 18.4. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Certificate Policies Extension Policy |
|
The CertificatePoliciesExt plug-in module implements the certificate policies extension policy. This policy enables you to configure Certificate Management System to add the Certificate Policies Extension defined in X.509 and PKIX standard RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt) in certificates. The extension contains a sequence of one or more policy statements, each indicating the policy under which the certificate has been issued and identifying the purposes for which the certificate may be used. Presence of this extension in certificates enables an application with specific policy requirements to compare its list of policies to the ones contained in a certificate during its validation; typically, such applications will have a list of policies (which they will accept) and compare the policies in the certificate to their list as a part validating the certificate.
To promote interoperatability, the PKIX standard recommends that the policy statements or information terms should be included in certificates in the form of object identifiers (OIDs). For more information on OIDs, see "Object Identifier". This means, in order for the server to add this extension to any certificate it issues, you need to compose policy statements you want to include in the extension, define OIDs for these policy statements, and configure the server with these OIDs.
When determining whether to add this extension to certificates, keep in mind that if the extension exists in a certificate and if it is marked critical, the application validating the certificate must be able to interpret the extension (including the optional qualifiers, if any), or else it must reject the certificate. For general guidelines on setting the certificate policies extension, see "certificatePolicies" in Appendix B of Netscape Certificate Management System Installation and Deployment Guide.
The certificate policies extension policy in Certificate Management System enables you to set the extension with the following information:
During installation, Certificate Management System automatically creates an instance of the certificate policies extension policy. See "CertificatePoliciesExt Rule".
CertificatePoliciesExt Module
The Java class that implements the certificate policies extension policy is as follows:
com.netscape.certsrv.policy.CertificatePoliciesExt
Figure 18.5 shows how the configurable parameters for the CertificatePoliciesExt module are displayed in the CMS window.
Figure 18.5 Parameters defined in the CertificatePoliciesExt module 
The configuration shown in Figure 18.5 creates a policy rule named CertPoliciesExtForClientCert, which enforces a rule that the server should set the certificate policies extension in all client certificates.
Table 18.5 gives details about each of these parameters.
CertificatePoliciesExt Rule
The policy rule named CertificatePoliciesExt is an instance of the CertificatePoliciesExt module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:
For details on individual parameters defined in the rule, see Table 18.5. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". Also, if you need to add additional instances, follow the instructions in "Step 4. Add New Policy Rules". For example, if you want to include different policy statements in different types of certificates, you should create multiple instances of the policy module and configure each instance with the appropriate policy OID and predicate expression.
|
| Certificate Renewal Window Extension Policy |
|
The CertificateRenewalWindowExt plug-in module implements the certificate renewal window extension policy. This policy enables you to configure Certificate Management System to add the Certificate Renewal Window Extension to certificates. The extension, which must be noncritical, aids in managing the life cycle of a certificate by specifying a process to follow for renewing a certificate and by defining a time window when automatic renewal of the certificate should be attempted.
Every certificate issued by Certificate Management System has a validity period beyond which it cannot be used. In order to continue to participate in the PKI-using system beyond this validity period, the entity owning the certificate must renew the certificate. Renewal of a certificate essentially means getting a new certificate for the existing key pair with a new validity time period (and updated attributes).
Once a certificate is issued, the owner of the certificate may attempt its renewal any time. To prevent certificate owners from renewing their certificates too often and thus reduce the overhead of processing new certificate requests, the CA can use a policy that restricts the time period when certificate renewal may occur. For example, the CA can use a policy that limits the renewal process to the last few weeks or days of validity of the certificate, thus defining a certificate renewal window. In general, the renewal window must be sufficient for the renewal to occur, but at the same time delay the renewal as long as possible to best utilize a certificate's life time.
The certificate-renewal process is often different than the enrollment process an entity uses to obtain the certificate; this is because the entity already owns a key pair that is associated with his or her identity. For example, in Certificate Management System, the certificate-renewal process for end users is different than the enrollment process they used to obtain the certificate. To renew their certificates, end users go to the certificate-renewal interface of Certificate Management System and submit their original certificates; for details, see "Authentication of End Users During Certificate Renewal".
Because the renewal process requires end users to remember when their certificates expire and renew them before the expiry date, some clients provide built-in support for automated renewal. Inclusion of the certificate renewal window extension in certificates is useful in a PKI setup with such clients; such a setup eliminates the need for the owner of the certificate to manually submit a renewal request to the CA and install the renewed certificate. For example, assume you have deployed clients that can automatically submit certificate-renewal requests to Certificate Management System. If you issue certificates with the certificate renewal window extension to these clients, they can then read this extension for the renewal window and automatically get the certificate renewed from the CA during that window.
For a PKI setup without clients that can handle automated certificate renewals, Certificate Management System enables administrators to easily manage certificate renewals using the following features:
Unlike some of the other policy modules, Certificate Management System does not create an instance of the certificate renewal window extension policy during installation. If you want the server to add this extension to certificates, you must create an instance of the CertificateScopeOfUseExt module and configure it (see "Step 4. Add New Policy Rules").
CertificateRenewalWindowExt Module
The Java class that implements the certificate renewal window extension policy is as follows:
com.netscape.certsrv.policy.CertificateRenewalWindowExt
Figure 18.6 shows how the configurable parameters for the CertificateRenewalWindowExt module are displayed in the CMS window.
Figure 18.6 Parameters defined in the CertificateRenewalWindowExt module 
The configuration shown in Figure 18.6 creates a policy rule named CertRenewWindowExtForClientCert, which enforces a rule that the server should set the certificate renewal window extension in client certificates only; the renewal window starts 30 days before a certificate expires and ends with certificate expiration.
Table 18.6 gives details about each of these parameters.
|
Previous
