...
- The decision whether to enable or disable key escrow for an organization (resp., department) is made when the organization (resp., department) is created. This decision is final and cannot be subsequently modified.
- Important Note: All current organizations have key escrow enabled. The only way to change this is to create a new organization instance in the CSM. (InCommon made the decision about key escrow many months in advance of deploying client certificates, when SSL was the only service in operation and the key escrow functionality in CSM was still in its infancy. Since we didn't want to disable potentially useful functionality for an entire organization's life cycle, we chose to enable escrow for all organizations.)
- If key escrow is enabled for an organization, client certificates can not be issued until a RAO initializes the key escrow database for the organization. The importance of this one-time operation can not be overemphasized.
- As RAOs create new departments, an independent decision must be made whether or not to enable key escrow for the department. If key escrow is enabled for the department, client certificates can not be issued until a DRAO initializes the key escrow database for that department. The initialization process for the department is exactly the same—and just as important—as it is for the organization.
A Note about Organizations and Departments in the CSM
In the CSM, the organization and department constructs do not represent a parent/child hierarchy. Organization settings are thought of as settings that apply to issued certificates when no department is specified. Departments settings are independent of organization settings. Consequently, for example, an organization may or may not have key escrow enabled, but this is completely independent of whether or not any particular department has key escrow enabled. As another example, just as only one key usage template may be applied to a department, so only one key usage template may be applied to an organization. In many ways, an organization is just another department, at least in the CSM.
| Anchor | ||||
|---|---|---|---|---|
|
Key Usage
...
The various key usage types permit different approaches to key escrow, which is applicable to encryption keys but not signing keys. In addition to signing and/or encryption, any Standard Assurance Client Certificate may be used for SSL/TLS client authentication regardless of the key usage type. Be aware, however, that we expect dual-use client certificates to work with the widest variety of software implementations. Consequently, organizations are strongly encouraged to test the compatibility of Standard Assurance Client Certificates, especially signing-only and encryption-only client certificates, with relevant devices and software prior to deployment.
Key Usage
...
Templates
If an organization is to issue client certificates, the MRAO assigns one key usage type template (KUT) template to that organization. Likewise if a department is to issue client certificates, the RAO assigns one KUT template to that department. Thus only one KUT template can be configured per organization or department. This means, for example, that if your Physics department wishes to use two types of certificates (e.g., signing-only and encryption-only), then you will have to create two departments in the CSM, something like "Physics-Signing" and "Physics-Encryption." Alternatively, depending on your deployment requirements, you may wish to architect your departments by function rather than by academic unit. For example, you could create three departments for the entire campus, say, "Standard Signing Cert," "Standard Encryption Cert," and "Standard Dual-Use Cert." How you create your departments is up to you of course.
...