...
- 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 is 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.
...
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 Department 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.
...
If an organization is to issue client certificates, the MRAO assigns one key usage template (KUT) to that organization. Likewise if a department is to issue client certificates, the RAO assigns one KUT to that department. Thus only one KUT 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 of course up to you of course.
| Anchor | ||||
|---|---|---|---|---|
|
...
Key escrow provides for offline storage of users' private keys in an encrypted database for the purposes of backup and recovery. Once an escrow database is created for an organization or department, it cannot be removed from the system or made inactive.
...