PKI and Digital Certification Infrastructure

Ray Hunt, Associate Professor, Department of Computer Science, University

of Canterbury, New Zealand

Abstract enough. If traditional paper based commerce are

to be reproduced in the electronic environment,
Secure VPN technology is only possible with the the following are required:
use of appropriate security systems such as
0 Security policies to define the rules under
encryption, digital signatures, digital certificates,
which cryptographic systems should operate
public/private key pairs, non-repudiation, and
time-stamping. A PKI comprises a system of 0 Products to generate, store and manage
certificates, certificate authorities, subjects, certificates and their associated keys
relying partners, registration authorities, and key Procedures to dictate how keys and
repositories that provide for safe and reliable certiiicates are generated and distributed
communications. This paper discusses these key
technologies focusing particularly on recent A trusted and authenticated key distribution
standardisation as well as looking at some of the infrastructure is necessary to support the use of
challenges pending its widespread operation in public keys in a public network such as the
the industry. Internet. Recent efforts in standardisation have
seen developments on a number of fronts.
1. Introduction
2.1 Evolution of PKI standards
Public key cryptography can play an
important role in providing security services The X.509 Recommendation provides a useful
including confidentiality, authentication, digital basis for defining data formats and procedures for
signatures and integrity. This paper provides a the distribution of public keys via certificates that
brief outline of the basic concepts and principals are digitally signed by CAS. X.509 does not
involved in its operation including issues such as however include a profile to specify the supporting
how a PKI operates, its characteristics and what requirements for many of the certificate’s sub-
problems need to be addressed before the use of fields, exlensions or for some data values.
PKI becomes more widespread. PKI can be used The standards effort produced an outline for
to solve many problems, however there are still PKI of X.509 Version 3 certificates as well as
several problems and risks involved in its use as Version 2 Certificate Revocation Lists (see Section
well as organisational and management issues for 3.2.3). The Internet PKI profile went through
which solutions are still evolving. eleven draft versions before becoming RFC 2459
[ 3 ] . Other profiles have been developed for
2. PKI background and standards particular algorithms to make use of RFC 2459.
developments
The development of the PKI management
Public key cryptography was conceived in protocols has gone though a number of iterations.
1976 by Diffie and Hellman [ I ] and in 1977, RFC 25 10 [4] was developed to specify a message
Rivest, Shamir and Adleman designed the RSA protocol I O be used between entities in a PKI. The
Cryptosystem [2], the first public key system. need for an enrolment protocol and the preference
Each public key cryptosystem has its own to use PK:CS#10 message format as the certificate
technical features, however they all share the request si ntax lead to two parallel developments.
property that given an encryption key it is
computationally infeasible to determine the The Certificate Request Syntax was developed in
decryption key and vice versa. Theoretically, no the S/MIME WG which used PKCS#10 [5] as the
confidential information needs to be exchanged certification request message format. Certificate
before secure communication is possible. Request Message Format RFC 251 1 [6] draft was
Everyone has access to the recipient’s public key also developed but in the PKIX WG. It was to
and even though the communication is private, define a simple enrolment protocol that would
the message cannot be authenticated. This shows work for the RFC 2510 [4] enrolment protocols,
that public key cryptography on its own, is not but it did not use PKCS#IO as the certificate
234
1531-2216/01 $10.00 0 2001 IEEE
request message format. Then, RFC 2510 [4]and document containing the operational procedures on
[7] were developed to define an extended set of how the security policy will be enforced and
management messages that flow between the supported. It includes specifications on how the CAS
components of the Internet PKI. These, combined are constructed and operated, how certificates are
with CMS [7] allowed the use of an existing issued, accepted and revoked, how keys will be
protocol (SMIME) as a PKI management generated, registered and certified, where they will
protocol, without requiring the development of an be stored and made available to users.
entirely new protocol such as CMP [4]. It also
3.1.2 Certification Authority (CA)
included PKCS#IO as the certificate request
syntax. The CA is an entity which issues and revokes
certificates. An in-house server or a TTP such as
Development of the operational protocols has
Entrust, Baltimore or VeriSign, can provide a CA
been more straightforward. Two documents for
function. A CA provides the trust basis for a PKI as
LDAP have been developed - one for defining
it manages public key certificates for their whole life
LDAPv3 as an access protocol to repositories [8]
cycle. The CA will:
and one for storing PKI information in an LDAP
directory [9]. Using FTP and HTTP to retrieve Issue certificates by binding the identity of a user
certificates and CRLs from PKI repositories is or system to a public key with a digital signature
specified in RFC 2585 [IO]. Schedule expiry dates for certificates
3. Public Key Infrastructure Ensure certificates are revoked by publishing
Certificate Revocation Lists (CRLs)
PKI provides the core framework for a wide
variety of components, applications, policies and When implementing a PKI, an organisation can
practices to combine and achieve the three principal either operate its own CA or use the services of a
security functions (integrity, authentication and non- Commercial CA or TTP. While the principles of PKI
repudiation). A PKI is a combination of hardware are the same there are currently two major
and software products, policies and procedures. It commercial implementation models which depend
provides the basic security required for secure upon who the CA is. (On each of the respective web
communications so that users who do not know each sites are a number of white papers claiming the
other or are widely distributed, can communicate advantages of each of these models [ 121):
securely through a chain of trust. Digital certificates 1. Private CA - vendors sell a complete PKI
are a vital component in the PKI infrastructure as system to an organisation which then becomes
they act as ‘digital passports’ by binding the user’s its own CA and is responsible for the issuing
digital signature to their public key
and management of certificates. Examples
3.1 Components of a PKI include RSA’s Keon 5.0, IBM’s Secureway
Trust Authority 3.1, Baltimore’s Unicert 3.0.5
A PKI consists o f and Entrust’s PKI 4.0.
0 Security policy
2. Public CA - certificates are purchased from a
Certificate Authority (CA) public CA organisation as required. The most
0 Registration Authority (RA) common example of this approach is VeriSign.
Certificate repository and distribution system 3.1.3 Registration Authority (RA)
0 PKI-enabled applications
An RA provides the interface between the user
3.1.1 Security policy and the CA. It authenticates the identity of the users
and submits the certificate request to the CA. The
A security policy defines an organisation’s top-
quality of this authentication process determines the
level direction on information security as well as the
level of trust that can be placed in the certificates.
processes and principles for the use of cryptography.
For example, if all an RA requires is an e-mail
Typically it will include statements on how the
address and a name, the level of trust that should be
organisation will handle keys and valuable
placed in that certificate would be considerably
information and will set the level of control required
lower than if more stringent registration procedures
to match the levels of risk.
were required.
Some PKI systems are operated by Commercial
3.1.4 Certificate repository and distribution
Certificate Authorities (CCAs) or Trusted Third
system
Parties (TTPs) and therefore require a Certificate
Practice Statement (CPS) [ l l ] . This is a detailed

235
 Di gi t at Iy
Signed
Code and
Fi I es
St andar ds
that r e l y
on a PKI

St andar ds
X509 PKI X t hat def i ne
t h e PKI
Figure 1 PKI security architecture [13]

3.2 Operations of PKI and retrieving certificates and CRLs, as well as key
lifecycle m.anagement. Some of the enhanced
The main PKI functions are shown in Table 1. functions include time-stamping and policy-based
These include - registration, issuing and revoking certificate validation.
certificates, creating and publishing CRLs, storing

Function I Description I Implementation

Registering users I Collect user information, verify identity 1 Function of CA, or separate RA
Issuing certificates Create certificates in response to user or Function ofthe CA
administrator request
Revoking certificates Create and publish Certificate Revocation
Lists (CRLs) I Administrative software associatcd with the
CA
Storing and retrieving
certificates and CRLs
Make certificates and CRLs available to
authourised users
1I Repository for certificates and CRLs in secu
replicated directory service accessible via
LDAP
Policy-based certificate pat
validation

Time-stamping
1 Impose policy-based constraints on
certificate chain, and validate if all
constraints are met
Time-stamp each certificate
Function of the CA

Function of the CA or a dedicated Time

Key lifecycle management Update, archive and restore keys Automated in software or performed manual

Table 1 Public Key Infrastructure (PK 1) Functions

These functions can be described in terms Certification is the process of binding a public
of three basic PKI infrastructures: key value to an entity

236
 Validation is the process of verifying that a information pertaining to those keys are published.
certificate is valid and revoking where A CA might have different classes of certificates
necessary with each class providing a designated level of trust.
For example to overcome these inherent limitations
Key management - updating, backing up and
archiving VeriSign has introduced four different levels of
certificate [ 141 (each with different cost structures)
3.2.1 Certification corresponding to the degree of authentication
required and shown in Table 2 .
Certification is the fundamental function of all PKIs
and it is the means by which the public keys and

VeriSign Class 1 Individual Certificates enhances the security of some applications by assuring that a certificate’s
subject and e-mail address are included within VeriSign’s repository but do not provide proof of identity.
VeriSign Class 2 Individual Certificates provide a reasonable level of assurance of a subscriber’s identity. Identities art
checked against local records or Trusted Third Parties (TTP).
VeriSign Class 3 Individual Certificates provides a higher level of assurance by validating the identity via in-person
presentation of identification credentials or other enhanced procedures. Used in banking and contracting applications.
VeriSign Class 3 Organisational (Server) Certificates provide assurances for web site authentication. Validation
includes comparison of certificates to information held by TTPs or official records.

Table 2 Classes of Digital Certificates available from VeriSign

In addition to the content and authenticity of a Request the CA to include a validity period in
transaction, the exact time of the transaction can be the certificate (offline validation)
important. For example, it may have to be submitted
within a specified time to be valid. The solution Closely related to the issue of validation of
therefore is to combine signatures with a time- certificates is certification revocation. A certificate
stamping service. (Section 5.5) should be revoked when it is suspected that it has
been compromised. If a certificate is validated online
3.2.2 CA hierarchy with the CA, the CA can simply state that the
It is impractical to have a single universal CA certificate is no longer valid. With offline validation,
and most PKIs permit CAS to certify other CAS. the most common method is to use Certificate
Different PKIs arrange their CAS in different Revocation Lists (CRLs). A CRL is a list of
hierarchies or they may even have arbitrary or certificates that have been revoked before their
bilateral structural agreements. scheduled expiration date. For example, the key
specified in the certificate might have been
The scalability of a PKI depends on the compromised or the user specified in the certificate
relationship between its CAS. A problem here is that may no longer have authority to use the key.
CAS may allocate trusts differently and this problem
increases as the certification path grows. The The PKIX recommendation does not require CAS
certification path also runs the risks of becoming too to issue CRLs [15]. On-line methods of revocation
long. Path discovery and trust delegation is difficult notification may be applicable in some situations as
to achieve across company and/or geographical an alternative to CRLs. PKIX defines an Online
boundaries. The dominant hierarchy is top down, but Certificate Status Protocol that facilitates on-line
it has the problem that all users must trust the root checking of the status of certificates [ 161 [ 171.
CA and since so many paths pass through the root 3.2.4 Key management
CA, it is vulnerable to attack.
Each user is likely to have a number of keys that
3.2.3 Validation and revocation require lifecycle management. For example, users
The information in a certificate can change over typically have at least one key pair for each secure
time and a certificate user needs to validate that the application (e.g. e-mail, desktop file encryption,
certificate’s data is current. Users can either: VPN). Some applications use several key pairs for
different purposes, such as digital signatures, bulk
Ask the CA about a certificate’s validity every
encryption, and authentication.
time it is used (online validation)

237
 Updating keys - new keys are usually issued at Time-stamping and data certification services,
regular intervals so as to reduce the exposure from which tcan be used to build services such as non-
keys that have been unknowingly compromised. repudiation
Backing up keys - Users frequently forget 5.1 X.5091~3profiles
passwords that protect their private keys - or they
may lose the keys, for example, through a disk crash X . 5 0 9 3~ certificates are complex data structures
or virus attack. as they offer a variety of extensions which can take
on a wide range of options. This provides
Archiving keys - When employees leave the considerable flexibility, which allows the X . 5 0 9 ~ 3
company, their keys must be invalidated, while certificate format to be used with many applications.
retaining the keys in order to access previously Unfortunately, this same flexibility makes it
encrypted files and messages. Keys used for digital extremely difficult to produce independent
signatures may be retained for as long as the signed implementations that will actually inter-operate. To
documents exist so that signatures can be verified. build an Internet PKI based on X . 5 0 9 ~ 3certificates,
the PKIX working group developed a profile of the
Key expiry - To guard against a long-term
cryptanalytic attack, every key must have an X . 5 0 9 ~ 3sipecification - RFC 2459 [3] together
expiration date. The key length should be long with additional ongoing work [20].
enough to make the chances of cryptanalysis before In addic ion to profiling the certificate and CRL
key expiration extremely small. The validity period formats, it is necessary to specify particular Object
for a key pair may also depend on the circumstances Identifiers (OIDs) for certain encryption algorithms,
in which the key is used. The appropriate key size is since there are a variety of OIDs registered for
determined by the validity period, together with the certain algorithm suites. PKIX has produced two
value of the information protected and the estimated documents [21] and [22], which provide assistance
strength of an expected attacker. on the implementation of specific algorithms.
5. PKI Working Group activities 5.2 Operiational protocols
There are two main IETF working groups Certificates and CRLs can be delivered by
focused on PKI standards and implementations. protocols such as LDAP, HTTP, FTP and X.500.
Operationall protocols that facilitate certificate
The SPKI (Simple Public Key Infrastructure)
delivery are: defined in [lo], [17], [16] and [23].
working group (www.ietf.org/html.charters/spki-
charter.htm1) is developing Internet drafts for public 5.3 Mana,gementprotocols
key certificate formats, signature formats and key
acquisition protocols. SPKI is intended to provide Management protocols are needed to support
mechanisms to support security over a range of online inr.eractions between PKI user and
protocols (e.g. IPSec) and applications which may management entities. For example, a management
require public key certificates such as encrypted e- protocol might be used between a CA and a client
mail, web documents and electronic payment with whom a key pair is associated, or between CAS
systems. Two important RFCs developed under which cross-certify one another. A management
SPKI include RFC 2692 [ 181 and RFC 2693 [ 191. protocol can be used to carry user or client system
registration information, or requests for certificate
The PKIX working group has developed revocation. Management protocols that facilitate
recommended standards covering five significantly message format and transmission are defined in [4]
different sections (www.ietf.org/html.charters/pkix- and [7]. Certificate Policies and practice statements
charter.html) [ 151: are defined by [24].
Profiles of the X . 5 0 9 ~ 3certificate standards and
5.4 Time-stampand data certification
the X . 5 0 9 ~ 2CRL standards for the Internet
Operational protocols - relying parties can Time-stamping is a service in which a Time-
obtain information such as certificates or stamp Authority (TSA) signs a message to provide
certificate status evidence that it existed prior to a specific time. A
Time-stamping protocol [25] provides some support
Management protocols, in which different for non-repudiation so that a user cannot claim that a
entities in the system exchange information transaction was later forged after compromise of a
needed for proper management of the PKI private key.
Certificate policies and certificate practice
A Data Certification Server protocol [26] is a
statements, covering the areas of PKI security
TTP that verifies the correctness of specific data
not directly addressed in the rest of PKIX

238
submitted to it, thus going beyond a simple time- [[9] RFC 2587, Boeyen, S . , Howes, T., Richard, P.,
stamping service. The DCS certifies possession of "Internet X.509 Public Key InfrastructureLDAPv2
data or validity of another entity's signature. As part Schema", June 1999
of this, the DCS verifies the mathematical [IO] RFC 2585, Housley, R., and Hoffman, P., "Internet
correctness of the actual signature value contained in X.509 Public Key Infrastructure Operational Protocols:
a request and also checks the full certification path J T P and H'ITP", July1998
from the signing entity to a trusted point (e.g., the [ 111 Arsenault, A & Turner, S., Certification Practice
DCS's CA, or the root CA in a hierarchy). Statement, Internet Draft PKIX Roadmap, October 1999
[ 121 Public- Key Infrastructure- The VerisSign
6. Summary Difference; VeriSign whitpaper, 1999
(www.verisign.com/whitepaper/enterprise/difference)
This paper has reviewed a range of technical,
infrastructural, operational and management issues [ 131 RSA Data Security, "UnderstandingPKI".
(www.rsa.coni) 1999
associated with the use of PKI. There is no weakness
in the cryptographic strength of the encryption and [ 141 VeriSign., VeriSign Certification Infrastructure,
www.verisign.com/repository/CPS 1.2/CPSCH2.HTM#
digital signature processes, however the
toc36 1 806948, 1997
management of these processes, storage of
cryptographically strong keys, identification of [ 151 Arsenauly, A and Turner, S., "Internet X.509 Public
Key Infrastructure PKIX Roadmap". <draft-ietf-pkix-
entities, storage of certificates etc, all need be
roadmap.txt>, November 2000
subject to good business practices.
[ 161 RFC 2560, Arsenauly, A and Turner, S., X.509
PKI is still in its infancy and yet many Internet Public Key Infrastructure Online Certificate
organisations have already begun deploying Status Protocol - OCSP, 2000
certificate-enabled applications and infrastructures. [ 171 Myers, M., Ankney, R., Malpani, A., Galperin, S.,
Looking ahead, businesses and organisations who and Adams, C., "X.509 Internet Public Key Infrastructure
intend to use PKI will have to examine issues such Online Certificate Status Protocol - OCSP Extensions",
the legal aspects of liability, interoperability between September 1999
multiple PKIs, certification validation paths, [ 181 RFC 2692, Ellison, C., "SPKI Requirements",
protection of private keys and user acceptance. September 1999
Given the complexity of the infrastructure required [I91 RFC 2693 Ellison, C. et al, SPKI Certificate Theory,
to implement and support a public PKI system, in September 1999
the short term continued deployment of PKI-enabled [20] Santesson, S., Polk, W., Barzin, P., and Nystrom, M.,
applications for specific industry groups seems to be "Internet X.509 Public Key Infrastructure Qualified
the most likely scenario. Certificates",<draft-ietf-pkix-qc.txt>, February 2000
[21] Bassham, L., Johnson, D., and Polk, W., "Internet
8. References x.509 Public Key Infrastructure: Representation of Elliptic
[ I ] Diffie, W. and Hellman, M. E., New Directions in Curve Digital Signature Algorithm (ECDSA)", cdraft-ietf-
Cryptography. IEEE Transactions on Information Theory, pkix-ipki-ecdsa.txt>,October 1999
22 ( 1 976), pp. 644-654. [22] Housley, R., and Polk, W., "Internet X.509 Public
[2] Rivest, R., Shamir, A. and Adleman, L., A Method for Key Infrastructure Representation of Key Exchange
Obtaining Digital Signatures and Public Key Cryptosystems Algorithm (KEA) Keys in Internet X.509 Public Key
Communications of the ACM, 21(1978), pp. 120-126. Infrastructure certificates", March 1999
[3] RFC 2459, Housley, R., Ford, W., Polk, W., and Solo, [23] RFC 2559, Boeyen, S., Howes, T., and Richard, P.,
D., "Internet X.509 Public Key Infrastructure Certificate "Intcmet X.509 Public Key Infrastructure Operational
and CRL Profile", January 1999 Proiocols - LDAPvZ", April 1999
[4] RFC 2510, Adams, C., Farrell, S., "Internet X.509 [24] RFC 2527, Chokhani, S., and Ford, W., "Internet
Public Key Infrastructure Certificate Management X.509 Public Key Infrastructure Certificate Policy and
Protocols", March 1999 Certification Practices Framework", March 1999
(51 PKCS#IO, RSA, "The Public-Key Cryptography 1251 Adams, C., Cain, P., Pinkas, D., and Zuccherato, R.,
Standards ", RSA Data Security Inc., November 1993 "Internet X.509 Public Key Infrastructure Time Stamp
[6] RFC 251 I , Myers, M., Adams, C., Solo, D., and Protocols", <draft-ietf-pkix-time-stamp.txt>,2000
Kcmp, D., "Internet X.509 Certificate Request Message 1261 Adams, C., Sylvester, P., Zolotarev, M., Zuccherato,
Format", March 1999 R., "Internet X.509 Public Key Infrastructure Data
[7] Myers, M., Liu. X., Fox, B., and Weinstein, J., Certification Server Protocols", <draft-ietf-pkix-dcs-.txt>,
"CertificateManagement Messages over CMS", <draft- March 2000
ieft-pkix-cmc.txt>, July 1999
[SJ RFC 2251, Wahl, M., Howes, T., Kille, S.
"Lightweight Directory Access Protocol (v3)" 1997

239