This document gives a business perspective on client certificates. You may also find these wiki pages helpful:
...
For a general overview, see the InCommon Client Certificate Infosheet (pdf).
In this document, you will find these sections.
Activation
...
Process
Before client certificates can be issued, the subscriber's InCommon Executive contact must complete the Client Certificate Request form.
Although unlimited client certificates are available to all subscribers of the InCommon Certificate Service at no extra charge, a new or existing subscriber explicitly chooses whether or not to issue client certificates. This choice may be made at any time. We recommend you read this page, including the parts about key escrow and deployment, before proceeding with activation.
Information About Key Escrow - Is it Enabled or Not?
See the technical page regarding key escrow for background information.
Regarding item 2 above, if your organization subscribed to the InCommon Certificate Service after 8 March 2011, then key escrow was not enabled by default.
All organizations created after 8 March 2011 have key escrow turned off, but RAOs may still enable key escrow for new departments if they wish. For further technical details regarding key escrow, please visit our wiki.
If your institution subscribed prior to 8 March 2011, it is highly likely that your organization was created in the Certificate Manager prior to 8 March 2011. In that case, you have key escrow enabled. If you began issuing SSL certificates prior to 8 March 2011, then you have 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.
The subscriber's Executive contact acknowledges that key escrow is an add-on service provided at no additional charge, with the understanding that the InCommon Steering Committee—a representative governing body of InCommon participants—governs and determines which options and services are bundled into the base fee and which services are considered add-on services, and whether these add-on services are provided at no additional charge or for an additional fee.
Value Proposition
A subscriber to the InCommon Certificate Service may issue unlimited client certificates for no additional fee. Unlimited client certificates are a tremendous opportunity for the community. However, unlike SSL/TLS certificates, client certificates have not found widespread deployment within academia so this is largely uncharted territory for most campuses, especially at scale. Perhaps the most challenging aspect of client certificates is end-user key management, training, and support, but experimentation and collaboration groups are encouraged. Best practices and lessons learned will be our community's measures of success.
Important: This document does not address deployment issues regarding client certificates. Campus decision-makers are encouraged to seek the support of local X.509 PKI experts before undertaking experiments, pilots, or deployments. Community engagement around common use cases and support will be encouraged on the inc-cert@incommon.org mailing list as well as organized volunteer collaboration groups. Please join in. The PKI Subcommittee, which has been at the heart of the creation of our CPS documents, has created a draft Client Certificate Deployment Roadmap to start the process of collaborative co-development.
...
Client certificates may be used for signing, encryption, and authentication. Some of the more common uses of client certificates, detailed in the community-authored Client Certificate Deployment Roadmap, include:
- S/MIME
- X.509 client authentication (mobile devices, VPNs, etc.)
- signing documents (document preservation, curation, etc.)
- data and file encryption
Encryption and Key Escrow
Use cases that involve the long-term encryption of data or documents raise the issue of key backup and recovery. Accordingly, key escrow, a service offered for no additional fee to subscribers of the InCommon Certificate Service, provides for backup storage of users' private keys. Whether or not you need key escrow is a question that should be addressed early on, before you begin deploying client certificates in production:.
- If your organization intends to issue signing-only client certificates, then key escrow is probably not necessary.
- If your organization intends to use client certificates for X.509 client authentication only, then key escrow is probably not necessary.
- In general, any use of encryption in conjunction with a real-time protocol flow (such as SSL/TLS, SCEP, or SAML Web Browser SSO) probably does not require key escrow.
- If your organization intends to use client certificates to encrypt S/MIME e-mail messages, and you require guaranteed future access to unencrypted e-mail (for archival purposes or in the event of subpoena, for instance), then you probably want to consider key escrow.
- If your organization intends to use client certificates to encrypt sensitive documents or other long-lived media, then you probably want to consider key escrow.
In any case, you should seek the advice of technical and legal experts before making a decision regarding key escrow.
Policy Issues
Issuance of client certificates must comply with the corresponding Certification Practices Statement (CPS). Two campus requirements of particular note in the Client CPS are:
...
Section 4.2.1 stipulates that user's email addresses must be be validated by the Subscribing institution. Section 3.1.5 stipulates that Subject Distinguished Names (DNs) should be assigned to individuals "in perpetuity" and must uniquely map to one individual. See the CPS for Standard Assurance Client Certificates for the official language and enumeration of the requirements.
Deployment
InCommon strongly recommends that organizations follow a "Client Certificate Checklist" prior to using client certificates in production. Such a checklist might include:
...
- Convene a "tiger team" of local experts, including the administrator(s) ultimately responsible for the management of client certificates, to oversee the deployment of client certificates on your campus.
- Prepare detailed use case descriptions for client certificates, including the intended uses for signing, encryption, and authentication purposes.
- If you intend to use client certificates for encryption purposes, articulate your requirements with respect to key escrow.
- If key escrow is a requirement, create a master Decryption Key Management Plan that protects your long-term investment in key escrow.
- Consult the Certificate Manager Administrator Guide.
- Contribute to the community's success by volunteering on a collaboration group or to write lessons learned or best practices to promote the development and deployment of certificates and their interoperability across domains.Discuss issues and help others on the inc-cert@incommon.org email list.