1 Introduction
1.1 Why the Difficulty?
1.2 Why the Complexity?
1.3 Understand Your Application's Requirements
1.4 Certificates Are Different...
1.5 Goals for This Document
1.6 What is PKI-Lite?
1.7 Acknowledgements
2 Planning Considerations
2.1 Create a Certificate Policy (CP)
2.2 Create a Certification Practices Statement (CPS)
2.3 Certificate Contents (profile)
2.4 Choosing a Trusted Root
2.5 In-sourcing vs Out-Sourcing the Certificate Authority
2.6 Implementing I & A appropriate to the required level of assurance
2.7 Certificate Revocation Requirements
2.8 Separate Signing and Encryption Keys?
2.9 Key Escrow Requirements
2.10 Audit Requirements
2.11 Certificate Repository
2.12 Be Aware of Browser Related Issues
2.13 Standard Operational and Support Concerns
3 Creating and Operating the PKI Infrastructure
3.1 Generating Keys for the CA, and Protecting Those Keys
3.2 Procedural Controls for the CA
3.3 Physical Security
3.4 Disaster Recovery
3.5 Revocation Request Process
3.6 Certificate Life Cycle Maintenance (User Certificates)
3.6.1 Obtaining a Certificate
3.6.1.1 The Registration Authority (RA) Process (I & A)
3.6.1.2 Key Creation
3.6.1.3 Certificate Creation
3.6.2 Getting a New Certificate (when the validity period expires)
3.6.3 Revocation
3.6.4 Key escrow
3.7 Server certificates (SSL and TLS)
4 References
Asymmetric encryption (using public and private keys) was first publicly described in the late 1970's. It was immediately clear that it had many desirable traits. Today, twenty-five years later, very few campuses have succeeded in deploying the Public Key Infrastructure (PKI) needed to use this technology. The answer to why is a long and winding road, that leads deeper into a rathole.
Like other new and dazzling technology ideas, asymmetric encryption was quickly loaded down with many interesting but grandiose scenarios. People set about building the technology infrastructure needed to address these scenarios, and ended up with the complex PKI infrastructure that has (seemingly) defied all efforts at successful deploy. Somewhere during this journey, people lost sight of the simpler, more mundane scenarios and requirements -- scenarios that corresponded to today's world, and problems that were actually solvable.
As expected, for several reasons. Each user has two keys (essentially, very long random bit strings, but with a specific but peculiar mathematical relationship). One is the private key; the user protects this just as they would a password or safe deposit box key. The other is the public key; the user should make this easily and widely available. The public key is usually contained in a Certificate -- which is digitally signed by a trusted third party. The certificate is usually considered to bind names to keys or keys to names. The third party is asserting that the person named in the certificate owns and uses the private key that corresponds to the public key contained in the certificate. Such an assertion can potentially carry liability, if it is wrong. In addition, protocols exist that allow the private key and corresponding certificate to be used to prove a person's identity to organizations outside the campus -- as long as those organizations trust the third party that signed the certificate. Today, campuses issue userids and passwords; but, these are only usable with campus-based systems. If a campus issued certificates, they might be usable to authenticate to systems not managed by the campus.
The original PKI scenarios imagined these new credentials being used to initiate legal and financial transactions requiring an extremely high Level of Assurance (LoA) about the identity of the person initiating the transaction. That required building a PKI infrastructure that was complex and costly to operate. Fortunately, when a campus issues a certificate, it can constrain the ways that the certificate can be used. PKI-Lite uses these mechanisms to constrain usage to applications that can accept a much lower level of assurance. This level, while lower than originally imagined for PKI, in fact corresponds to what we see today on many campuses. This places a burden on the campus, though, to know how the certificates are being used, and to understand the requirements of each of those applications.
Even though PKI would be operating at the same Level of Assurance (or level of risk and exposure) as current security systems, its implementation is different from those systems. Consequently, there is a need to define new policy. Because PKI credentials may be usable by institutions other than the issuing institution, we need to address what contract, implied or otherwise, is being entered into between the PKI credential issuer and a Relying Party. Many of the issues addressed by this contract should be understood and documented for other security systems. In general, however, this aspect of security has been ignored. In addition, we may need to address how we have to change policies to make use of the new features of PKI credentials.
One note of caution -- groups such as the Federal Government are moving toward "accepting", for a wide variety of purposes, PKI credentials issued by campuses. For this to work, though, a campus must issue certificates that are compatible with the requirements of these other parties. Consequently, campuses may NOT have carte blanche when deciding how to constrain the use of their certificates.
All certificates are NOT created equal. The ways that a certificate can be used are specified in some of the fields contained in the certificate, as is the OID for the policy under which the certificate was issued. It is theoretically possible for an institution to issue certificates that may create a legal liability for the institution. Consequently, it is very important, when an institution is considering issuing certificates, to review and understand the requirements of the applications and situations where the certificates will be used.
This topic will be covered in more detail in later sections of this document. This section will merely describe some example applications, to give some sense of the spectrum of possibilities.
One popular use of certificates is with VPN software. The cert is used to create the encrypted tunnel. It can be used for user authentication, but does not have to be (many sites rely on traditional userid/password combinations for authentication). Because the cert is only used to create the encrypted environment, there is NO need to provide users with identity certificates. In this case, "junk certificates" are acceptable -- they are issued by a CA recognized by the VPN concentrator, but they cannot be used to prove identity. These are low-risk certificates.
Another popular use of certificates is server certificates used by web servers to create SSL/TLS tunnels. These certificates are issued to machines (not to people), and are used by the web server on the machine to prove its identity. Some proof of legitimacy is usually required before a CA will issue one of these certificates. For instance, a company should have to prove that it is Microsoft before a commercial CA would issue it a certificate whose subject field contained the name Microsoft. Likewise, a campus CA should verify the origin of a request for a server cert for geology.example.edu before issuing it (it should not be given to a student, for instance, for use on a dormitory based machine).
Adam -- certificates for W2K servers
Certificates can be used to support user authentication. This is easiest to implement when the application is web based, since web browsers and servers commonly support this method of authentication.
Another popular use of certificates is with secure email -- often called S/MIME. These certificates are used to sign email -- which is usually interpreted to mean proving one's identity. A cert containing the name Jane Doe should ONLY be issued to her. Stated another way, Jane must conclusively prove her identity before she is given a cert. The phrase Level of Assurance is often used to refer to the strength of the proofs that Jane provided of her identity before she was given a cert.
Lastly, Campus X requires the use of certificates when people authenticate to the campus financial system and authorize transfers exceeding $10K. These certificates are very similar to the identity certificates used for S/MIME, but may contain a much higher Level of Assurance, because of the liability associated with the actions they enable.
The same CA software can issue all of the different kinds of certificates described above -- what is different from one to the next is the contents of the Policy and KeyUsage fields in the cert. A site has to understand how the cert will be used before telling the CA what to put into those fields.
Although certificates can be used in some of the same ways as current userid/password style credentials, their flexibility can create problems for organizations. When an IT department issues credentials that are primarily for use by the institution itself, the credential is not generally viewed as representing a legal contract with potential liability for the institution. In fact if the institution's counsel believed that the act of issuing credentials might result in liability for the institution, there are likely cases where the counsel would recommend against the deployment of a PKI. Password credentials don't normally have any perceived liability associated with them.
Making the issuance of PKI credentials a "risky" operation means that either an institution will avoid PKI solutions, or will install policies and procedures that significantly increase the cost of the credential management business. Yet many institutions are not in a position to significantly increase the cost of operating their authentication infrastructure (if they even think of it in those terms!).
To address this we need a policy that "fits" higher education. We need a solution which can be deployed within the context of an existing IT management organization (aka, no increase in staffing) and which does not bring undue liability upon the institution.
To that end, this document is part of a set of recipes describing the issues when operating CAs at three different Levels of Assurance:
This document is NOT
This document strives to
Over the last few years, the Internet2 and EduCause sponsored HEPKI groups ( http://www.educause.edu/hepki/ ) have worked to define a framework they call PKI-Lite. 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 requirements for initial user authentication and overall system security. The result is a framework that is (roughly) comparable in complexity to other enterprise wide security systems, and deployable without significant new staff positions.
As the name implies, this Policy is "lighter-weight" than the more traditional CPs. Just place the Higher Education Certificate Policy [HECP] on a scale, and you'll immediately get a sense of the size of the effort that lies before you. IETF Certificate Policy and Certification Practices Framework is even more "weighty". The HECP is 80 pages long; The PKI-Lite CP is 3 pages. Clearly, there are many topics covered in the HECP that PKI-Lite does NOT identify or address.
However, PKI-Lite may not be appropriate for certain campus situations. A campus' use of PKI in its interactions with other organizations, or deployment of applications requiring a higher LoA, will likely determine whether a campus needs a "stronger" policy than PKI-Lite. A higher Level of Assurance will in turn affect many of the processes the campus uses in the operation of its Registration Authority and Certificate Authority.
For instance, if the Presidents of two schools plan to use signed and encrypted email, they can probably find a way to securely exchange their certificates. However, if the campus Research Administration Office plans to begin using electronic proposal submittal to NIH, then the Higher Ed Bridge Certificate Authority will probably have to 1) recognize the OID for the CP that the campus CA is operating under (and this may have to be HECP), and 2) see an Assurance Level of at least BASIC, before NIH will accept the submittal. If a campus has to support this application, then they may not be able to use PKI-Lite. It is critical to identify, at the outset, the likely set of applications, and to build the appropriate processes. Of course, it is possible to construct a second CA two years after building the first.
If the campus plans to take a measured and thoughtful approach to deploying a PKI infrastructure, perhaps deploying to groups and applications only on an as-needed basis, then the campus might be able to operate their CA under the PKI-Lite CP. HEBCA would likely map this to an LoA of RUDIMENTARY, but if there are no plans to use applications that rely on HEBCA, this may not be a problem.
What are the operational and process implications of choosing an LoA of BASIC, rather than RUDIMENTARY? This is described in detail in the Higher Education Certificate Policy [HECP].
This document is NOT an original piece of work. Rather, it merely assembles into one place much of the work done over the last several years by the the Internet2/Educause HEPKI-TAG group. This includes the work on both HECP and PKI-Lite. Any campus attempting to deploy a PKI Infrastructure owes that group an immense debt of gratitude.
In addition, in a number of places, text has been directly copied from campus web sites. The University of Virgina was been a particularly "generous" donor. Bob Brentrup of Dartmouth College has also been very helpful. Lastly, [Adams] has been an immense aid in this exploration, and has supplied many of the ideas mentioned in this document.
This section reviews many of the policy issues that have tobe addressed while planning to deploy a PKI-Lite infrastructure.
When setting up a PKI, an institution is expected to publish a "Certificate Policy (CP)" and a "Certification Practices Statement (CPS)." A CA issuing certificates that reference the policy object identifier (OID) of a particular CP MUST be operated in a manner consistent with the terms and conditions described in that CP. In this context, "operate" includes mangement of the PKI infrastructure, and management of the certificates that are issued. The CPS describes how the CA implements the provisions of the CP. These two statements taken together are designed so that a Relying Party can look at them and obtain an understanding of the trustworthiness of the certification associated with the credential.
The PKI-Lite Sample Certificate Policy can be found in section 1 of this document. It should be immediately obvious that this CP is radically "lighter" than the traditional CPs. The PKI-LITE CP spells out requirements related to:
It does NOT address many of the issues found in the HECP, including insurance, indemnification, governing law, etc. The requirements were explicitly designed so as to avoid being onerous. Remember, though, that if a campus claims to be operating their CA under the PKI-Lite CP, then they must adhere to the assertions being made in the CP.
A key issue that campus IT departments must address is when does the use of certificates progress to the point where it is "different from userids and passwords", and the IT department should begin consulting with legal.
The CPS describes the actual steps that an institution takes in implementing the CP. A sample CPS, for use with the PKI-Lite CP, is available here, in section 2. This CPS includes sections describing how the campus operates its CA, including:
This sample is, in fact, a template. A campus should be able to pickup this template, and edit it to describe the choices and implementation chosen by the campus. Again, the CPS was explicitly designed so as to avoid being onerous.
The PKI-Lite Certificate Profile describes how a CA operating under the PKI-Lite CP should use the various fields in the certificate. once again, the Lite aspect should be apparent. There are no hard and fast requirements for some fields (ie some fields can be left empty).
Note two fields needing additional explanation: Key Usage and Certification Policy, lifetime
Part of the process of validating a certificate involves ensuring that a trusted CA has digitally signed the certificate. Web Browser software performs this check every time a secure web site is accessed. All browsers come with a pre-filled Certificate Store that contains a number of the well-known commercial CA's; Verisign is probably the most well known of these. All PKI-enabled applications will have to perform this check.
When choosing what to use as a master root, a campus has several options:
Each site must decide whether to deploy its own internal PKI infrastructure - utilizing its own resources -- or to hire external resources to help with any or all of the PKI's internal operation. With In-Sourcing, the PKI is under the control of the campus. With Out-Sourcing, an organization allows an external third party to supply and operate some aspects -- perhaps even all aspects -- of its PKI.
This In-Sourcing/Out-Sourcing decision typically looks at the tradeoffs between cost and risk, although the unique characteristics of certificates may bring a new dimension to the definition of risk (new to universities, at any rate). However, the campus has to also examine its level of comfort with giving up control of the PKI infrastructure to a third party. There are a number of other issues that may be considered, including: response time from the vendor, level and availability of help desk support, flexibility and scalability issues, and disaster planning and recovery.
Out-sourcing the CA, however, does NOT remove from the campus the responsibility for making most of the policy decisions that have to be addressed before a CA can be turned on. It does place the liability associated with operating the CA on an external party. Presumably, the campus would then be charged for every certificate that is issued.
If a campus decides to In-source thier CA implementation, several software possibilities exist:
If a campus decides to Out-Source their CA implementation, most of the significant vendors in the certificate space could probably help.
PKI-Lite requires that "People identified in HE PKI-Lite certificates are authenticated using standard university practices for identifying people for other applications such as issuing user-IDs and passwords for on-campus systems". In other words, if members of the campus community already have a NetID and password, they can use those credentials (and maybe a bit more) to obtain a certificate. Note, though, that the typical web-based mechanisms that campuses use to enable NetIDs are viewed as having a relatively weak Level of Assurance.
Some campuses are actively exploring the possibility of leveraging the existing ID card process to obtain a higher LoA for both the enterprise userid/password and user certificates. On many campuses, faculty, students, and staff already have to go to an ID Card office and prove their identity in order to obtain a university ID card. Part of this process presumably ensures that the person is authorized to obtain an ID card. Since the person is already physically present in an office, this opportunity could be used to issue them a certificate with a higher LoA.
It is the responsibility of the campus to ensure that this type of Lite I & A is appropriate for the PKI-enabled applications they plan to deploy.
UVa has a typical set of steps built into its web-based certificate issuing process:
All the information I will provide and all the representations I will make in applying for a certificate are true. I agree to: Not share my private key with anyone, including my family members, nor will I allow anyone to have access to it. Protect my private key in accordance with University Policy, just as I protect my password. Inform the UVa Certificate Authority (pkimaster@virginia.edu) immediately should I believe the security of my private key has been compromised. Remove the UVa certificate and the associated private key from my browser within 24 hours of being informed that it has been revoked. I understand that when I use my certificate to access remote services that I am also providing the remote server with my name and email address.
Note: Although Lite does NOT specify including an OID for LoA in the certificate, a process like the one described above would probably correspond to RUDIMENTARY.
Qualifying for a higher LoA would typically require that the requesting individual physically appear in the RA office, and present a number of forms of identification.
A campus must analyze and understand the requirements of each PKI-enabled application with respect to Certificate Revocation -- the process of invalidating an existing key pair and certificate. Different applications can have radically different requirements. A range of possible approaches exists, from online distribution of revocation lists (fast, although not instantaneous) to more manual approaches. In addition, the campus has to understand the algorithms used by the client software in accepting and processing revocation information. Some client programs may require that the user initiate the process, rather than automatically checking for revocation.
A particular revocation issue for campuses is the high turnover rate among undergraduates. Some campuses have concluded that if their certificates have a lifetime of one year, it is not worth the effort to revoke the certificates of all of the seniors. Instead, they often decree that applications using certificates for authentication MUST also check the campus directory, and ensure that the user has an active entry in the directory; otherwise, authentication fails.
A strong argument can be made that private encryption keys should be escrowed. Otherwise, sealed email could never be unsealed if the private key were no longer available. However, if encryption keys are to be escrowed, then separate signing keys should be used. There should only be one copy of the private signing key, and that should be in the possession of the owner. Otherwise, the owner could always claim that their signature has been forged.
A campus must analyze the structure of its PKI-enabled applications to determine the role and need for escrow of private keys. Keys used for signing must never be escrowed, since that would allow someone to be able to impersonate the owner. When a key is used to seal (or encrypt) information, there must be a way to ensure that the information remains available to authorized parties when needed. If the encryption is only used to hide the information while it is in transit, then simply saving the information upon receipt in unencrypted form is one approach. Another approach is to encrypt the information to the keys of multiple parties and make it available to each of them. E.g. contracts could be encrypted to the lawyer involved, and also CC'd and encrypted to an "archival" account at the legal office. Yet another approach is to escrow the encryption key. The best approach depends on how the cost, complexity and risk assessments play out for a given situation.
A Key escrow/recovery facility could be implemented as part of the CA, or as a separate implementation. On a small scale, it could even be implemented via a manual process.
A scalable method of disseminating certificates to relying parties is a key aspect making PKI usable. Many campuses choose to automatically store people's certificates in the campus directory. Certificates can then be easily obtained by anyone who needs them. Since certificates are considered to be public information, this may be an easy and effective way of publishing them.
If one of the proposed applications is Web Server certificates, for use with SSl or TLS, then there are a number of browser related issues that will have to be addressed. They are described here. The biggest practical problem will be adding the campus' Root Certificate to the Certificate Store of all/most/many of the browsers accessing secure campus based web servers, if the campus' trusted root is not already in the browsers.
A Certificate Authority requires the kind of process, operational, and technical support usually provided for administrative information systems. It also needs the level of pysical and operational security provided for other security systems (eg the kerberos KDC).
For a checklist of issues and concerns, and some suggestions on "extreme good practice", review [HECP].
These two topics are intertwined, and probably inseparable. These questions are a concern in direct proportion to the Level of Assurance that is being asserted, and the level of exposure that would be created if the CA's private key were compromised. There are many approaches to this problem, and (unfortunately) all seem to entail some level of risk. For example, it might seem prudent to keep the private key inside tamper-proof hardware, with no possibility of getting the key outside the unit. This clearly avoids the exposures that exist where a human may have access to the raw private key. However, what happens when the manufacturer of this device sells the product line to another company, which then discontinues it?
If humans do have access to the raw private key, then various approaches are possible. Normal safe storage and auditing processes may be deemed sufficient. However, some sites may opt for splitting the key and storing the parts separately, and requiring that multiple people are involved in order to use the key.
Jeff Schiller has written a document describing issues related to protecting the private key of a CA.
The University of Virginia has described the steps they have taken to protect the primary and secondary key pairs in their CA.
(text from UVa http://www.itc.virginia.edu/intranet/cdp/pki/protection.html ) UVa Standard Assurance CA operates using a two-level hierarchy of Key Pairs. The Primary Key Pair (PKP) is generated on a small off-line computer. The public key portion of the PKP appears in the certificate signed by CREN and forms the master root of the UVa CA. The small off-line computer is used once each year to generate a Secondary Key Pair (SKP). The public portion of the SKP is placed into a certificate signed by the PKP's private key. The SKP's private key is moved to an on-line computer and used to sign End Entity certificates for a one-year period.
One point everyone seems to agree on is that the private key for the campus CANNOT be stored on a device that is attached to the network. Because the CA itself is likely to be accessible via the web, this will lead toward the two-level scheme described by UVa.
See sections 5 and 6 of the HECP for a thorough review of issues.
The University of Virginia has described the steps they have taken to physically protect their CA Hardware.
(text from UVa) One of the critical aspects of the operation of a Public Key Infrastructure (PKI) Certification Authority (CA) is the protection of the private portion of the CA's key pair. The CA's private key is used to sign the certificates for all of the End Entity (EE) certificates issued by the CA. In our case, we issue EE certificates to university students, faculty, and staff. If the private key is compromised and obtained by a third party it can be used to forge certificates that are indistinguishable from those generated by the real UVa Certification Authority and its protection is critical to the operation of the system. The only solution to the compromise of a CA's private key is the revocation and reissue of all associated EE certificates.
It is important to consider absolute worst-case scenarios, since the compromise of the university's private key could have catastrophic consequences.
The campus must decide whether or not its use of PKI requires that they implement a revocation process. If graduates possess valid certificates for a few months, does that create an unacceptable exposure? If a user key is compromised, what is the exposure?
If a campus decides it needs to implement a revocation process for some situations, then they need to implement a way to distriute a list of the revoked certificates.
If a campus is operating their CA under the PKI-Lite CP, they are allowed to use existing campus practice for identifying the certificate Subject before issuing the certificate. In most cases, this will mean that campuses can use a similar proocess for issuing certificates. Perhaps they can even leverage the userid/password, and use those credentials to obtain a certificate. A web-based form can be used to obtain a certificate.
For example, the UVa Standard Assurance Certification Authority is designed for medium assurance processes. Certificates are issued to members of the university community based on the individual's knowledge of their UVa Computing ID, their Last Name, Date of Birth, and their password to one of our central systems. No physical identification is required. A higher assurance CA with requirements for physically presenting identification is also being developed.
If a campus were operating under one of the more traditional CPs, it would have to operate one or more RA offices. Users desiring certificates would have to physically visit one of these offices, and offer several forms of identification to prove their identity. For a campus with tens of thousands of students, and without high LoA requirements, creating and operating this RA bureaucracy will quickly prove to be a significant expense and burden.
The PKI-Lite CP requires that the user's private key be generated by their computer. Typically, this would leverage the existing support in web browsers for this operation.
Typically, a web based process would be used to upload the user's private key to the CA, trigger getting it signed by the CA, and then downloading it back into the certificate store in the browser.
This process should be as transparent as possible to the user. Ideally, the program would notice that the certificate's lifetime was about to expire, and would automatically and transparently obtain a new certificate.
If the campus supports this process, then they willneed a process for users to report compromised keys, and for the campus to add this certifiate to the revocation list.
- there is some discussion on revocation and key escrow in the PKI-Lite profile doc and in the Outlook/Outlook Express S/MIME document
[Adams] Adams, Carlisle, and Lloyd, Steven. Understanding Public Key Infrastructure. Indianapolis, IN: Macmillan Technical Publishing, 1999.
[HECP] -- http://middleware.internet2.edu/certpolicies/HEPKI_CP_011.pdf
[HEBCA] -- http://www.educause.edu/hebca/
[PKI-Lite] -- http://middleware.internet2.edu/hepki-tag/
[FIPS 140] -- http://csrc.nist.gov/cryptval/
[PKIX] -- IETF PKIX docs ( http://www.ietf.org/ids.by.wg/pkix.html )
[Fed PKI] -- X.509 Certificate Policy For The Federal Bridge Certification Authority http://archive.ncsa.uiuc.edu/General/GridForum/SWG/Federal_Bridge_CP.html
[CREN] CREN's "Guide for Getting Started with Digital Certificates" A Mellon/NSF Supported Project (http://www.cren.net/crenca/onepagers/guidebook.html )
From : Randy Butler < rbutler@ncsa.uiuc.edu > Date : Fri, 03 Mar 2000 11:11:26 -0600
I've posted the Federal Bridge Certificate Policy at http://www.ncsa.uiuc.edu/General/GridForum/SWG/Federal_Bridge_CP.html for your review.
Note this replaces the earlier work that the Federal PKI Steering Committee did on the Model Certificate Policy. The Federal Bridge CP follows the earlier CP model very close however. I talked to Rich Guida and he said they are trying to get federal agencies to use the Federal Bridge certificate policy as the model now and the older model generated by the FPKI Steering Committee is now dead.
Also note the Federal Bridge policy documents 4 levels of certificates, or to be more precise there are four policies each with a different trust level defined in this document. I am thinking that we might do well to pick one of those levels as a starting point for our discussions. The four levels defined rudimentary, basic, medium, and high. Rudimentary translates into very weak identity verification and high is at the opposite end of the spectrum.