Motivation

Certificates are signed only for institutional servers within columbia.edu using the Columbia CA certificate signed by the CREN CA. (Note that CREN has disbanded, and the CREN CA has been adopted by the Internet 2 community.) In theory, this allows interoperation with other sites signed by the CREN certificate once the certificate has been installed in the browser.

There are several issues with this model.

1. Certificate Distribution
   Since the CREN certificate is not included with any major browser (only Opera includes it, and only recently), almost all users must download and install the certificate. This applies not only to web browsers (including newer browsers such as Safari that do not recognize the automatic method for installing a certificate that we support), but to email clients and PDAs as well.

   This issue becomes more significant as non Columbia people (and more generally, those who do not download a web browser from or otherwise visit the AcIS software pages) use more of our secure services, including alumni services, Epic web site registrants, etc.

2. Staff Signing and Support Requirements
   All certificates must be signed by a member of the Certificate Authority group. While the signing operation is relatively fast (about 3 minutes per transaction), the number of certificate requests increased from 5 per month in 2002 to 11 per month in 2003 for the four month period June through September (for which statistics about both CUCA2 and the previous CUCA are available).

   Some requesters require assistance in properly formatting their certificate signing requests and in installing their signed certificates on their servers. While these are not official responsibilities of the Certificate Authority group, members of the group usually try to assist with these requests. In addition, even for the majority of requests that are straightforward, there is still a requirement for verifying the identity of the requester.

3. Broken Development Environments
   Some development enviroments, especially Java based utilities, do not handle the Columbia/CREN certificates correctly. (Especially for Java libraries, this may be caused by a malformed field in the current CREN signed Columbia CA certifigate.) While this is technically a problem with those environments, this has frustrated the development of WIND based applications by AIS.

Options

1. Continue As Is
   CUCA2 remains, signing certificates with CREN/I2 and enhancing the CUCA software as needed.

2. Continue As Is, With Fee
   Charge a "nuisance fee" to offset the increased work required as the number of certificate signing requests would otherwise increase.

3. Switch To Commercial Certificate With Delegated Signing
   Have the Columbia Certificate signed by a major signer (ie: one included in browsers by default), and continue signing requests locally, charging a fee to offset the cost of the delegated signing certificate. (Or, similarly, obtain a site license/volume discount for issuing multiple certificates signed directly by the commercial authority.)

4. Switch To Commercial Certificate With Switch Back to I2
   As for the previous option, but with the intention of switching back to the I2 certificate once it is incorporated into browsers.

5. Discontinue the Certificate Authority
   AcIS purchases its own certificates and directs all signing requests to external vendors, who also provide support.

6. Switch To Commercial Certificates, Keep the Certificate Authority
   AcIS purchase its own certificates, but continues to run the Certificate Authority for campus signing requests.

Factors For Decision Making

1. Cost
   Switching to a commercial authority requires payment. In a bulk purchase/delegated signing scenario, AcIS would charge other Columbia entities for signing. The only advantage in this would be the per unit certificate cost would be cheaper university wide rather than having each department or organization request certificates directly.

   Rates do not include any education or other discounts.

   • Verisign
     10 128bit/2yr Certificates for $6950
     100 128bit/2yr Certificates for $57000

     With Verisign, one purchase order per year is completed. The PKI administrator (at AcIS) can then sign up to the purchased number of certificates per year through Verisign's web based interface. No local signing infrastructure is required. Certificates are signed for 2 years.

   • Thawte
     1 128bit/2yr certificate for $849

     "ISP Program" is not well described.

   • RSA Keon
     With co-signing/root signing, certificates are still signed locally, but use the "ubiquitously-recognized and trusted" RSA root certificate.

   • GeoTrust (formerly Equifax Secure)
     1 128bit certificate for $229 (renew for $179)
     10 128bit certificates for $1250
     

     Model for bulk purchase appears to be similar to Verisign in that no local PKI infrastructure is required.

   • Baltimore
     1 128bit certificate for $349 ($249 renewal)
     Volume discount available
     "OmniRoot" can work with an in-house CA or outsourced

   A delegated signing method could be expected to cost anywhere in the range of $50,000 to $200,000, although we would need to obtain price quotes, etc, to verify this. Part of this cost would be recovered by charging Columbia affiliates for certificate signing.

2. Fast Response
   On occasions when system administrators fail to notice the expiration of a certificate, rapid turn around is required to avoid user noticeable problems. Rapid turn around is most likely when there is no external dependency on certificate signing.

3. University Environment
   A significant number of organizations within the university community take advantage of the Columbia CA to deploy secure web services without paying fees to commercial entities while granting a greater degree of trust and legitimacy to their services than if they had used a self-signed CA. Given that most of the infrastructure to support this service has already been deployed, the incremental cost in maintaining this service is very low (notwithstanding any necessary outlays due to the possible switch to a commercially signed certificate).

   Another factor here is that different organizations within the university may have different requirements. While AcIS may be willing to spend money to purchase a commercially signed certificate, other departments may not be willing to make such a purchase. Especially with regards to option #6, it may or may not be valid for a certificate that is not "good enough" for AcIS to be good enough for another department.

4. Collaborative Development
   AcIS has historically taken a leading position in collaborative development with our peers. The Columbia CA can be (and to some extent already is) a point of leverage for maintaining this position with regards to PKI and certificate trust hierarchies.

5. Personal PKI
   Personal PKI is a secondary issue with little immediate weight. There are no immediate plans for this service, and in the longer term usability and scalability issues must first be resolved.

Where To Go From Here

1. If the decision has already been made to sign AcIS' highly visible servers with a commercial authority, then options 1 and 2 are no longer relevant.

2. Does AcIS wish to maintain signing services for the campus?
   • No: Option 5 is selected. Choose a CA based on price and browser availability.

3. If the answer to the previous question is yes, then should the same CA that signs the AcIS certificates also sign other campus certificates? AcIS will have to absorb or pass on the added expense.
   • No: Option 6 is selected. Choose a CA based on price and browser availability. Any site signed by the CREN/I2 certificate will still require their visitors to download the signing certificate into their browser (and so AcIS may still need to maintain some support infrastructure).

4. If the answer to the previous question is yes, then Option 3 is selected. A CA for AcIS should be chosen based on the number of expected signings and how such signings are performed.

See Also

• CREN X.509 Certification Authority Policy & Practices
• RFC for Internet X.509 PKI Certificate Policy and Practices Framework