Non-profit, member-based IT support for research & educational institutions


Section Two
Strategic and Practical FAQ -- Using Digital Certificates

2A: Operating and Running a Campus CA: What are Accepted Practices?

Draft 1.1 November 27, 2001

1. When setting up a campus CA, questions of security and policy must be addressed. Does the community have any recommendations in these areas?

Questions related to security and policy are basic to the running of a campus certificate authority (CA). Without good practices verifying holders of digital certificates and protecting access to the CA, certificates issued by a CA might not be worthy of trust.

As for physical security, it is important that the CA is located in a secure location and that access to the system be controlled. If the CA issues certificates using a campus database or repository, then access to that database or repository also needs to be carefully managed and controlled. Existing good campus practices for security of administrative systems is generally appropriate for the database/repository.

As for detailed practices for the security of the CA, the generic policy for higher education being developed by the HE-PKI group contains practices for test CAs through very high security. Specific background and guidance on the protection of the private key of a campus CA is included in another section of this guide.

2. I understand that there is more than one level of trust, or assurance behind digital certificates? How many levels are there?

Many policy and security documents discuss levels of assurance, or LOAs. There are five levels of assurance detailed in current PKI work. The five levels are respectfully: test, rudimentary, basic, medium, and high.

3. What distinguishes one level of assurance (LOA) from another?

One of the major areas of distinction has to do with the rigor with which the Registration Authority (RA) validates a person or an organization to be eligible for a certificate. For example, the rudimentary level of assurance may not require an in-person identification requirement. Rather, an applicant might apply and receive a digital certificate by providing personally identifying information that only the RA and the Subject should know. Campus policy for this rudimentary level of assurance can vary within a range of requirements and still be consistent with basic reasonable good practices.

For the High level of assurance there is usually more rigor required for proof of identity. Identity may have to be established by in-person appearance before a Registration Authority for the CA or before a Trusted Agent for that CA. Credentials might include a picture ID issued by the federal government or state government in addition to this in-person appearance.

Another area of distinction between LOAs has to do with the division of duties for managing and operating the CA. More people are required for higher levels of assurance certificates.

There are many other areas of distinction between the levels of assurances. More about these levels of assurance is easily available by reviewing the generic higher education policy template created by David Wasley and others in the HE-PKI group. This document is still undergoing review, but will be available at the HEPKI sites, and linked to from the CREN CA site.

4. What is the PKI- Lite Initiative?

The PKI-Lite initiative is a HE-PKI community initiative that has developed a campus policy and digital certificate profiles for pilot projects using digital certificates. The digital certificates issued under PKI- Lite policies and profiles can be used for campus applications of signed email and web authentication and/or authorization.

5. Is the policy for PKI- Lite pilots and deployment ready?

Yes, the policy for PKI-Lite pilots and deployment is ready and available on the web at http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-policy-current.doc. The policy — X.509 Certification Authority Policy Higher Education PKI-Lite — as of 11/20/01 is also printed in this guidebook.

This policy encourages campuses to build on existing campus practices and policies for the launching of their digital certificate pilot. For example, most campuses already have policies and practices in place for issuing picture IDs of for setting up email and computer accounts. The PKI- Lite policy supports the strategy of campuses building on these practices. The policy t is brief – at less than two pages long.

6. Is there a recommended generic profile for the campus CA for PKI-Lite available?

Yes, the HEPKI ­TAG group developed a generic profile for campus Certificate Authorities for PKI-Lite projects. The profile dated March 27, 2002 is printed in this guide later in this section or available at: http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-root-profile-current.html

Also of interest are the assumptions underlying the use of the PKI-Lite certificates, which are roughly equivalent to the rudimentary level of assurance. This set of assumptions is available at http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-assumptions.html

Note: HEPKI-TAG has also developed an End Entity Certificate profile for Certificate Authorities to use when issuing End Entity Certificates. It is located at http://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-profile-current.html.

7. I have heard about CPs and CPSs. What are these?

CP is the abbreviation for Certificate Policy; CPS refers to a Certification Practice Statement. Certificate Policies and Certification Practice Statements are of interest to vendors and organizations who will be making use of digital certificates for access to resources and for web authentication. Organizations that make use of digital certificates are called "Relying Parties."

A Certificate Policy sets forth the requirements and standards for operating a CA so that relying parties can determine if there is “sufficient trust" for them to accept digital certificates issued by that CA. For example, relying parties will be able to refer to the PKI-Lite campus policy to determine if that campus policy provides strong enough assurance as to who will be requesting access to providers using digital certificates issued by that campus CA.

A Certification Practice Statement states how a CA implements procedures and controls to meet the requirements stated in the CP. In summary, a CP states requirements; a CPS states how a particular CA meets those requirements.

The full and complete scoop on CPs and CPSs is detailed in RFC 2527, updated on July 12, 2001. This document -- Certificate Policy and Certification Practices Framework for the Internet X.509 Public Key Infrastructure is at < draft-ietf-pkix-ipki-new-rfc2527-00.txt >

Note: RFC 2527 is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups.

Top

Please send comments/suggestions to cren@cren.net


Strategic and Practical FAQ -- Using Digital Certificates

2B: X.509 Certification Authority Policy Higher Education PKI-Lite

HE-PKI-LITE Policy – Original draft by James Jokl
Draft 3, November 20, 2001

Introduction

Discussions within the Higher Education PKI community and with others working in the field suggest that one of the reasons for the slow rate of deployment of PKI is the relatively high overhead associated with building a Certification Authority (CA). While the technical aspects of a full-featured PKI may be complex, they are usually dwarfed by some of the policy and operational constraints often imposed on a PKI designed to support high assurance financial and legal transactions. PKI-Lite focuses on employing PKI technology for standard assurance applications that already have known and implemented policies for initial user authentication and overall system security. For example, a use for PKI-Lite may be to improve the security of a password-based application by using PKI for authentication instead of passwords. The application’s existing process for system security would be used and its practice for identifying the user before creating their password would be replicated in the PKI environment. PKI-Lite can also enable standard assurance implementations of newer services such as S/MIME enhanced email. HE-PKI-Lite is the deployment of PKI technology using existing standard campus mechanisms for identifying users and securing systems.

Requirements

Institutions issuing HE-PKI-Lite X.509 certificates agree that they will make reasonable efforts to adhere to this policy but assume no liability for policy violations, either accidental or deliberate. Parties relying on certificates issued by a HE-PKI-Lite CA should study this policy and the CA’s Practices Statement to determine if the assurance level and operational practices are sufficient for the needs of their application.

1) User Identity

HE-PKI-Lite certification authorities agree to use existing campus practice for identifying the user before issuing the certificate.

  1. People identified in HE-PKI-Lite certificates are authenticated using standard university practices for identifying people for other applications such as issuing userids and passwords for on-campus systems.
  2. Subject names must uniquely map to the individual for the validity period of the certificate. Furthermore, it is strongly recommended that subject names uniquely map to the individual in perpetuity regardless of the certificate’s validity period.

2) Certificate Revocation

HE-PKI-Lite certification authorities are not required to be able to revoke certificates. However, if a CA issues certificates containing a Certificate Revocation List (CRL) distribution point extension, then the CA is obligated to issue CRLs and must update the CRLs as specified in the Next Update field of the CRL.

3) Private Key Protection

Operators of HE-PKI-Lite certification authorities must understand the significance of the CA’s private key(s) and take action to protect the key(s) appropriately. On-line CAs are specifically permitted in the PKI-Lite framework to help make user certificates easy to obtain. The operator of the CA is expected to take reasonable precautions to protect the private key(s) and must publish an outline of these measures in their CPS.

4) Certificate Profile

HE-PKI-Lite certification authorities must issue certificates that follow the HE-PKI-Lite Certificate Profile.

5) Certification Practice Statement (CPS) Operators of HE-PKI-Lite certification authorities must either edit the HE-PKI-Lite CPS Template as needed or develop their own CPS and publish their practices statement. A URI pointing to this statement must be included in the certificate’s CPS pointer extension. In the spirit of PKI-Lite, the CPS should be a brief document that conveys sufficient information such that a PKI-knowledgeable person at another institution of higher education could use the document to understand if they can rely on the CA to meet the needs of their application.

Top

Please send comments/suggestions to hepki-tag@internet2.edu, James A. Jokl (jaj@virginia.edu) or cren@cren.net


CREN Strategic and Practical FAQ – Setting Up a CA

2C: How much does a CA cost to set up and to run?

Draft 1.2, November 27, 2001

1. What is the approximate budget recommendation for setting up and operating a campus CA service?

As with most technology purchases, there is a wide range in the amount of money you can spend on setting up and operating a CA. Budgeting for a CA is similar to budgeting for a car. First you determine your needs and your budget; then you shop for the best car you can get within that requirement and budget range.

Setting up and operating a CA service has similar budget ranges. As described in an earlier section, a campus CA requires hardware, software, and personnel. It is possible that you can re-assign one or two machines to be dedicated to the campus CA. If not, you will want to budget for one, but preferably two machines for your campus CA. Sun Solaris, Linux, Windows 2000 or NT 4.0 machines can be used.

Another budget item is the certificate authority software that actually makes the CA and RA operational. Certificate Authority software is available from vendors, such as RSA, iPlanet, Entrust. It is also available with the purchase of a Hardware Security Module from vendors such as Chrysalis-ITS Luna, nCipher, and IBM. Open source certificate authority software is also available, such as Open CA and the software from Jeff Schiller. However support for the open source software is minimal.

The pricing models for the certificate authority software needs to be further analyzed. Some vendors charge for the certificate authority software plus a charge for the users or certificates that are issued and/or managed by the certificate authority. As users might have more than one certificate, pricing models based on the number of people to whom certificates will be issued tend to be more manageable.

The chart with vendor specifications has more detail on the pricing structure of the various CA software vendors. One of the goals of the pilot will be to share information about which of the CA packages fits particular campus models.

As for personnel, they are needed. A minimum of a portion of two people is required. A team of one responsible executive, two staff plus a student would be a good team.

2. What is the cost range of the software?

The current sticker price of the certificate authority software can range from "free" to about $40,000+. The systems at the higher range of this price are bundled systems, including the recommended hardware security modules along with all the CA software including the registration modules. There has been some price movement of late, with some hardware security modules being available at less than $5000.

If your budget is very restricted and you have access to programming staff, the Open Source CA might be an option. In this case, the software would be free but the staff resources would need to be increased. Another cost factor for the software is the choice of whether or not to purchase additional consulting.

3. What cost models are vendors using for digital certificates?

There are three cost models available for certificate issuance. The CAs available in the Open Source community and therefore the use of them is free. Any number of certificates may be issued; however, the updates to the software will have to be made by the institution’s staff or someone in the Open Source community.

The next most common cost model is to pay once yearly per certificate issued. Usually this is based upon the number of entries in the institution’s directory from which a certificate has been issued. A third model that is emerging is the model of the managed certificate that has a one-time payment associated with it.

3. What can I expect to pay for installation if somebody else installs the CA?

Some CA vendors such as Entrust will charge a lump sum, which includes the software, the installation, the certificates and the support for one year. Other vendors, such as iPlanet, provide specialized support through consulting services.

4. What human resources will be needed for the setting up of the CA?

The setup time involved will vary depending on your operating system and your selected CA software. It can take as little as 2 days for a consultant who is experienced in standing up a CA to three weeks for staff new to this area, if patches for upgrades, etc. need to be located.

5. What human resources will be needed for the ongoing operation of the CA?

For the most part, daily operations include maintaining a secure environment for the CA and checking the log files. If you do not have a managed directory on campus before you set up your CA, then initial setup time will be a bit more extensive. You can choose to keep the database fairly simple at the beginning and build your people directory/database out more thoroughly at a later time.

Top

Please send comments/suggestions to cren@cren.net

Higher Education PKI-Lite
Certification Authority Certificate Profile


Document: hepki-tag-pkilite-root-profile-4.html
Editor: James Jokl
Date: March 27, 2002
Comments to: hepki-tag@internet2.edu

Reference: Implementors should reference RFC-2459 for additional details.


 

This profile is intended for use both for self-signed root institutional certificates and for intermediate CA certificates for cases where the campus CA is part of a hierarchy such as CREN.

HE-PKI-Lite CA Certificate Profile Summary Table
Field Name Value Example Specified Explanation
Version
0x2
0x2
Y
Version 3 certificates are specified by the PKI-lite profile
Serial Number
a unique integer
334
Y
An integer that is unique to all certificates signed by the CA that signed this certificate.
Signature Algorithm
 SHA1/RSA
 
N
We recommend the use of SHA1/RSA. You are likely to experience interoperability problems if you choose DSA.
Issuer
DN
Either (a) the same as the Subject name if this is self-signed, or (b) the Subject name in the signing CA's authority cert.
Y
HEPKI-TAG recommends that you keep this field simple to avoid problems with some software. If this certificate is a self-signed root certificate, this field will be identical to your Subject field. If this certificate is an intermediate certificate, this field will be specified by the signing CA. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional. Notes for PKI implementors
Validity
Time
The validity period must be greater than the period of any certificates signed by this certificate or below this certificate in the chain.
Y
Notes for PKI implementors
Subject
DN
cn=your pki's name, E=pkimaster@youruniversity.edu, o=YourUniversity, c=US, dc=youruniversity, dc=edu
Y
If this is a self-signed root certificate, this field must be identical to to the Issuer field. If this is a campus intermediate certificate, we recommend that you keep this field as simple as possible. The use of domain component naming as per the HEPKI-TAG dc naming recommendation is optional.
Public Key
 
 
N
Recommend a minimim of a 2048 bit key
Certificate Extensions
Key Usage
  Certificate Signing , Off-line CRL Signing , CRL Signing(06)
N
While not specified, we recommend the use of the specified attributes and that this extension be marked critical.
Basic Constraints
CA=true
Subject Type = CA
Y
We recommend that you omit the Path Length attribute and mark this extension critical.
CRL Distribution Points    
N
If the certificate specifies a CRL location, the CA must produce CRLs. Furthermore, the CA must update the CRL as promised in the CRL's next issue field. Notes for PKI implementors
Certificate Policy
HE PKI-Lite Policy OID
 
N We recommend that you omit the HEPKI PKI-Lite policy OID. If you are willing to take some risk about how future applications may interpret this field you may choose to include the HE PKI-Lite policy OID.
Subject Alt Name E= email:pkimaster@youruniversity.edu
Y
The Email identifier should be in both the Subject and SubjectAlt name fields.
CPS Pointer URI Pointer to CA's Certification Practices Statement
Y
The publication of a Certification Practices Statement is required by the HE PKI-Lite Policy.
Other fields     ? CAs may include other elements in certificated as needed. HEPKI-TAG recommends that certificates be kept as simple as possible to maximize interoperability.


CA Certificate Profile Summary Table Legend

  • We recommend that no certificate extensions be marked critical.
  • Specified column
    YThe profile specifies the use of this field as documented.
    NThe profile does not specify the usage but may recommend a way to use the field.
    ?Still undecided.
      italics  Example of an optional element.




HE PKI-Lite Certificate Profile Implementor Notes

Top

Please send comments/suggestions to hepki-tag@internet2.edu


CREN Strategic and Practical FAQ – Certificate Authorities

Protecting a Private Key in a CA Context

Draft by: Jeff Schiller, MIT, 10/15/00

Introduction

1. As we build Public Key Infrastructure (PKI) one of the critical issues that comes up is how an institutions’ private key is protected. This document attempts to go over the issues and technologies available to an institution.

1.1. Protection schemes can be broken into two basic classes.

A) Schemes where no human ever has access to the raw private key.

B) Schemes where a human may have access to the raw private key.

Schemes where no human ever has the key are obviously stronger from a security perspective. You don't have to depend on and trust any one person. Put another way, schemes where a person does have access to the key requires that that person be extremely trusted. They will be in a position to abuse their trust by creating any number of bogus certificates. If a root key is so abused, recovery may be difficult as it may require the re-issuance of all certificates within the institution. Furthermore it may be difficult to determine whether or not abuse has occurred, particularly if only a few bogus certificates are ever created (presumably for a focused illegitimate purpose).

Even in schemes where no human has access to the key, trust is still a factor because some set of people will ultimately (either singly, or jointly via dual-control technologies) be able to make

use of the key to issue certificates, legitimate or otherwise. However audit controls are easier to provide in systems where no human has the key directly, so it is easier to detect illegitimate activity.

1.2. Another way to divide.

Just as it is critically important to trust the humans involved in the control of the private key, it is also important to understand the physical and logical protections that are used to protect the key from illegitimate use by others, aka being stolen.

Solutions can be viewed on a spectrum based on how well they protect the private key. At the bottom of the spectrum is storing the key in a file on a network-connected computer. This exposes the key to the risk of being compromised by anyone who can login to the system, legitimate or otherwise. Given the sorry state of computer system security, particularly for network connected computers, it is highly likely that a key stored in this fashion will be compromised.

At the other extreme are systems that store the private key in a hardware device which itself requires a hardware token to operate. In this type of system compromise requires that the device itself be stolen and the necessary tokens to activate it must also be acquired.

Another thing to consider is that some systems will only need access to the private key when an authorized operator is explicitly making use of the private key (aka signing a certificate). However other systems may be on-line, being available to sign certificates without human intervention.

1.3 Key Recovery

Any system that stores private keys can fail. This is particularly true to hardware systems. Yet it must be possible to prevent the loss of the private key under failure circumstances.

Therefore some form of key recovery is necessary in order to deal with failure.

Key Recovery schemes used in systems where no human should ever have access to the private key must maintain this property.

2. A survey of possible strategies

2.1 Systems where humans can have access to the key

There are many approaches that can be used to protect a private key where authorized users may have access to the key, but unauthorized users are prohibited from having access.

2.1.2 Storing the key in a file

Perhaps the simplest approach is storing the private key in a disk file on the CA computer system. With this type of system the computer must be maintained in a secure fashion and the backups must also be protected as they will contain a copy of the private key.

***This is the least recommended solution***

Given the state of modern computer systems security, this method is likely not appropriate for sensitive CAs unless the computer is never connected to a network. A variant of this type of solution is to use two computers connected via a serial cable. This is discussed in section [FORWARD REFERENCE]

2.1.3 Storing the key encrypted in a file

A variant of (2.1.2) this approach has the file encrypted using a key known only to authorized parties. Typically this key is the result of a one-way hash function applied over a hopefully strong password (12 characters, mixed alpha and numeric characters perhaps with punctuation added as well).

Provided the password is sufficiently strong, this method may be a reasonable way to operate an off-line CA where the operator only enters the password, and it is in memory only for a short period of time, to manually sign a certificate.

On-line systems can make use of this strategy but care must be taken in the technical implementation of the on-line components so as to make unauthorized key extraction from a running system difficult.

When implemented correctly this approach should protect the private key even in circumstances where the CA system is compromised by the typical internet cracker.

This approach is not sufficient to protect against a knowledgeable "high level" attacker who is familiar with the CA software and is explicitly looking to steal the private key.

2.2 Hardware Approaches

The basic scheme with hardware based approaches is to have the private key reside on a hardware device which is then used to make digital signatures using the private key. The key never leaves the device. At the low end, the hardware device may be a smart card processor. At the high end a dedicated hardware CA component may be involved.

Hardware solutions may have the properties:

1) Humans have access to the key

In this case the hardware token has the key downloaded to it. A human may have access to the key prior to and after it is downloaded. However the file where the key is stored can be kept off-line and locked up while the hardware token is used for actual certificate signing. The primary advantage to this approach is that failure of the hardware token can be dealt with by downloading the key to a replacement device.

The primary downside of this approach is that the key is still stored outside the device and available to rogue CA administrators.

2) Human has access during initialization

This is a scheme similar to [1] above. However after the key is downloaded into the hardware token, all outside knowledge of it is destroyed.

This scheme assumes that the human involved in the key creation operation is honest at the time of key download and does in fact destroy the created key after download. This is a stronger approach then [1] but is not perfect.

An important consideration with this approach is that hardware failure may result in the loss of the key. One way of mitigating this concern is to download the key to multiple devices with at least some number of devices stored at a disaster recovery facility or similar "off-site" storage location.

3) No Human ever has access to the key

In this approach the key is generated by the hardware device and never leaves it. As such no human ever can come in direct contact with the key. This is a very secure approach from a personnel management point of view. However care must be taken to deal with what happens when the hardware device fails.

The BBN SafeKeyper(tm) is a well thought out example of such a system, complete with facilities to recover the key from a failed unit. The SafeKeyper is described in more detail in another section [FORWARD REFERENCE]

2.3 Hybrid Approaches

One interesting hybrid approach suggested by Ken Klingenstein involves the use of a laptop computer as a virtual hardware token. In this approach a laptop computer is programmed to behave like a smart card, accepting signing requests via a serial connection from a different computer, which may or may not be connected to a network. The laptop itself is never connected directly to a network and its only connection to the outside world besides its keyboard and display is via the serial port.

In this approach some human may have access to the raw private key, the person who has possession of the laptop to wit.

The key itself is stored on the laptop (as in 2.1.2) but is protected by the laptop's software environment. Additional protection can be afforded by encrypting the key on the laptop with a password (as in 2.1.3) to further improve security.

This may be a suitable approach for an on-line CA where we have to assume that the on-line system is subject to compromise.

2.4 The BBN SafeKeyper(tm)
[TBW]

Top

Please send comments/suggestions to cren@cren.net