Creating Certificate Policies and Certificate Practice Statements
Applies To: Windows Server 2003 with SP1
The definition of certificate policies and the certificate practice statement (CPS) is often forgotten by technically-oriented planners. The basis for both the certificate policy and CPS are the organizations security policy.
Creating these documents is usually a joint responsibility of the legal, human resources, and information security departments.
.gif "Art Image")
Figure 3: Relationship Between Certificate Policy and Certificate Practice Statements
Both the certificate policy and the CPS help the user of a PKI determine the level of trust that those departments can put in the certificates that are issued by a CA. The existence of policies is critical when dealing with a reliable PKI. If certificates are exchanged only within an organization, the creation of a CPS and a security policy might not be mandatory. When this is true, some clauses regarding the use of PKI and certificates in the employee manual may be essential. Note that an organizational CPS is a CPS that covers all CAs in a hierarchy. Generally, a CPS covers only a specific CA.
A CP and CPS may prove to required when certificate holders exchange or use certificates with partners and entities that live outside of the company's network. When external trust is implemented, it is often very important to align PKI policies and practices as part of the external contract terms.
Security Policy
The security policy is a high-level document that is created by the corporate IT group. It defines a set of rules about the use and provision of security services in the organization, and should reflect your organization's business and IT strategy. The security policy should answer high-level PKI questions, such as:
What applications should be secured with certificates?
What kind of security services should be offered by using certificates?
Certificate Policy
A certificate policy focuses on certificates and the CA's responsibilities regarding these certificates. It defines certificate characteristics such as usage, enrollment and issuance procedures, as well as liability issues.
The following references define a certificate policy as a set of rules that determine if a certificate is applicable to either a community or a class of applications that have common security requirements.
For more information about the X.509 standard, see the International Telecommunication Union Web site.
For more information about the European Electronic Signature Standardization Initiative (EESSI) definition, see the EESSI Web site.
A certificate policy typically answers the question about what purposes the certificate serves, and under which policies and procedures the certificate has been issued. A certificate policy typically addresses the following issues:
How users are authenticated during certificate enrollment
Legal issues, such as liability, that might arise if the CA becomes compromised or is used for something other than its intended purpose
The intended purpose of the certificate
Private key management requirements, such as storage on smart cards or other hardware devices
Whether the private key can be exported or archived
Requirements for users of the certificates, including what users must do if their private keys are lost or compromised
Requirements for certificate enrollment and renewal
Minimum length for the public key and private key pairs
The certificate policy is typically defined by members of an organization who are known as the policy authority. The policy authority typically consists of representatives from different core departments, including management, legal, audit, human resources, and other departments. Overall, the policy authority members will also be members of the group that defined the security policy, which ensures that the certificate policy is in agreement with the security policy.
Certificate Practice Statement
The certificate practice statement (CPS) translates certificate policies into operational procedures on the CA level. The certificate policy focuses on a certificate; the CPS focuses on a CA. Both the EESSI and the American Bar Association (ABA) define a CPS as a statement about the way that a CA issues certificates. For more information about the ABA, see the ABA Web site. For more information about the EESSI, see the EESSI Web site.
A CPS might include the following types of information:
Positive identification of the CA, including the CA name, server name, and Domain Name System (DNS) address
Certificate policies that are implemented by the CA and the certificate types that are issued
Policies, procedures, and processes for issuing, renewing, and recovering certificates
Cryptographic algorithms, cryptographic service providers (CSPs), and the key length that is used for the CA certificate
Physical, network, and procedural security for the CA
The certificate lifetime of each certificate that is issued by the CA
Policies for revoking certificates, including conditions for certificate revocation, such as employee termination and misuse of security privileges
Policies for certificate revocation lists (CRLs), including where to locate CRL distribution points and how often CRLs are published
A policy for renewing the CA's certificate before it expires
The CPS should be defined by a team that consists of members of the IT department, people who are operating and administering the IT infrastructure, and the people (often attorneys) that defined the certificate policy. The CPS is a public document that should be published on the Internet. Every certificate that has been issued by a CA that follows a CPS has an URL pointer in the certificate that directs people to the public document. When a certificate has a CPS pointer as part of the certificate, the Issuer Statement button becomes available. When you click Issuer Statement, the URL that has been specified by the CA administrator is redirected.
Important
A CPS is always valid for all certificates that are issued subordinate to the CA that contains the qualifier. Make sure that all parameters that are listed in Appendix B are part of the planning process.
Revocation Policy
Before certificates are enrolled, the PKI management team should know how to revoke certificates. Any X.509 V3 certificate (except the root CA certificate itself) should have a pointer to a valid CRL. The CRL distribution point is included in the certificate's extension and cannot be modified after a certificate is enrolled.
The logical availability of the CRL distribution point that is specified in the certificate allows a PKI-enabled application to verify the certificate's validity against the CRL. The CRL is essential to ensure the quality (status) of certificates that are published by the CA. If the CRL is available and the certificate's serial number is part of the CRL, the certificate is marked as invalid from a clients perspective.
A revoked certificate's serial number is added to the CRL as long as the original certificate lifetime is valid. After the original lifetime of the certificate expires, the serial number of the certificate is added to the CRL for the last time.
Note
You cannot use revoked certificates for signing or encryption operations anymore. However, you can use revoked certificates for decryption operations, because the revoked certificates are required for decryption.
If an application is going to verify a certificate against the CRL and no valid CRL is available, the revocation check does not work and the certificate cannot be used for the transaction. If the application has properly implemented CRL checking, no authentication, encryption, or signing is allowed with this certificate until a valid CRL is available again.
For immediate revocation of logon certificates, consider disabling the account in Active Directory instead of revoking the logon certificate. It is more time efficient to delete or disable user accounts if you want to immediately revoke a user's ability to gain access to the logon certificates.
For more information about CRLs, AIA, and chain building refer to the "Troubleshooting Certificate Status and Revocation" white paper on TechNet.
CRL Best Practices
When you consider CRL distribution, you should know where and how clients can gain access to a CRL. The CRL distribution mechanism of enterprise and stand-alone CAs is different by default.
It is a common mistake to not modify the default CRL distribution point of an isolated stand-alone CA. Because a root or intermediate CA is typically disconnected from the network, PKI-enabled clients cannot validate the issued certificates against the default CRL distribution point on the CA server. To make a CRL of an offline stand-alone CA publicly available, you must manually publish the CRL or utilize a custom exitmodule or script that publishes the CRL to a predefined location. For more information about custom exit modules, see “Writing Custom Exit Modules” in the Cryptography collection of the Microsoft Platform SDK on MSDN.
An online CA on a computer that is joined to an Active Directory domain or forest automatically publishes the CRL to Active Directory so that it can be accessible through LDAP. Alternatively, the CRL can be made available through an HTTP URL that points to a location on a Web server.
Depending on the certificate types that are issued with a CA, the order of the CRL distribution points is important. For authentication certificates, it is beneficial to have a CRL or fully-qualified LDAP CRL distribution point as the first entry in the list of distribution points. If a relative LDAP CRL distribution point is specified, a client contacts the domain controller that is closest, according to the Active Directory site structure, to get the CRL. Fully-qualified LDAP CRL distribution points eliminate latency issue that may occur until the CRL has been replicated in Active Directory. For non-authentication certificates, you may want to use LDAP because LDAP is more fault-tolerant in an Active Directory environment compared to tolerance in a single-instance HTTP server.
It is also an option to set both an LDAP and HTTP CRL distribution point URL to support clients that are Active Directory-aware, as well as clients that are not running Windows and that are not Active Directory-aware. If you have a mixed client environment or both internal and external clients, it is a best practice to place the HTTP location in the CRL distribution point extension first to avoid network timeouts. Any client that retrieves a CRL on demand during certificate verification caches a copy of the CRL in the Internet Explorer temporary files until the CRL expires.
Note
It is a best practice to publish a CRL that is available externally through an HTTP location so that users and applications that are outside of the organization may perform certificate validation. It is also a best practice to use paths and naming that do not reveal the internal network infrastructure to external entities.
The CRL maintains a list of revoked certificates that have been issued by a CA. The CRL does not maintain the validity of certificates that are owned by a subordinate CA, like the CA certificate. The subordinate CA certificates revocation status is maintained by the CAs parent CA, since the parent CA has issued the subordinate CA certificate.
Since a root CA certificate has no parent CA that could maintain the CRL, there is no need to specify a CRL distribution point for the root CA certificate itself. To revoke a root CA, all certificates that have been issued by the root CA must be revoked instead.
Here are some additional planning notes:
A root CA certificate should have an empty CRL distribution point because the CRL distribution point is defined by the certificate issuer. Since the roots certificate issuer is the root CA, there is no value in including a CRL distribution point for the root CA. In addition, some applications may detect an invalid certificate chain if the root certificate has a CRL distribution point extension set.
Offline CAs must continue to publish CRLs.
If certificates are exchanged with external entities, the CRLs must be available at a location that is accessible for all internal and external entities. To satisfy this requirement, in this case the CRL is usually published in the organization's perimeter network.
To ensure redundancy, make the CRL available through more than one location.
If the CRL is distributed by using Active Directory, plan for replication latency.
Plan for CRL publications that cannot be performed as usually scheduled and have contingency operations prepared
The CRL should be valid for the amount of time that it takes for CA recovery if hardware fails or if software does not work. For example, a one-hour CRL publication period is most likely not adequate time to perform a hardware or software restoration because of the possibility of issues with either the hardware or software.
The less frequently CRLs are published, the more time you will have for issue resolution.
If a CA cannot publish the CRL on time, the CRL is not updated and will expire. If a CRL has expired, clients cannot verify certificates that would require the CRL. To prevent certificate misuse, certificates are considered invalid if the CRL has expired or is unavailable.
A Windows Server 2003 Certification Authority can publish to an IIS cluster using UNC paths for the CRL distribution point URL.
All Windows CAs follow the CRL V2 format that is specified in RFC 2459 and RFC 3280. For additional information about RFC 2459 and RFC 3280, see the Internet Engineering Task Force Web site.
LDAP CRL Best Practices
The following best practices apply to LDAP-based CRLs:
An LDAP CRL is replicated in Active Directory to all domain controllers in the forest. Because of this, it provides fault-tolerance in an environment with more than one domain controller and can be designated as "highly available."
The Active Directory replication schedule should be taken into account. This is an important consideration since it may take longer than expected for every directory server to receive the latest version of the CRL, depending on the size and replication schedule of the Active Directory environment.
CRLs should not be published to Active Directory when the CRL publication period is shorter than the replication convergence time for the Active Directory forest.
Do not use escape characters in LDAP CRL distribution point paths, such as a backslash (\).
Do not include names that are specific to either internal or organization names in the CRL distribution point. Certificates may be exchanged with external parties and those parties should not be able to obtain information about internal name spaces. To eliminate internal names in the CRL distribution point, also allow internal clients to gain access to the external distribution point, or implement a name mapping mechanism that ensures that internal clients can resolve an external name and gain access to an internal resource.
If an LDAP CRL distribution point for certificates that are exchanged with external parties is used, do not use the relative LDAP URL that points to the closest domain controller.
The first part of the name is the hosting and distribution point is the LDAP name of the server that is hosting the CRL distribution point; the second part of the name is the complete LDAP path of the directory location where the CRL is stored. The following configuration string (or LDAP reference):
ldap:///CN=,CN=
is interpreted as
ldap://ClosestDomainControllerBySite/CN=,CN=
When you use this syntax, part one of the LDAP CRL distribution point is left out, but it is automatically inserted when the CRL must be retrieved. The ldap:/// syntax forces a Windows 2000, Windows XP, or Windows Server 2003 client that is joined to an Active Directory domain to find the closest domain controller. Alternatively, a fully qualified domain name (FQDN) or an exact server path with a port value, is also supported.
Not only is the path of the CRL is important when you plan an LDAP CRL distribution point; you must also configure the correct search criteria and append that search criteria to the LDAP path.
LDAP searches support search suffixes to specify attributes, depth, and object-classes. Because the directory service may store several objects of different data types in the same location, it is important to query for the correct data. A search suffix uses the following format:
?attribute?depth?object_class
If the attribute, depth, and object_class search suffixes are missing, the client selects the correct object. Because there are different client implementations, a CRL verification might not work without this extended information.
The following example shows a relative LDAP CRL distribution point (on one line):
ldap:///CN=CorporateRootCA,CN=Root_CA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
In the sample line above, CorporateRoot, CA_Root_CA, contoso, and com are placeholders and must be replaced with parameters that are specific to the organizations requirements.
The following example shows an absolute LDAP CRL distribution point (on one line):
ldap://cdp1.contoso.com/CN=CorporateRootCA,CN=Root_CA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
In the sample line above, cdp1.contoso.com, CorporateRootCA, RootCA, contoso, and com are placeholders and must be replaced with parameters that are specific to the organization's requirements.
HTTP CRL Distribution Point URL Best Practices
Non-Windows clients might not be able to retrieve CRLs with LDAP URLs based on Active Directory. Because of this, you may need to provide an additional HTTP CRL distribution point location for LDAP-enabled clients. Computers running Windows support LDAP and HTTP URLs. The following are some best practices for HTTP CRL distribution point URLs:
If you provide an HTTP CRL distribution point location, provide fault tolerance by having either a virtual server name that points to several physical Web servers (round-robin DNS) or a clustered Web server to provide redundancy in the HTTP URL.
HTTP CRL distribution point locations are ideal for providing accessible CRL locations for clients that are not running the Windows operating system.
Place HTTP CRL distribution point URLs second in the list of the URLs in the CRL distribution point extension when Active Directory-aware clients are primarily used. This is to decrease network traffic because the client would benefit from intra-site communication with the domain controller.
Place HTTP CRL distribution point URLs first in the list of the URLs in the CRL distribution point extension when clients cannot connect to the Active Directory to verify certificates. Examples include external Web servers, VPN and remote access servers, and RADIUS (IAS) servers.
HTTP URLs should contain only valid file name characters.
Delta CRLs
In a production environment, the number of certificates that are revoked is in relation to the number of certificates that are issued. The list of revoked certificates will vary in length, depending on the number of certificates that are enrolled by a CA.
Revoked certificates are added to the CRL as a collection of certificate serial numbers. RFC 2459 and RFC 3280 define a method that you can use to reduce base CRL sizes by using delta CRLs. Delta CRLs maintain a list of certificates that have been revoked since the last base CRL publication.
Base CRLs and delta CRLs are cached by Windows clients. To ensure the validity of a certificate, the client uses the locally-cached base and delta CRL until the CRLs validity period expires. If a base CRL expires, the client retrieves a new base CRL from the distribution point that is specified in the certificate. If the base CRL is valid but the cached delta CRL is expired, a Windows client retrieves only the delta CRL. Typically, a delta CRL is much smaller in size than a base CRL because it saves only the certificates that have been revoked after the last base CRL update.
Delta CRL best practices:
Use delta CRLs with issuing CAs whenever possible.
Do not use delta CRLs with offline CAs, because there are not as many certificates that require frequent revocation. Offline CAs usually have longer CRL publication cycles than issuing CAs, since it is abnormal to revoke a large number of CA certificates.
To provide clients with the most up-to-date revocation information with smaller network utilization (compared to the network utilization that is required for a base CRL distribution), you can publish the delta CRL on a daily basis and publish the base CRL on a weekly basis. However, if a large number of certificates is revoked and if the number of revoked certificates exceeds the number of revoked certificates that are already part of the base CRL, the size of a delta CRL is larger than the size of a base CRL. Note that this scenario is very unlikely to occur and is not considered to be typical.
Do not publish frequent delta CRLs to Active Directory if replication takes a longer period than the delta CRL is valid.
Online Certificate Status Protocol Support
A Windows CA does not provide online certificate status protocol (OCSP) functionality by default. However, you can enable OCSP if you install a revocation provider in CryptoAPI or through a third-party OCSP responder that communicates with the Microsoft Certification Authority. For more information about CryptoAPI or revocation providers, search for CryptoAPI on the MSDN Web site.
Best Practices for CRL Publication
The CRL publication interval for CAs that issue certificates to CAs should be a longer period than for CAs that issue certificates to end-entities, because revocation of a CA certificate should be a very rare operation. A recommended creation interval for a new CRL of that type would be in the range of 90 to 180 days.
A CRL for an offline CA should always be published a few days before expiration to allow for unexpected issues. The publication interval for issuing CAs should be set according to the type to issued certificates. Authentication certificates might require a less frequent publication schedule than other certificate types.
For offline CA CRL publication, you should also consider these points:
For issuing CAs, a short CRL publishing schedule ensures that the CRL is current and that any revocation can be made available as quickly as possible. Note that Windows clients cache a CRL for the validity period.
For offline CAs, a longer CRL publishing schedule ensures that the CRL does not have to be regenerated and republished through the required manual generation and publishing processes.
AIA Extensions
The AIA extension allows the certificate user to obtain a current copy of the CAs current certificate. CA certificates are required when a certificate chain is built. Chain building is performed as part of the certificate verification process.
When you configure AIA extensions, use the same attention to detail that you use when you configure CRL distribution point extensions. See the following example for more information about the AIA extension in a certificate.
.gif "Art Image")
Figure 4: AIA Extensions
CA certificates are multivalued, Base64-encoded attributes in Active Directory that can store more than one CA certificate. A multivalued AIA attribute is used for every CA because a CA may have more than one valid certificate after CA renewal.
Note that multivalued attributes are limited in the number of values that they can store. You cannot sure more than 1,000 CA certificates in the AIA object.
Compared to an LDAP AIA URL that points to a multivalued object and distinguishes certificates in the same object by the search suffix, an HTTP AIA URL points only to a single file. Because of this, all HTTP URLs must include the certificate suffix (*.cer, *.crt, etc) as the suffix for the file name to distinguish between the multiple certificates that are stored in the same directory on the HTTP server
The following table describes the structure of how certificates are stored. Note that an HTTP location must be unique and only one CRL object (or file) may exist at each explicit URL path. An LDAP location is a single object in Active Directory that supports a multivalued attribute.
Table 12 Example of Stored Certificate Structure
| AIA HTTP URL (object) | AIA LDAP URL (object) | ||
|---|---|---|---|
Several files at https://www.microsoft.com/ |
concorp-ca-00_ CorporateRootCA.crt concorp-ca-00_ CorporateRootCA(1).crt concorp-ca-00_ CorporateRootCA(2).crt |
concorp-ca-00_ CorporateRootCA.crt concorp-ca-00_ CorporateRootCA(2).crt concorp-ca-00_ CorporateRootCA(2).crt |
One multivalued attribute at CN=AIA,CN=Public Key Services,CN= Services,%6%11 |
Certificate Validity Period and Key Length
The validity period of certificates depends on the organization's requirements. The following table outlines some recommendations for the validity period for different CA types.
Table 13 Recommendations for Validity Periods
| Purpose of Certificate | Certificate Life | Private Key Renewal Strategy |
|---|---|---|
Stand-alone root CA (4096-bit key) |
20 years |
Renew at least every 10 years to ensure that policy CA certificates can be issued with lifetimes of 10 years. Renew by using a new key at least every 20 years. |
Stand-alone policy CAs (2048-bit key) |
10 years |
Renew at least every 5 years to ensure that child-issuing CAs can be issued for 5 years. Renew by using a new key at least every 10 years. |
Enterprise issuing CAs for medium-security certificates (1024-bit key) |
5 years |
Renew at least every 3 years to ensure that certificates can be issued for 2 years. Renew by using a new key at least every 5 years. |
Enterprise issuing CAs for high-security certificates (2048-bit key) |
5 years |
Renew with new key at least every 4 years to ensure that certificates can be issued for a year. |
Enterprise issuing CA for external certificates (2048-bit key) |
5 years |
Renew at least every 4 years to ensure that certificates can be issued for a year. Renew by using a new key at least every 5 years. |
Secure e-mail and secure browser certificates |
1 year |
Renew by using a new key at least every 2 years. |
Smart card certificates (1024-bit key) |
1 year |
Renew by using a new key at least every 2 years. |
Administrator certificates (1024-bit key) |
1 year |
Renew by using a new key at least every 2 years. |
Secure Web server certificates (1024-bit key) |
2 years |
Renew by using a new key at least every 2 years. |
Business partners' user certificates for an extranet (1024-bit key) |
6 months |
Renew by using a new key at least every year. |
Note
All these values are suggestions and may be dictated by legal, governmental, or contractual rules that are specific to the organization. Changes of policy and extensions during renewal and rekey of CAs may also require subsequent changes of CPS recertification, audit, and so on.