Campus CA Requirements

Importance

Item

SubItem

Description

High

Medium

Low

Notes ...

1

CA Operation and Security

a

Use of native OpenSSL with "Engine" support to enable the use of HSMs for CA Private Key Protection

1

a-1

Direct support and documentation for Rainbow iKey and/or Alladin eToken for low-throughput CAs

1

a-2

Direct support for nCipher and/or other high-speed HSMs

1

b

Rational software mechanism for CA private key protection. This is a secure way to protect the CA's private key in the cases where a hardware HSM is not being used.

1

c-1

Ability to sign requests for End Entity certificates (from Browser)

1

c-2

Ability for CA to generate key pair, generate the End Entity certificate, and deliver it in the form of a PKCS-12 file containing the whole chain

1

c-3

Accept request (CSR) via a cut and paste interface and deliver the resulting certificate via a web interface or email

1

d

CA will maintain a database of the certificates that it issues

1

e

Support for certificate revocation (requires database above)

1

f

Support for an OCSP responder (requires database above)

1

g

Registration Authority Interface

g-1

A simple call-out based mechanism where, given the authenticated user, the CA can obtain a Yes/No decision on if to issue the certificate and obtain the official naming information to place into the certificate.

1

g-2

Support for manual RA interface for approval of server certificates

1

g-3

Some server certificate content validation mechanism for automatic issuance

1

i

Ability to email users prior to certificate expiration

1

j

Flexible configuration options for certificate expiration dates. E.g., one year but not over the summer, all on a single day, etc - Implement via Call Out

1

2

User Interface

a

Assumption that this is an on-line CA and that delivered certificates are marked as non-exportable in the user's certificate store when practical

much debate on this topic

b

Direct support for Internet Explorer for certificate request generation, certificate delivery and installation, and root/intermediate certificate installation

1

c

Direct support for FireFox for certificate request generation, certificate delivery and installation, and root/intermediate certificate installation

1

d

Direct support for Netscape for certificate request generation, certificate delivery and installation, and root/intermediate certificate installation

1

e

Direct support for other browsers for certificate request generation, certificate delivery and installation, and root/intermediate certificate installation

1

f

Cut and paste web interface for uploading certificate requests. Can be especially important if web-based interface for server certificates is implemented.

1

g

Ability to email the end user receiving the certificate with instructions, a copy of a click-through agreement, etc - Call Out mechanism suggested

1

h

Web interface installs the appropriate root and intermediate certificates at the same time that the user obtains their personal certificate.

1

i

A final confirmation to the user that all of the certificates have been downloaded and installed.  Consensus: skip if hard

1

j

An intermediate screen that displays certificate naming fields in Subject and SubjectAlt and gives the user the opportunity to abort the signing process before the certificate is issued. Consensus: skip if hard

1

3

Certificate Profile

a-1

By default upon installation, the CA will issue certificates using the PKI-Lite certificate profile for users. Some fields such as Subject, SubjectAlt Name, and Serial Number will vary for each certificate issued. Naming information will come from the validated user's certificate request.

1

a-2

A matching profile for server certificates needs to be developed.

1

b

A mechanism will exist to support private campus extensions for advanced users.

1

4

Logging Information

a

Information about each certificate issued, including the date, subject, email, serial number, and the IP address of the requesting computer.

1

b

Each certificate revoked, including the date, subject, email, and serial number.

1

c

Failed request validations

1

d

Log information will be in a parsable format and sent via syslog to ensure easy remote logging

1

e

Configuration or documentation of key operating system logs that should be retained.

1

f

A copy of every certificate issued will be retained

1

5

Campus Identity Management Interface

a

Assume that the site will preauthenticate the user and deliver the validated user in the Remote User environment variable?

1

b

Assume that the site will provide whatever data is needed to validate the request. A likely interface might be a call-out that the CA can make, providing the user's login name and receiving back the information needed to validate the certificate request. What information in the request should be validated?

1

c

A direct LDAP interface and/or perhaps a set of shell scripts as the example interface

1

6

Installation Process :-)

a

./configure

Discussion: needs to be simple

b

make install

Discussion: needs to be simple

7

Documentation

a

Recommended campus deployment guide

1

b

USHER subordination how-to

1

c

Summary of known-supported applications

1

8

Some software candidates

a

CA software developed by HEPKI schools

b

Our Opensource crypto software list.

9

Some Assumptions

a

The CA system will be implemented for a Linux platform and that we can specify the Linux version.

1

b

The CA will run on dedicated hardware.

1

c

The project implementer can choose an appropriate language and toolkit to use. Anything weird should be discussed with the group first

1