...
Contents:
| Table of Contents |
|---|
Technical Considerations
Initially, one or more RAOs from each organization will be given the ability to manage client certificates. Before a RAO can issue client certificates, a decision regarding key escrow must be made. Key escrow (also known as "key recovery" in the CSM) is available to all subscribers of the InCommon Certificate Service for no additional fee.
| Info | ||
|---|---|---|
| ||
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. |
Enabling or disabling key escrow for organizations or departments has the following consequences:
...
| Tip | |
|---|---|
|
...
|
...
In the |
...
InCommon Certificate Manager (CM) web interface, the organization and department constructs do not constitute a parent/child hierarchy. Organization settings are settings that apply to issued certificates when no department is specified. |
...
Likewise 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 |
...
CM. |
| 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
A key usage template (KUT) is associated with each key usage type. 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.say, signing-only and encryption-only), then you will have to create two departments in the CSMCM, 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, however, is of course up to you.
| Anchor | ||||
|---|---|---|---|---|
|
Key Escrow
Key escrow (also known as "key recovery" in the CM) is available to all subscribers of the InCommon Certificate Service for no additional fee. 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.
Understanding Key Escrow
Initially, one or more RAOs from each organization will be given the ability to manage client certificates. Before a RAO can issue client certificates, a decision regarding key escrow must be made.
| Info | ||
|---|---|---|
| ||
All organizations created in the CM prior to 8 March 2011 have key escrow enabled by default. The only way to change this is to create a new organization instance in the CM. If your institution subscribed to the InCommon Certificate Service after 8 March 2011, then key escrow was not enabled by default. If your institution subscribed to the InCommon Certificate Service prior to 8 March 2011, it is highly likely that your organization was created in the CM prior to that date. In particular, if your organization began issuing SSL certificates prior to 8 March 2011, then your organization has key escrow enabled. 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 the CM 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. This policy was changed on 8 March 2011. |
Enabling or disabling key escrow for organizations or departments has the following consequences:
- The decision whether to enable or disable key escrow for an organization (resp., department) is made when the organization (resp., department) is created. The decision regarding key escrow is final and cannot be subsequently modified.
- 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 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.
| Anchor | ||||
|---|---|---|---|---|
|
...
If an RAO is given permission to issue client certificates, and the organization is configured for key escrow, the next time that RAO logs into the CMSCM, s/he will be prompted to initialize a database of encryption keys. Upon doing so, a master decryption key will be issued to the RAO. The RAO should immediately take steps to secure the master decryption key. Failure to do so will render the key escrow feature useless.
...
If the RAO does not initialize the database of encryption keys upon first login, s/he will be prompted to do so every time s/he logs into the CMSCM. If multiple RAOs are given permission to issue client certificates, all of them will be prompted to initialize the database of encryption keys. The first RAO that does so will be issued the master decryption key.
...
- As an RAO/DRAO using the web-based Certificate Services Manager
- Via CSV upload [Note: the invitation sent by email contains a link to download the certificate. As of 10/13/2011, the links don't work. A bug report has been filed.]
- Via web-based Enrollment form
- Via the API Via Active Directory linkage(for non-escrowed organizations or departments)
These methods are described in the Administrator Guide.