Date: Fri, 29 Mar 2024 09:41:51 +0000 (UTC) Message-ID: <1405846508.7783.1711705311206@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7782_1123798638.1711705311205" ------=_Part_7782_1123798638.1711705311205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This document gives a technical perspective on client certificates for a= ccount administrators, campus support personnel, and others involved in the= management, deployment, and support of client certificates. For a high-lev= el perspective on client certificates, please visit our web site. See the <= a href=3D"/display/ICCS/InCommon+Cert+Types">InCommon Certificate Types= wiki page for detailed information on all types of certificates, including= client certificates, issued by the InCommon Certificate Service.
Contents:
In the InCommon Certificate Manager (CM) web interface, the organiza= tion and department constructs do not consti= tute a parent/child hierarchy. Organization settings are settings that appl= y to issued certificates when no department is specified. Likewise departme= nt settings are independent of organization settings. Consequently, for exa= mple, an organization may or may not have key escrow enabled, but this is c= ompletely independent of whether or not any particular department has key e= scrow 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 t= o an organization. In many ways, an organization is just another department= , at least in the CM.
Three key usage types of Standard Assurance Client Certificates are avai= lable to subscribers:
The key usage type of a particular Standard Assurance Client Certificate= is specified in the critical X509v3 Key Usage certificate extension (Digit= al Signature, Key Encipherment, or both). Other than that, all Standard Ass= urance Client Certificates are structurally identical.
The various key usage types permit different approaches to key escrow, which is applicable to encr= yption keys but not signing keys. In addition to signing and/or encryption,= any Standard Assurance Client Certificate may be used for SSL/TLS client a= uthentication regardless of the key usage type. Be aware, however, that we = expect dual-use client certificates to work with the widest variety of soft= ware implementations. Consequently, organizations are strongly encouraged t= o test the compatibility of Standard Assurance Client Certificates, especia= lly signing-only and encryption-only client certificates, with relevant dev= ices and software prior to deployment.
A key usage template (KUT) is associated with each key usage type. If an= organization is to issue client certificates, the MRAO assigns one 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 conf= igured per organization or department. This means, for example, that if you= r Physics department wishes to use two types of certificates (say, signing-= only and encryption-only), then you will have to create two departments in = the CM, something like "Physics-Signing" and "Physics-Encryption." Alternat= ively, depending on your deployment requirements, you may wish to architect= by function rather than by academic unit. For example, you could create th= ree departments for the entire campus, say, "Standard Signing Cert," "Stand= ard Encryption Cert," and "Standard Dual-Use Cert." How you create your dep= artments, however, is up to you.
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 i= s created for an organization or department, it cannot be removed from the = system or made inactive.
Initially, one or more RAOs from each organization will be given the abi= lity to manage client certificates. Before a RAO can issue client certifica= tes, a decision regarding key = escrow must be made.
Important Note
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 creat= e a new organization instance in the CM.
If your institution subscribed to the InCommon Certificate Service
InCommon made the decision about key escrow many months in advance of de= ploying 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 organ= ization'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 th= e following consequences:
If an RAO is given permission to issue client certificates, and the orga= nization is configured for key escrow, the next time that RAO logs into the= CM, s/he will be prompted to initialize a database of encryption keys. Upo= n doing so, a master decryption key will be issued to the RAO. The RAO shou= ld immediately take steps to secure the master decryption key. Failure to do so will render the key escrow feature useless.
By all means protect your master decryption key! If the= master key is compromised, the confidentiality of all encrypted data may l= ikewise be compromised. If the master key is lost or stolen, you will lose = the ability to recover individual decryption keys and may therefore be unab= le to decrypt previously encrypted data. Neither InCommon nor Comodo have a= ccess to the encrypted escrow databases. The decryption key that the campus= administrator takes possession of at the time of creation is the sole copy= . No master key is the same as no key escrow at all!
If the RAO does not initialize the database of encryption keys upon firs= t login, s/he will be prompted to do so every time s/he logs into the CM. I= f multiple RAOs are given permission to issue client certificates, all of t= hem will be prompted to initialize the database of encryption keys. The fir= st RAO that does so will be issued the master decryption key.
Key escrow for organizations has no bearing on whether or not key escrow= is subsequently enabled for departments. Consequently, if a DRAO is given = permission to issue client certificates, and the department is configured f= or key escrow, exactly the same initialization process as described above w= ill take place. Moreover, this will happen for every depar= tment that is configured for key escrow.
There are numerous ways to issue client certificates:
These methods are described in the Admi= nistrator Guide.