Introduction

Applications do not automatically know how to recognize digital certificates. Application systems need to be modified or developed to prepare applications for recognizing and using digital certificates.

Note: This is an area that is just under development, and will be developed in collaboration with the content providers during the course of the pilot.

1. Is any content provider now ready to accept and use digital certificates?

Yes, JSTOR is ready to accept and use digital certificates. More information on how JSTOR prepared their systems is detailed in another section of this guidebook.

In brief, the web log-in server runs a program that examines key fields in the certificate that is presented to the server. The server examines the signers of the certificates and the expiration dates. The issuer field of the certificate needs to match a signer, such as the University of Minnesota CA in the JSTOR database. For access to JSTOR to work, the certificate must also be valid. This means a certificate that has not expired and that contains a valid chain, i.e. that the chain tracks back to a recognized root, such as CREN.

2. Are there any applications that are "PKI-enabled" out of the box?

Just as there are multiple ways of assessing authenticity and authorization, there are multiple ways of PKI-enabling applications. Some institutions have PKI-enabled many of their campus applications. More on how they have done this will be developed in future versions.

One way of PKI-enabling an application is to write rules for the Apache web server "mod_ssl" package to recognize a "hard-wired" set of certificates by some rule, such as matching the Issuer field. This is essentially equivalent to using the "htaccess" file to restrict access by IP address. It works fine for a small number of distinct sites for simple binary access decisions, either full access or no access. It does not work well when there are a large number of sites, or when different sites must be granted different levels of access.

3. Are there applications or tools to assist in PKI-enabling applications?

Yes. Applications and tools for PKI-enabling applications are beginning to emerge. One vendor currently in this space is Conclusive. Conclusive software supports the use of digital certificates by providing software for relying parties, such as content providers and organizations with web applications, to write rules for users to access their resources. Using a GUI, very granular or very broad rules can be set for access and the software then writes the Java code in the background to implement the specified rules. The Conclusive server sits in front of web applications and acts as a front door to the web users coming to transact interactions with the site.

4. What if a content provider wants to leverage the work from JSTOR? Is that code available?

Yes, this code is available from JSTOR. It is JAVA code that accepts the certificate and extracts information from it.

5. Once a content provider is ready to process certificates, does a campus need to do anything to facilitate recognition of certificates coming from their campus?

Yes. If an application is enabled using the CREN-signed institutional certificate, the campus will need to send to JSTOR the certificate(s) that they will be using to sign end-user certificates for authorized JSTOR user classes. For example, if the campus used the CREN-signed root to sign three certificates that were then used to sign certificates for, respectively, students, faculty/staff, and alumni; the campus should send to JSTOR the public key portion of the certificates used to sign student certificates and faculty/staff certificates. The campus should NOT send the certificates they use to sign alumni certificates as the alumni will not be authorized for JSTOR access.

6. What about the contracts that content providers have with campus institutions? Can existing contracts be used? Or are amendments and modifications recommended?

This is an area for discussion between the content providers and the campuses.

Some contract variables that may want to be evaluated are questions of campus policies as to whom the campus will be issuing campus client certificates? Questions such as these will usually be included in existing campus policies or in explicit certificate practices statements (CPS)

Content providers may want campuses to certify that they will only be issuing certificates to current faculty, staff, and students. Content providers may also want campuses to certify that they will be issuing end-user digital certificates with a reasonably short expiration period, such as, the end of the academic year.

7. How rigorous might content providers want this assurance to be?

Content providers may be willing to accept what is becoming known as the 95/5 provision, stating that campuses can reasonably assure that 95% of the campus certificates are issued to current faculty, staff and students, and that no more than 5% of the campus certificates would be issued to campus affiliates, such as visiting professors, students, or vendor contacts.

8. What about campus policies regarding the process for issuing campus client certificates?

To launch increased security of campus computer communications, the HEPKI groups have approved a PKI-Lite initiative. This initiative has resulted in the draft of a certificate policy that sets forth the context for a rudimentary level of assurance for campus client certificates. This draft policy is in another section of this guidebook.

Note: The federal government has a system of five levels of assurance in place —test, rudimentary, basic, medium and high. The rudimentary level provides more security and assurance than the ubiquitous name and password, but requires less rigor in policy and deployment than the basic medium, or high levels of assurance. It is anticipated that a gradual increase in security is a good way to get started with this technology, as it will lay the basis for a significant increase as the technology is deployed and understood.

9. How much time does it take to PKI-enable an application?

Develop at Meeting/during the pilot

10. Do content providers need to acquire any special software to PKI-enable their applications?

Develop at Meeting/during the pilot

11. Why should content providers accept digital certificates?

Develop at Meeting/during the pilot

12. Is there a sample contract amendment template that content providers can use as a model?

Develop at Meeting/during the pilot

13. Other questions?

Develop at Meeting/during the pilot

Introduction

JSTOR, a provider of digital journals is now ready to use CREN-signed institutional digital certificates for user authorization from participating institutions.

1. Why should a user access JSTOR using CREN-Institutional Certificates?

A user with a CREN-signed institutional certificate as part of their digital certificate can access JSTOR from anywhere at anytime. These users do not have to be on campus where the incoming IP address is used for authentication nor do they need to access a campus proxy server to make it appear as if they are on campus. This service increases access for users.

2. How does JSTOR process incoming user digital certificates?

JSTOR has prepared its server to recognize and process incoming digital certificates. In processing digital certificates, the web server examines the signers of the certificates and the expiration dates of the digital certificates. The issuer field of the certificate needs to match a signer, such as the University of Minnesota CA in the JSTOR database. For access to JSTOR to work, the certificate must also be valid. This means a certificate that has not expired and that contains a valid chain, i.e. that the chain tracks back to a recognized root, such as CREN.

3. What does a campus need to do to obtain a CREN-signed institutional certificate?

The detailed steps for obtaining a CREN-signed institutional certificate are at the CREN site at (please fill this in) In brief the process is as follows:

• Apply for the CREN Certificate Authority Institutional Certificate at https://www.cren.net/crenca/dcservices/icert/index.html#application.
• Complete and sign the application form.
• Set up a secure communications channel for sending a certificate signing request.
• Receive the certificate and install it in your campus Certificate authority software. package.

4. What does a campus need to do to arrange for JSTOR to recognize the -signed institutional certificate from their campus?

The campus technical contact needs to contact Spencer Thomas at JSTOR (spencer@umich.edu) requesting that JSTOR set up your institution for access to JSTOR using digital certificates. Here are the steps in the process:

• Use the CREN-signed institutional certificate to create the campus certificate that will be used to sign digital certificates issued to members of the campus community.
• Send Spencer a copy of the CREN-signed campus institutional certificate and a copy of the public key portion of this certificate.
• Confirm to JSTOR (www.jstor.org) that end-user certificates signed with the campus certificate will only be issued to the students, faculty and staff at an institution consistent with the existing JSTOR contract.
• Certify that you will be issuing end-user digital certificates with a reasonably short expiration period, such as, the end of the academic year.
• Begin using JSTOR with digital certificates at the following URL: https://www.jstor.org/logon .

5. What about the need to have the CREN root certificate in client browser? Do users need to download the CREN root to access log in servers of content providers?

No. In this type of application, the server at the content provider’s site is the server that navigate the trust path from the client to the institution to CREN. Thus the content provider must have the CREN root, but the users do not need the root in their browsers. See Section Six for more on roots and browsers.