Cryptographic Service Providers
CSPs implement specific security algorithms and key strength based on
security requirements (e.g., 1024-bit RSA public key generation, 128-bit RC2 and RC4 encryption, 56-bit Data Encryption Standard--DES). You can configure one application with different CSPs according to your business' needs and export restrictions. For example, you might use Microsoft Enhanced Cryptographic Provider (which supports 1024-or-greater-bit RSA public key, 128-bit RC2/RC4, DES, and 3DES) in North America, and Microsoft Base Cryptographic Provider (which supports 512-bit RSA public key and 40-bit RC2/RC4) outside North America to comply with export laws. When you need to specify a CSP in an application, simply choose the CSP you want from NT's installed CSPs. Screen 1 shows how you can easily choose a CSP by using Certificate Server's Certificate Template Wizard.
In addition to the base and enhanced CSPs that Microsoft includes in NT
4.0, Win2K includes more CSPs to meet your security needs--for example, RSA, Digital Signature Standard (DSS), Diffie-Hellman, and various base smartcard CSPs. Third-party developers can write proprietary CSPs that you can install after Microsoft ap-proves the CSPs' use in NT. For example, Datakey, a company providing smartcard products, shipped a Microsoft-approved CSP called SignaSURE Cryptographic Provider, which fulfills all major cryptographic functions in smartcards.
Physically, a CSP is a .dll file. Most CSPs are software-based, but you can implement a CSP on hardware. For example, a vendor might implement its
proprietary smartcard CSP in its smartcard reader adapter to heighten
performance and efficiency.
Certificate Server
Microsoft delivered Certificate Server 1.0 in IIS 4.0 for NT 4.0 and is
building a new version of Certificate Server in Win2K. Both versions let you request, issue, and manage keys and X.509v3 certificates. Certificate Server 1.0 provides a simple Web interface for certificate request and management, which Screen 2 shows. A user can retrieve a CA certificate and request client certificates via the Certificate Enrollment Tools hotlink after connecting an IE or Netscape browser to the certificate server. Administrators can issue and revoke certificates via the Certificate Administration Queue Utility hotlink. Certificate Server 1.0 also supplies several command lines for advanced operations, such as Web server certificate issuance and key and certificate database backup and restoration. You can use Certificate Server 1.0 to issue Web certificates in your intranet. Unfortunately, Certificate Server 1.0 lacks a comprehensive administrative GUI to customize certificate types and policy
settings. You must use the Certificate Server software development kit (SDK) for customization.
Compared with Certificate Server 1.0, Certificate Server in Win2K takes a big leap forward in functionality. In addition to Web interface support, Win2K's Certificate Server provides two user-friendly GUI tools for certificate and key management, Certificate Manager and Certificate Server Manager. Both tools are Microsoft Management Console (MMC) snap-ins. Certificate Manager is a client tool for requesting and managing CA and client certificates in a client computer. Certificate Server Manager is an administrative tool for issuing, revoking, and managing certificates in the certificate database and executing other administrative tasks, such as key and certificate database backup and restoration. Certificate Server in Win2K takes full advantage of Win2K's policy features and Active Directory (AD), using AD to store and publish certificates. Certificate Server in Win2K uses Group Policy Editor, an MMC snap-in, to set up
certificate policies in AD. Figure 2 shows the basic components and functions of Certificate Server in Win2K.
Certificate Manager. Certificate Manager manages client and CA certificates a client computer keeps in five certificate stores: personal, trusted-root CA, intermediate CA, enterprise-trusted CA, and AD user object. From within the personal store, you can request a client certificate from a CA by using the certificate request wizard. When the CA grants your request and
issues the certificate, you can either immediately install the certificate into
the personal store or install it into the personal store later by searching for
the certificate in AD and retrieving it into the personal store. A certificate
in the personal store can reside in the local machine's Registry or in a
smartcard. In addition, you can renew expired certificates and restore current valid certificates that you have lost in your local machine from within the personal store.
Certificate Server in Win2K can issue three kinds of client certificates: user, computer, and NT service. However, each type of client certificate requires a separate Certificate Manager snap-in in MMC.
Certificate Manager preinstalls several public CA certificates (e.g., AT&T's,
GTE's, and VeriSign's) in the trusted-root CA store. If your company's CA in
Win2K is a root CA (i.e., a CA that issues and signs its CA certificate), you
place that CA's certificate in the trusted-root CA store.
Certificate Server in Win2K supports CA hierarchy, also called certificate
hierarchy. In a CA hierarchy, you can have a public root CA issue your company's
CA certificate. If you do so, your Win2K CA becomes a subordinate CA of the
public root CA. You store the subordinate CA certificate in the intermediate CA
store. Using the CA hierarchy, you can easily establish CA trust relationships
with other companies and your business partners. For example, if Company X is a
subordinate CA of the public-root CA of which your company is also a
subordinate, your company's CA and Company X's CA automatically trust each
other. You save your trusted CA certificates in the enterprise-trusted CA store.
In addition to the personal, trusted-root CA, intermediate CA, and
enterprise-trusted CA stores, which physically keep client and CA certificates,
Certificate Manager provides an AD user object store. The AD user object store
doesn't physically contain certificates but rather supplies pointers that point
to a particular user's certificates published in AD. The AD user object store
lets users easily identify all of their certificates, including those they have
not retrieved into their personal store.
Register
