Girma Nigusse

Master’s Thesis1
Evaluating Public Key Certificate

Revocation Schemes:
Towards Conceptually Versatile Revocation Scheme
Girma Enideg Nigusse
Submitted in Partial Fulfillment of the

Requirements
for the Master Degree in
Information and Communication Systems Security at
the Department of Computer and Systems Science (DSV)

Royal Institute of Technology (KTH)
Sweden
August, 2007
1
This thesis corresponds to 20 weeks of full-time work.
c
�2007
Girma Enideg Nigusse
All Rights Reserved
Acknowledgement
(place holder ...) Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore
eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
Abstract
Today’s secure communications solely rely on Public Key Infrastructure (PKI) and its public
key certificate. However, there are a number of open problems and challenges in the design and
use of PKI. One of the architectural challenge in public key certificate is a public key certificate
is certainly valid for use until its issue date. Since a public key certificate can be compromised
any time after its issue date, there is no guaranty of any type about its validity after its issue
date. As a result, a public key certificate is probably valid until its expiration date. The current
design of X.509 based PKI uses a certificate revocation process to inform relying party about a
public key certificate status.
There are a wide variety of standardized, proprietary and proposed public key certificate re-
vocation schemes to manage public key certificate revocation validation process in a PKI. The
existence of different certificate revocation schemes is a challenge for PKI implementers, since
there is no standardized evaluation metrics or requirement specification by far. This thesis eval-
uates different public key certificate revocation schemes with a consistent evaluation metrics, in
an attempt to come up with a conceptually unified versatile certificate revocation scheme. This
thesis assumes that major public key certificate revocation process open problems are solved by
the existing public key certificate revocation schemes. The challenge is the solutions provided
by different certificate revocation schemes. In addition, most research works contemplate in
providing newer public key certificate revocation solution and a little attention is paid in inte-
grating the existing schemes. This thesis is a contribution which attempt to fill this gap through
classification of different certificate revocation schemes, in-depth evaluation with analysis of the
tradeoffs exist between different schemes, and requirement specification for a versatile certificate
revocation scheme towards the conceptual integration of the different schemes. The thesis also
investigates the different public key certificate revocation process approaches advocated by dif-
ferent PKI implementations and various misconceptions around public key certificate revocation
process.
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Symmetric and Asymmetric Key Cryptography . . . . . . . . . . . . . . 2
1.1.2 Public Key Certificate (PKC) . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 PKC Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.8 Brief Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Different PKIs vs. PKC Revocation 7

2.1 Asymmetric Encryption & Digital Signature . . . . . . . . . . . . . . . . . . . . 7
2.2 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 X.509 Compliant PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 SPKI/SDSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 PKC Revocation in Different PKIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 X.509 Certificate and CRL Format . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 X.509 PKC Revocation Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Classification & Evaluation Metrics 19

3.1 Classification of X.509 Certificate Revocation Schemes . . . . . . . . . . . . . . 19
3.2 PKC Revocation Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Design Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Performance Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Implementation Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Windows of Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Unique Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.6 Resource Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 27
III
IV CONTENTS
3.2.7 Cost Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.8 Security Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 PKC Revocation Schemes Evaluation 30

4.1 Traditional CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Partitioned CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Dynamic CRL Distribution Points . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Redirect CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Indirect CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.1 Indirect Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Over-Issued CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Windowed Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Black-list CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.11 Over-Issued Segmented CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.12 Over-Issued Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.13 Over-Issuing Delta CRL with Distribution Points . . . . . . . . . . . . . . . . . . 47
4.14 Sliding Window Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.15 Online Certificate Status Protocol (OCSP) . . . . . . . . . . . . . . . . . . . . . 50
4.15.1 OCSP Extensions (OCSP-X) . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.16 Distributed OCSP (D-OCSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.17 Certificate Revocation Status (CRS) . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.17.1 Fast Digital Identity Revocation . . . . . . . . . . . . . . . . . . . . . . . 54
4.18 NOVOMODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.19 Certificate Revocation Tree (CRT) . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.19.1 2-3 Certificate Revocation Tree (2-3 CRT) . . . . . . . . . . . . . . . . . . 57
4.20 Semi-Trusted Mediator (SEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.21 Trusted Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 Requirements & Integration 60

5.1 Versatile PKC Revocation Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Conceptually Versatile PKC Revocation Scheme Requirement Analysis . . . . . . 61
5.2.1 Major Stakeholders and Functional Components . . . . . . . . . . . . . . 61
5.2.2 Versatile PKC Revocation Scheme Requirement Identification . . . . . . . 63
5.3 PKC Revocation Schemes Integration . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Conclusion & Future Works 75

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A Alternative Names 86
List of Tables
1.1 The three Phases of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 X.509 Certificate and CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Selected Certificate Revocation Schemes Classification . . . . . . . . . . . . . . . 21

3.2 Perfomance Constraints Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Evaluation of Traditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Evaluation of Partitioned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Evaluation of Dynamic CRL Distribution Points . . . . . . . . . . . . . . . . . . 34
4.4 Evaluation of Redirect CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Evaluation of Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Evaluation of Indirect CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7 Evaluation of Over-Issued CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8 Evaluation of Windowed Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9 Evaluation of Black-list CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.10 Evaluation of Freshest CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11 Evaluation of Over-Issued Segmented CRL . . . . . . . . . . . . . . . . . . . . . 46
4.12 Evaluation of Over-Issued Delta CRL . . . . . . . . . . . . . . . . . . . . . . . . 47
4.13 Evaluation of Over-Issuing Delta CRL with Distribution Points . . . . . . . . . . 48
4.14 Evaluation of Sliding Window Delta CRL . . . . . . . . . . . . . . . . . . . . . . 49
4.15 Evaluation of OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.16 Evaluation of D-OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.17 Evaluation of CRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.18 Evaluation of NOVOMODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.19 Evaluation of Certificate Revocation Tree . . . . . . . . . . . . . . . . . . . . . . 57
4.20 Evaluation of SEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
V
List of Figures
2.1 X.509 Certificate and CRL life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Existing Perspectives on Classifying Certificate Revocation Schemes . . . . . . . 20
5.1 PKC Revocation Scheme Stakeholders and Functional Components . . . . . . . 61

5.2 Some Evaluation Metrics of a PKC revocation Scheme . . . . . . . . . . . . . . . 63
5.3 Traditional CRL based PKC revocation schemes dependency . . . . . . . . . . . 68
5.4 Non CRL based PKC revocation schemes dependency . . . . . . . . . . . . . . . 70
5.5 Traditional CRL based PKC revocation schemes improvement dependency . . . . 71
5.6 Non CRL based PKC revocation schemes improvement dependency . . . . . . . . 72
VI
List of Acronyms
ARL Authority Revocation List

CA Certificate Authority
CCITT Consultative Committee on International Telegraphy and Telephony
CIA Confidentiality, Integrity & Availability
CMAE Certificate Management Ancillary Entity
CRL Certificate Revocation List
CRT Certificate Revocation Tree
CSI Certificate Status Information
DN Distinguish Name
D-OCSP Distributed Online Certificate Status Protocol
DoD stste Departemet of Defenvce
DOS Denial of Service
FRIP Freshest Revocation Information Pointer
FTP File Transfer Protocol
HCRS Hierarchical Certificate Revocation Scheme
IAA Identification, Authentication and Authorization
IETF Internet Engineering Task Force
IPsec Internet Protocol Security
ITU International Telecommunication Union
KCA Key Compromise Agent
LDAP Lightweight Directory Access Protocol
MITM Man-In-The-Middle
NIST National Institute of Standards and Technology
OCSP Online Certificate Status Protocol
OCSP-X Online Certificate Status Protocol Extension
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PKC Public Key Certificate
PKI Public Key Infrastructure
PKIX Public Key Infrastructure for X.509 Certificates (IETF)
RA Registration Authority
S/MIME Secure/Multipurpose Internet Mail Extensions
SB Suicide Bureau
VII
SDSI Simple Distributed Security Infrastructure
SEM Semi-Trusted Mediator
SET Secure Electronic Transaction
SPKI Simple Public Key Infrastructure
SSL Secure Sockets Layer
SWD CRL Sliding Window Delta CRL
TLS Transport Layer Security
TTP Trusted Third Party
URI Universal Resource Identifier
Chapter 1
Introduction
This chapter gives a high level explanation about digital identity management in the last years
and explains the motivation behind this thesis. It briefly pinpoints how identity management
advances from the early days of username-and-password applications until today’s certificate
based identity management infrastructure. It also describes the intended audience, purpose,
research methodology applied, scope and the main goal of this thesis.
1.1 Background
Identity is a set of facts about an entity. An identifier is some strings of character, digits or
symbols which is used to refer an entity. A system security model in the late 1960’s for multi-
user time sharing systems was commonly known as IAA (Identification, Authentication and
Authorization) [ELL03]. In IAA, identity serves as a means of identification. Based on the iden-
tification, verification of entity identity (authentication) and resource granting (authorization) is
achieved. These processes in the IAA security model exhibit a linear precedence. There need to
be an identifier of an entity before authentication and an entity has to be authenticated before
authorization.
In a networked environment the simplest possible communication can be established just by

sending a message to the intended recipient without authenticating the sender and receiver of
the message. The problem is any one can send similar message as a sender and the receiver has
no way to verify. Impersonating sender/receiver or both was a threat to this type of commu-
nication, since neither a proper identification nor a proper authentication involved in this type
of communication. As a result, communication security was unthinkable. Since then, a lot of
approaches introduced to enable a secure communication between entities. In the past years IP
address is used for client authentication. It was believed before, that IP address will serve as a
unique identifier for a client and validating the IP address is sufficient, but this method suffers
a lot from IP spoofing attack [CER96].
1
2 CHAPTER 1. INTRODUCTION
On the other hand, the widely used approach of presenting username-and-password for authen-
tication purpose is not secure either because of replay or play-back attack [KR00]. Username-
and-password designed to be used multiple times. For the relying party, there is no way to dif-
ferentiate between the real username-and-password and the play-back username-and-password.
Another short coming of username-and-password authentication approach is that, it is impossi-
ble to test the ‘livens’ of the communicating party. Since it is a one-way authentication protocol
and there is no challenge-response interaction between the communicating parties. As a result,
there is no way to proof that the username-and-password entered is coming from the right holder
or a phony one by from an automated computer attack program [BGH+ 93].
1.1.1 Symmetric and Asymmetric Key Cryptography

[KR00] shows how symmetric key cryptography with challenge-response can be used to overcome
the problem of replay attack and incorporate ‘livens ’ test at the same time in the authentication
architecture. Symmetric key cryptography is a secret key cryptography where the encryption
key is derived from the decryption key and vice versa, in most cases encryption and decryp-
tion keys are the same [SCH95]. Although, symmetric key cryptography has a problem of key
management, difficulties in initiating communication between previously unknown entities and
scalability drawbacks [AL02]. These problems make symmetric key cryptography based authen-
tication infeasible for today’s highly scalable applications of the Internet.
Asymmetric key cryptography [DH76] on the other hand does not have any of these three prob-
lems. Using asymmetric key cryptography with challenge-response is a better alternative to
solve the authentication problem [KR00]. Asymmetric key cryptography has different key for
decryption and encryption, namely private and public key (see Section 2.1). Public key is used
for encryption and private key is used for decryption transformation. Public key must be freely
distributed, whereas the private key must not disclosed to anyone else except the holder of the
key. The security of asymmetric key cryptography solely depends on its key pair security. A
system can only be secure when it maintains the required level of security for both private and
public key.
However, the level and type of security required for the key pair is different. The security re-
quirement of a private key is straight forward as its name implies. A private key must not be
disclosed to anyone other than its holder and a public key must be publicly available. However,
keeping the security of a key which is publicly accessible to anyone is a big challenge, because
of impersonation attack. The possibility of impersonation attack creates a big question on the
integrity and authenticity of the public key [KWO02]. Therefore, to accept a public key as valid,
there must be sufficient ‘guaranty’ for the relying party, to make sure that a given public key is
certainly belongs to the claimed owner [HAS00]. It appears that keeping private key private is
the hardest thing to do, although keeping the public key public is also not an easy task [NN05].
The weakest link in asymmetric key cryptography is the public key itself, because impersonation
of public key is practically possible. When the attacker impersonates both communicating ends
(sender/receiver) (MITM) attack is also simple [KR00]. To circumvent this attack, public key
1.2. MOTIVATION 3
relying parties needs to have some means to clearly distinguish between a real and a phony
public key.
1.1.2 Public Key Certificate (PKC)

A Public Key Certificate (PKC) [KOH78] is a digital certificate, which contains a public key
and holder identity identifiers, like holder’s name. It is signed by a Certificate Authority (CA)
to testify the presented public key on the PKC is really belongs to the claimed holder. PKC
centrally managed and distributed by a Public Key Infrastructure (PKI). A PKC creates a means
to validate the integrity and authenticity of a public key (see Section 2.2). If there is a way to
make sure the integrity and authenticity of a public key, there is no place for impersonation and
MITM attack. Finally, the introduction of PKC makes a secure authentication a reality.
In summary, using IP address for authentication is trivial because of IP spoofing attack; using
username-and-password also suffers from replay attack and difficulty in testing the ‘livens’ of the
communicating parties. Secure authentication through the use of symmetric key cryptography
and challenge response is possible. However, it is infeasible because of key management and
scalability problem. For basic asymmetric key cartography authentication, impersonation and
MITM attack is also practically possible. As a result PKC is introduced.
1.1.3 PKC Revocation

A PKC is certainly valid for use only until its issue date (start-date-time) and probably valid
until its expiration date (end-date-time). In some circumstances a not-yet-expired PKC be-
comes invalid; because it’s corresponding private key get compromise, certificate holder affili-
ation changed or other possible reasons (see Section 2.4). The challenge in such conditions is
after a PKC gets distributed (published ), it is impossible to take it back. Therefore, every use of
a PKC for any purposes has a risk of using a compromised certificate. The probable risk of mis-
using compromised PKC is minimized (ideally avoided ) by publishing PKC status information
along with the PKCs. In general the processes of providing PKC status information commonly
referred as certificate revocation.
1.2 Motivation
There exist a wide variety of standardized, proprietary and proposed certificate revocation
schemes today. Implementers of PKI based systems have to make a wise decision, to choose
the right PKC revocation scheme out of the existing schemes. As [IGS+ 03] discussed, there is a
lack of systematic or standardized framework to evaluate the existing PKC revocation schemes.
Also, there is almost no significant research work is done to integrate the existing PKC revoca-
tion solutions.
Researchers done considerable research works in the area and proposes various alternative ways
and mechanisms for PKC revocation from different perspectives. For example, research works
in improving the existing revocation mechanism [COO00], in evaluating the existing PKC re-
vocation schemes [ZHE03] [IGS+ 03] [RJK+ 00] [MFC02], in improving performance, reducing
cost, and increase scalability of PKC revocation schemes [SBY06] [LK01] [GCD+ 05] [KAN99]
[EMR05] [WLM00] [MIC96], in proposing PKC revocation for wireless ad hoc network [CD03],
on peer-to-peer distribution of PKC revocation list [MM03b] [LBT02], about applying biomet-
rics to PKC revocation schemes [SHMM04] etc.
Most of the research works done by far attempt to find newer and better ways to do PKC
revocation. What lacks is, a considerable research work aimed toward integrating the existing
methods into one robust PKC revocation scheme. This thesis assumes ‘major’ problems of PKC
revocation are already solved, but with separate PKC revocation schemes. No single PKC re-
vocation scheme gives all or most of the required security and functionality so far. Although,
Choosing one revocation method over the others mostly let PKI implementers to take a con-
siderable risk. For example if revocation scheme ‘A’ is good in scalability, it may not be cost
effective to implement. If revocation scheme ‘B’ is best in providing the validation response in
real time and in a cost effective way, it might have a scalability problem. The main motivation
here is; to investigate whether it is possible to create a PKC revocation scheme ‘C’ which has both
the advantage of ‘A’ and ‘B’ or not. If it is possible, revocation mechanism ‘C’ will be highly
scalable, requires low communication cost, and it gives real time validation request response.
Therefore, certificate ‘C’ can be thought as a versatile PKC revocation scheme, which combines
the functionality of both mechanisms.
1.3 Goal
The goal of this thesis is to evaluate, define the requirements and conceptually investigating
the possibility for engineering a versatile PKC revocation scheme based on the unification of
existing PKC revocation schemes.
1.4 Purpose
Evaluation of existing PKC revocation schemes can help implementers to choose and priori-
tize among the existing schemes. Defining the requirements and investigating the conceptual
possibility of a versatile PKC revocation scheme can help researchers in the area to further un-
derstand the relationship exist between existing proposed schemes, in hoping to unify them for a
better and versatile solution. As a result it can facilitate the standardization of PKC revocation
process, interoperability between different applications and domains for easy implementation,
and deployment of PKI solutions.
1.5 Methodology
This thesis starts with literature review and classification of different PKC revocation schemes.
Then, it lists out consistent evaluation metrics and commence the actual evaluation accordingly.
1.6. SCOPE 5
Follows a generalized PKC requirement is derived, based on the evaluation tradeoff analysis.
Finally the integration phase unifies the existing PKC revocation schemes into conceptually
unified groups and discuses how a versatile scheme can be derived. Table 1.1 classifies the whole
process in the thesis into three major phases and explained them in brief.
I. Input phase
1. Literature review: Study scientific literaturesin the area.
2. Classification: Categorizing existing PKC revocation schemes
into their proper family.
3. Metrics: Formalizing a consistent evaluation benchmark
to evaluate the existing PKC revocation
schemes.
II. Evaluation phase
4. Evaluation: Evaluate selected PKC revocation schemes
exhaustively according to the evaluation
metrics provided.
III. Output phase
5. Requirement: Driving requirements for a versatile PKC
revocation scheme based on the evaluation
tradeoff analysis result.
6. Integration: Finding a way to unify the evaluated PKC
revocation schemes.
Table 1.1: The three Phases of the Thesis
1.6 Scope
There exist different PKIs in practice today, among them X.509 [HPFS02], Pretty Good Privacy
(PGP) [ZIM95] and Simple Public Key Infrastructure/Simple Distributed Security Infrastruc-
ture (SPKI/SDSI) [EFL+ 99] PKI are the most common ones. This thesis specifically deal with
an X.509 based PKI; however the following chapter (see Chapter 2) provides a concise com-
parison of the three different PKIs. The comparison is aimed to illustrate the differences and
similarities exist between them and their approach in handling PKC revocation. The comparison
also helps to understand the concept borrowed by some of X.509 PKC revocation schemes from
non-X.509 PKI revocation schemes. As X.509 PKC revocation schemes is the central theme of
this thesis, most of the discussion about X.509 PKI exclude other aspects of X.509.
1.7 Audience
The intended set of audience for this thesis includes: PKI implementers, researcher, vendors,
information security students and other PKI interested stake holders in the information and
communication system security industries.
1.8 Brief Outline

The outline of the following chapters is briefly described as follows:
Chapter 2: Different PKIs vs. PKC Revocation
Introduce briefly public key cryptography and digital signature. Compare the three
types of PKIs and their revocation schemes. Introduce about X.509 PKC and its
revocation processes.
Chapter 3: Classification & Evaluation Metrics
Classify the existing PKC revocation schemes into their proper family and list out
the evaluation metrics with their associated values.
Chapter 4: PKC Revocation Schemes Evaluation
Evaluate the selected PKC revocation schemes based on the formalized evaluation
metrics.
Chapter 5: Requirements & Integration
Organize and present requirements for a versatile PKC revocation scheme and their
integration.
Chapter 6: Conclusion
A structured discussion of findings, concluding remarks with pinpointing future re-

search works.
Chapter 2
Different PKIs vs. PKC Revocation
This chapter provides background about the different approach used to accomplish certificate
revocation by X.509, PGP and SPKI/SDSI. It starts with a brief introduction about asymmetric
key cryptography data encryption and digital signature. Finally, it explains X.509 certificate
and X.509 CRL format briefly to give a foundation for the following chapters.
2.1 Asymmetric Encryption & Digital Signature

Asymmetric key cryptography [DH76] as introduced in previous chapter (see Section 1.1.1) has
different but related key pair, namely private and public key. Computationally it must be im-
possible to infer the corresponding private key, based on the knowledge of the publicly reveled
public key and the cryptographic algorithm used. Asymmetric key cryptography gives two ser-
vices, data encryption and digital signature. Data encryption is used to get the confidentiality
security service, whereas digital signature is used to get the benefits of non-repudiation, origin
authentication and data integrity security services.
Asymmetric key cryptography data encryption is performed as follows: first each communica-
tion participant has to generate key pair, one for encryption e and another for decryption d,
although, computationally it must be very difficult to find d given e. A sender has to do en-
cryption of a message m by using recipient public key and get the cipher text c, i.e. encryption
is c = e (m). On the other end of the communication line, recipient of the encrypted message
can perform the decryption by using its own private key and get the original message back, i.e.
decryption is m = d (c).
Digital signature is generated in asymmetric key cryptography using three steps; generation of
key pair, signature creation and signature verification. Out of the generated key pair, the private
key is used for signing of a data. Using private key helps to make sure only holder can sign a
message and that avoids signature forgery, while the public key is used for signature verifica-
tion. Using public key for signature verification helps publicly to read and verify a signature.
7
8 CHAPTER 2. DIFFERENT PKIS VS. PKC REVOCATION
It must be computationally infeasible to others, to compute a similar digital signature without

the knowledge of the private key.
Law enforcements of ‘qualified digital signatures’are practiced globally in today’s e-commerce, on-
line contracts and other online non-face-to-face transactions. Some of the examples are: United
Nation’s, United Nations Commission on International Trade Law (UNCITRA) Model Law on
Electronic Signatures [oITL02], the American Bar Association’s Digital Signature Guidelines
[Ass96] and European Parliament and of the Council on a Community Framework for Elec-
tronic Signatures [PtCotEU99] etc.
2.2 PKI
PKI is a set of data structures, network protocols and human procedures that enable the creation,
dissemination and revocation of asymmetric key pair and their corresponding PKC. Even if the
concept of PKI built on a single and well defined principle of asymmetric key cryptography,
a number of completely different PKI implementations exist. Among the most common once
are: X.509 compliant PKI, PGP and SPKI/SDSI. The following sub-section briefly explores
these three different PKIs, emphasis is given on their different approach toward PKC revocation
strategies.
2.2.1 X.509 Compliant PKI

X.509 [IT97] [IT00] [HPFS02] is a family of CCITT X.500 standards developed by ITU (Interna-
tional Telecommunication Union, formerly CCITT), which is specifically designed to addresses
the authentication framework in the X.500 family. X.500 [CCI88] proposal was intended to
create a global directory of Distinguish Name (DN), i.e. global directory of peoples and other
communicating entities . DN is a path name to the X.500 directory which is globally unique, like
global online telephone book. In X.509 certificate format DN is intended to be used as a source
of unique holder identity. TThe challenge is for a number of reasons X.500 proposal never been
realized, but X.509 is still in use today. Due to names confidentiality nature, those owning the
lists of names will not publish them to a global name directory like X.500. It is unthinkable for
CIA to publish its agents name list to an X.500 directory [ELL99]. The current X.509 certificate
is called name certificate. It uses holder’s name instead of the intended X.500 DN. As a result,
X.509 certificate namespace assumes global namespace in principle but in practice it uses local
namespace chosen by and unique to the issuing CA only.
PKIX [HPFS02] is a standard by IETF (Internet Engineering Task Force) to support X.509
compliant PKI on the Internet. Specifically, PKIX makes X.509 v.3 certificate (see Section 2.4)
suitable for the Internet. X.509 PKI is mainly composed of the following elements: CA, Reg-
istration Authority (RA), PKC holder, relying party, repository and PKC. These elements are
explained below.
2.2. PKI 9
1. RA: RA is an optional element of an X.509 PKI to which the CA delegates some of

its management activities [HPFS02]. RA mainly registers and verifies the authenticity of
individuals or devices identity identifiers upon certificate request.
2. PKC holders: PKC holder is an end-entity in the X.509 PKI which actually owns the
PKC. Holders are responsible to maintain the security of the corresponding private key
3. Relying Parties: Relying parties are the actual users and verifiers of a PKC. They verify
the validity of CA signature and the validity of the PKC itself.
4. Repositories: PKCs and CRLs are public information, through repositories which are
directories to store and distribute PKCs and CRLs, they become available for public use.
Repositories are occasionally X.500 directories, but mostly LDAP [BHR99] directories in
most implementations. HTTP and FTP also used [HH99] as a means of repository for
X.509 certificates and their CRLs.
5. PKC: PKC is the certificate itself, which contains the public key of the PKC holder plus
other holders’ identity identifier information and signed by the CA.
There are a number of reasons (see Section 2.4) which can potentially makes a PKC invalid
before its expiration date. Also, once a PKC gets published publicly it is practically impossible
to take it back, when it gets invalid. Announcement of its invalidity is the only way to avoid
misuse of a compromised PKC. As a result, X.509 compliant PKI uses CRL to announce pre-
viously published certificate should no longer consider as valid. The concept behind the use
of CRL comes from the analogy used in the early days of credit card hot-list. Hot-list was a
booklet which contains a list of stolen or revoked credit cards and periodically distributed to
merchants. Merchant in turn checks credit cards of buyers against those lists before committing
a transaction [P.G02] [HP01].
X.509 compliant PKI uses a similar trend, it publish the serial number of compromised cer-
tificates through CRL. A relying party has to fetch the CRL or instantly validate whether a
certificate is revoked or not before use. For X.509 compliant PKI a number of other certificate
revocation schemes are practiced widely (see Chapter four) as alternative to the traditional
CRLs.
In summary, X.509 compliant PKI is used to enable the basic security services of various widely
used protocols and applications. Some of them are; the first functional X.509 compliant PKI
are Privacy Enhanced Mail (PEM) [S.T93], Master card’s secure electronic bank card pay-
ments Secure Electronic Transaction (SET) [INC97], IETF standard for secure messaging Se-
cure/Multipurpose Internet Mail Extensions (S/MIME) [RAM99], secure access to web servers
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) [DA99] [DR06], for IP encryp-
tion Internet Protocol Security (IPsec) [KA98] etc.
2.2.2 PGP
PGP [ZIM95] provides a tool to generate, manage and revoke a PGP certificate1 within a local
environment. PGP uses holder’s common name and email address DNS2 instead of X.500 DN
as an identifier (e.g.common name, email). PGP implements a decentralized trust model where
each entity takes a role as a PGP certificate holder and at the same time as a CA. Generating
key pair and distributing a PGP certificate is done by the holder. Since signing each others
certificate is practicable, a PGP certificate can hold multiple signatures. For example, if Bob
is confident enough that he has the legitimate copy of Alice’s public key, he can sign Alice’s
PGP certificate and pass it to John. In this scenario, Bob serves as introducer of Alice PGP
certificate to John. Signing each others PGP certificate creates a trusted interconnected com-
munity of PGP certificate holders’. This PGP’s fault tolerance scheme is called web of trust. As
a result, in PGP there is no need for a centralized CA to sign PGP certificates. However, PGP
trust supported by public key servers, which is located in a known address on the Internet. The
key server is used to add and fetch named PGP certificates. However, posting PGP certificate
on a personal web page or any other means of self distribution is also supported.
Revocation of PGP certificate is necessary when a corresponding private key is compromised

(e.g. lost or stolen) before the certificate expiration date. PGP certificate revocation is made by
distributing a special kind of signed PGP certificate called key revocation certificate. The in-
dexKey revocation certificatekey revocation certificate has to be signed by the private key of the
compromised certificate. PGP advocates self-revocation scheme and revocation made without
the consent of those who certify it. As a result, holder has a responsibility to distribute the key
revocation certificate as wide as possible. Certificate revocation is the weakest link in PGP, since
there is no official way of distributing or fetching PGP certificate, there is no guarantee to tell
everyone at once that a PGP certificate is revoked. Self-distribution of revocation information
is practically sufficient for small groups or relying parties sometimes, but it is infeasible and
unreliable for a scalable PGP Certificate relying party community.
PGP Certificate v.6 introduced a concept of designated key revoker and it allows delegated
revocation by other parties’ in addition to the holder of the certificate [ACL+ 99]. Delegated
revocation is necessary, since the Key Revocation Certificate has to be signed by the correspond-
ing private key of a compromised PGP Certificate, if the holder lost its private key delegated
key revoker can do the revocation on the holders behalf.
PGP is mainly used as off-line electronic document authorship validation scheme. It is included
in major operating systems and predominately serve as email plug-in for email client applica-
tions, like Microsoft Outlook, Lotus Notes, Eudora etc.
1
A PGP certificate commonly referred as ‘PGP key ’instead of PGP certificate because PGP is key-centric
PKI. This thesis uses the term PGP certificate for consistency with other PKI certificates.
2
DNS is an acronym for Domain Name System, which is an Internet address in a mnemonic form.
2.2. PKI 11
2.2.3 SPKI/SDSI
SPKI is intended to avoid the complexity in PGP and X.509 to something simpler. According
to SPKI promoters, the assumption and use of global namespace introduce impracticality and
complexity in PGP and X.509 compliant PKI. As a result, SPKI tries to avoid this complexity
[ELL99] by introducing the concept of local namespace.
Global namespace has the intension of mapping ‘real names’Ṫhat name supposes to define in-
dividuals or other entities uniquely at a global scale. X.500 was intended to be a global DN
database server for X.509 but never been practical (see Section 2.2.1). SPKI promoters’ argued,
since a single global name source is not practically possible; names can not be unique globally.
The classical example of Ellison’s the ‘John Wilson problem’ ; illustrate why names can not
work as a unique identity identifiers [ELL02]. As a result associating names with public key on
a certificate can not create a unique identity globally. SPKI advocates the use of globally unique
public key or its cryptographic hash value as an identifier, instead of public key holder’s name
as used in the X.509 name PKC.
The original SPKI do not use names for certificate holders, but after the merger with SDSI (pro-
nounced as ‘Sudsy’ ) [RL96] name is included. SDSI introduce the concept of local namespace,
which is a name space defined by the relying party relative to a particular key instead of holder’s
name. Therefore, in SPKI/SDSI everyone can attach names to keys and that name is relative
to some holder, i.e. not unique globally.
The sources of the certificate name create a major difference between PGP, SPKI/SDSI and
X.509 compliant PKI. The holder of the certificate assigns the name for PGP certificates. In
the case of SPKI/SDSI the name is assigned by the relying party relative to a particular key.
For X.509 certificate, it is done by the CA [C.E05]. SPKI/SDSI advocate egalitarian approach,
meaning there is no need for global hierarchy. Every one is free to issue a certificate to oth-
ers. Anyone with access to a resource can authorize others by issuing a certificate to them and
manage their validity. In X.509 compliant PKI the issuer and the verifier of a certificate are
different. The revocation decision made by the issuer, but the risk is taken by the verifier. In
SPKI/SDSI the validation is done by the issuer of the certificate itself, therefore it is possible
to balance the risk by controlling the revocation decision [KOR02]. SPKI/SDSI has two types
of certificates name certificate and authorization certificate. Providing a flexible authorization
is the main purpose of SPKI/SDSI rather than authentication [ELL99].
SPKI/SDSI does not have a scheme for certificate revocation in the way X.509 PKI approached
public key certificate revocation. SPKI/SDSI promotes reasonably short validity period for cer-
tificates and the use of certificates of health instead of CRL. The main notion of SPKI/SDSI
promoters is “This certificate is good until the expiration date. Period.”[REV98] [BCDR02], i.e.
there is no certificate revocation. Showing certificate of health in SPKI/SDSI aims to prove a
certificate is not compromised so far.
SPKI/SDSI uses key compromise agent (KCA) or a suicide bureau (SB) to register holder public
key. Holder has to sign suicide note and protect it in a private place, i.e. as an escrowed copy.
When a key compromise occurs, holder has to send the suicide note to the SB. SB broadcast
the note to SB network, to make other SBs aware of the key compromise. However, holder can
ask SB for certificate of health if the key is not compromised yet. Presenting a recent certificate
of health with the certificate is enough for validation in SPKI/SDSI. However, a relying party
can demand a more recent certificate of health [REV98].
A conventional certificate revocation like CRL contains a black-list which lists the serial number
of all terminated certificates. On the other hand SPKI/SDSI uses a white-list, since certificate
of health tells a given certificate is not compromised so far, it can be considered as positive
certificate status information [BCDR02].
In general SPKI/SDSI does not get wide spread support as X.509 and PGP, although its notion
is implemented in HP’s eSpeak and various prototypes systems [C.E05].
2.3 PKC Revocation in Different PKIs

X.509 compliant PKI, PGP and SPKI/SDSI advocate different ways to provide certificate status
information. The following listing illustrates the differences that exist between these three PKIs
from the certificate revocation point of view.
1. A Certificate is Valid:
• X.509: An X.509 Certificate is valid until its expiration date if it is not revoked (or
suspended). In other words, it is probably valid and later revoked or expired.
• PGP: A PGP Certificate is valid until its expiration date if it is not revoked. A
PGP Certificate is probably valid and later revoked or expired.
• SPKI/SDSI: An SPKI/SDSI Certificate is valid until to a reasonably short expi-
ration date and until it has a recent valid certificate of health. In other words, an
SPKI/SDSI Certificate is definitely valid and later expired..
2. Distribution of PKC status information:
• X.509: In an X.509 PKI, CA publishes CRLs through an LDAP, FTP, or HTTP

• PGP: In PGP the holder itself has to communicate certificate revocation by dis-
tributing Key Revocation Certificate manually. There is no way to make sure everyone
gets the revocation information.
• SPKI/SDSI: Presenting a certificate of health on demand for certificate validation
is enough.
3. Content of PKC status information:
• X.509: X.509 PKI uses negative certificate status information which states a given
certificate can not be considered as valid any more.
2.3. PKC REVOCATION IN DIFFERENT PKIS 13
• PGP: PGP uses a Key Revocation Certificate, which is a signed version of the
compromised PGP certificate to inform relying parties that a certificate can no longer
be considered as valid any more.
• SPKI/SDSI: SPKI/SDSI advocate the use of positive certificate status information,
i.e. Certificate of Health, which inform a relying party a given certificate can be used
as valid and never been compromised so far.
4. PKC revocation mechanisms used:
• X.509: X.509 PKI mainly uses CRL, and OCSP PKC revocation schemes to com-
municate certificate revocation information. However, there are alternative revocation
schemes (see Chapter 4).
• PGP: Unfortunately, PGP does not specify any revocation scheme (protocol), it
relies on any kind of user defined manual PKC revocation announcements like: posting
on personal webpage, add to key server or send it by email, etc to a targeted relying
party.
• SPKI/SDSI: SPKI/SDSI does not have a scheme for PKC revocation, since it
totally eliminate PKC revocation from its PKC management. However, it uses SB
networks, Certificate of Health and Suicide Note to render positive PKC health status
information to relying parties.
5. PKC revocation commenced by:
• X.509: In X.509 PKI only a CA can publish CRL for a compromised PKC.
• PGP: In PGP PKI delegated revocation is practiced, since in addition to the holder
a trusted designated revoker can also revoke a compromised certificate.
• SPKI/SDSI: In SPKI/SDSI the holder of a compromised certificate sends a suicide
note to the SB network and SB stops issuing certificate of health for the compromised
certificate. According to SPKI/SDSI a certificate without a recent valid certificate of
health considered as invalid.
It is clear that the three different PKIs advocate a different approach when it comes to certificate
revocation or termination. X.509 complaint PKI shows a centralized authoritative kind of revo-
cation in which the CA centrally manages the revocation alone. Distributed type of revocation
is practiced in PGP because delegated revocation can be done by a trusted revoker in addition
to the certificate holder. Cooperation of a SB and a holder is a must to terminate a certificate
from use in SPKI/SDSI, which exhibit some kind of collaborative revocation approach.
The emergence of alternative PKIs and varied PKC revocation approaches in addition to the
original X.509 PKI is mainly to address the existed security deficiencies in an X.509 PKI. PGP
PKI is designed to mitigate the X.509 top-down dictatorial trust relationship into a grass-root
referral trust relationship known as PGP Web of Trust. In X.509 PKI approach a single CA
certify PKC by signing, whereas a PGP Certificate is signed by multiple PGP network peers.
As a result, in the case of X.509 an attacker have a single clear point of attack, which is the
CA private key. However, in PGP the same attacker need to attack different multiple signers
of a single PGP Certificate and there is no place for a single point of failure. The unattainable
preposition of a through X.500 DN is the main reason for the development of SPKI/SDSI PKI.
From the perspective of PKC revocation distribution, an X.509 PKI uses a centralized approach
in which the CA centrally distributes PKC revocation information; which againcreates a single
point of attack. Due to its self revocation approach, PGP PKI does not have a reliable, stan-
dardized and uniform PKC revocation information distribution mechanism. In general PGP
PKI has availability problem form PKC and Key Revocation Certificate distribution point of
view. SPKI/SDSI PKI on the other hand totally dismisses the concept of certificate revoca-
tion. However, PKC status information is provided indirectly, since inexistence of Certificate
of Health for an SPKI/SDSI Certificate indirectly tells the relying party that the certificate is
compromised in one way or another.
2.4 X.509 Certificate and CRL Format

In simple words, X.509 certificate is a digital certificate which officially notarizes the association
of a particular holder identity identifiers and a public key. The name X.509 comes from the 1988
CCITT X.509 [CCI88] recommendation which specifies the authentication framework for X.500
directory. Formerly the X.509 was used to enable a strong authentication to access and modify
X.500 directory.
X.509 v1 certificate created to bind public keys with an X.500 DN. Through time the approach
changes from providing a strong authentication for X.500 to a general purpose PKI. As a result
X.509 v2 certificate is introduced to address the reuse of names and later X.509 v3 introduce
the concept of optional certificate extensions. Certificate extensions in X.509 v3 create a means
to add additional information in addition to the basic certificate fields in X.509 v3 certificate
[HP01]. X.509 v3 certificate support the use of local names and acknowledge the impracticality
of assuming a global namespace (see Section 2.2.3) [BRA00]. Whereas, X.509 v1 and X.509 v2
certificates assumes DN from the X.500 directory global namespace.
An X.509 v3 certificate is composed of three nested components, which is tamper evident enve-
lope, basic certificate content and certificate extension [HP01]. The outermost part, the tamper
evident envelop, contains three fields: tbsCertificate, signatureAlgorithm and signatureValue.
Signature algorithm (signatureAlgorithm) field tells the algorithm used to sign the certificate
and signature value (signatureValue) contains the actual digital signature.
Basic certificate content of X.509 v3 certificate contains a number of fields as shown in Table 2.1.
When a certificate do not include issuerUniqueID and subjectUniqueID field (which intended
to handle reuse of holder name and issuer name in X.509 v2 and X.509 v3) then it is X.509
v1 certificate. When a certificate contains issuerUniqueID and subjectUniqueID but not have
extensions field it is X.509 v2 certificate. When a certificate has an extensions field it is definitely
2.4. X.509 CERTIFICATE AND CRL FORMAT 15
X.509 v3 certificate. Serial number (serialNumber) filed is a unique serial number intended to
uniquely identify each certificate which is generated inside a given CA certificates. The validity
field contains two parts: notBefore and notAfter. The field not before (notBefore) indicates
date-time on which a certificate becomes valid. The not after field (notAfter ) tells the planned
date-time on which a certificate expires. PKC validity date-time field plays a key role in the
validation of PKC.
X.509 v1 CRL was the first version of CRL which was used with X.509 v1 and X.509 v2 cer-
tificates. Scalability concerns, functionality problems (like inability accommodating additional
extensions when needed) and CRL substitution attack makes X.509 v1 CRL obsolete [AL02].
X.509 v2 CRL is used with X.509 v3 certificate. When extension field is included it is easy
to tell the version of the CRL is X.509 v2 CRL. thisUpdate and nextUpdate fields are used to
specify the validity date-time range of a CRL. thisUpdate indicates the issue date of the current
CRL and nextUpdate tells when the next CRL update will be released. Table 2.1 illustrates the
differences between the three versions of X.509 certificate fields and the two CRL version fields.
Note that, X.509 v1 and v2 certificates use X.509 v1 CRL.
A number of CRL extensions fields defined by the ITU-T and ANSI X9 for X.509 v2 CRL.
Some of them are AuthorityKeyIdentifier, IssuerAltName, CRLNumber, deltaCRLIndicator, is-
suingDistributionPoint, FreshestCRL, CRLReason, etc [HP01]. Among these X.509 v2 CRL
extensions CRLReason is used to identify the reason why certificate revocation was carried out.
X.509 v2 CRL reason code includes keyCompromise (key compromise), cACompromise (CA
compromise), affiliationChanged (affiliation change), superseded, cessationOfOperation (cessa-
tion of operation), certificateHold (certificate hold), removeFromCRL (remove from CRL), priv-
ilegeWithdrawn (privilege withdrawn), aACompromise (for attribute certificates) and unspecified
[HPFS02] [AL02]. Cessation of operation reason code represents revocation reason where a cer-
tificate is no longer needed for its original purpose. Affiliation change occurs when information in
the certificate about the holder of the certificate is no longer valid, due to employee resignation,
promotion or any other possible reasons. [COO98] illustrates how an attacker can manipulate
reason codes to create an attack and how reason codes can be classified into malicious and non-
malicious classes.
[WOH00] describes another set of possible revocation reasons in addition to X.509 v2 CRL stan-
dard reason codes. Wohlmacher additional reasons includes signature algorithm compromise,
revocation of superordinated certificate, loss of security token or password (PIN), key usage
change and finally security policy change. Archiving of compromised PKC is necessary after
they expired or revoked in order to enable signature verification on their past use at a future
date [BCF+ 94]. Figure 2.1 illustrates the life cycle of X.509 certificate and X.509 CRL. The
cycles particularly related with the certificate revocation activities circles around three players in
an X.509 compliant PKI [ISKP00]. The three players are: the relying party which is the verifier,
certificate status information (CSI) provider which is the CA and revocation requester which is
the holder. The relying party is a dependent entity on the provider of the CSI provider, i.e. the
CA. The provider of the CSI performs the following three certificate revocation management
X.509 v1 Certificate X.509 v2 Certificate X.509 v3 Certificate

1st ed. 2nd ed. 1994 3rd/4th ed. 1997/2000
version version version
serialNumber serialNumber serialNumber
signature signature signature
Issuer Issuer Issuer
Validity Validity Validity
Subject Subject Subject
subjectPublicKeyInfo subjectPublicKeyInfo subjectPublicKeyInfo
- subjectPublicKeyInfo subjectPublicKeyInfo
- issuerUniqueIdentifier issuerUniqueIdentifier
- subjectUniqueIdentifier subjectUniqueIdentifier
- - extensions
X.509 v1 CRL X.509 v2 CRL
Version Version
Signature Signature
Issuer Issuer
thisUpdate thisUpdate
nextUpdate nextUpdate
revokedCertificates revokedCertificates
- crlEntryExtensions
- crlExtensions
Table 2.1: X.509 Certificate and CRL Fields

2.4. X.509 CERTIFICATE AND CRL FORMAT 17
operations.
1. Identification: a CA validates certificate revocation requests.
2. Generation: CA generation of certificate revocation information, i.e. CRLs.
3. Storing: CA stores certificate revocation information, i.e. repository of CRLs On the

other end the dependent entity which is the relying party has to perform the following
operations before using X.509 certificate.
On the other hand a relying party of a given CSI performs the following three certificate revo-
cation management operations
1. Locating: a relying party has to identify the location of or the scheme used to locate the
available certificate revocation information
2. Retrieval: a relying party has to retrieve the certificate revocation information, i.e. CRLs.
3. Validation: a relying party has to verify against the retrieved certificate revocation in-
formation before using an X.509 certificate.
Figure 2.1: X.509 Certificate and CRL life Cycle
Finally, if the certificate is in a revoked state upon validation the relying party can not use it
even if the certificate is not expired yet.
2.5 X.509 PKC Revocation Synopsis

X.509 certificate uses a CRL as a means of communicating PKC. The idea of using CRL comes
from the idea of black-lists of the credit card companies in the late 1970s. The same problem
the credit card companies’ faces in those days become today’s X.509 CRLs problem [P.G02]
[HP01]. The problem mainly comes from the difficulty of real time distribution of CRL and the
associated high cost. In practice, conventional CRL distribution is not frequent enough to be
effective in mitigating the possible attack which can come from a compromised certificate. Also
distributing and maintaining them is highly expensive.
A study by MITRE/NIST clearly shows that the cost of certificate revocation administration
is the major running cost of an X.509 compliant PKI compared to other costs. It is mainly
derived from CRL communication cost. [BCF+ 94]. Since the yearly expense of an authenti-
cation infrastructure mainly derived from managing certificate revocation, understanding and
balancing the expense, risk and security of PKC revocation is an important business concern.
From the system risk management point of view, a revoked certificate is more suspected in in-
troducing threat to the system than expired certificate, because of the high risk associated with
its compromised key. Therefore, an efficient and versatil certificate revocation management is
very important to reduce the associated cost, to ensure the authentication system security and
balance the underlined risk.
Chapter 3
Classification & Evaluation Metrics
This chapter explains classification of existing X.509 compliant certificate revocation schemes
from different perspectives. Selected PKC revocation schemes evaluation metrics are also dis-
cussed in detail. Both the classification and evaluation metrics included in this chapter is aimed
to create a consistent framework of evaluation for chapter four, where the actual evaluation of
each selected revocation schemes takes place.
3.1 Classification of X.509 Certificate Revocation Schemes

Classifying PKC revocation schemes helps to facilitate the evaluation process by avoiding re-
dundant evaluation engagement. In practice, PKC revocation schemes classification metrics can
be factored from different independent perspectives. As a result, different researchers follow
different classification approaches. The following part describes how researchers classify PKC
revocation schemes from different perspective.
[MYE98] classifies certificate revocation schemes into four categories: (1) CRL, (2) OCSP, (3)
Trusted Directory and (4) Short-Lived certificates. Mayer classification approach takes scope of
revocation scheme operations as a metrics for classification (see Section 3.2.3). [ZHE03] classify
revocation schemes into three different classes: (1) List Based Schemes, (2) Tree based schemes
and (3) Verifier Transparent Schemes. Zheng classification metrics focus on the architectural
design differences of the existing PKC revocation scheme. [IGS+ 03] classify PKC revocation
schemes into three based on the CSI response they provide. The three classes are (1) negative
CSI, (2) positive CSI and (3) Full CSI, i.e. revocation schemes which present both negative
and positive CSI (see Section 2.2.3 and 2.2.4). Other related classification approaches are also
discussed frequently in different literatures. Based on the orientation used to validate CSI, PKC
revocation scheme can be classified into two: (1) online and (2) off-line. Revocation schemes
classified into two based on the type of CSI evidence they provide: (1) direct and (2) indirect.
[REV98] argue against the use of negative CSI and suggested complete avoidance of CRLs from
certificate revocation system. He proposes the use of positive CSI or certificate of health (see
19
20 CHAPTER 3. CLASSIFICATION & EVALUATION METRICS
Section 2.2.3). Since their CSI statement is incomplete, both Rivest positive CSI and traditional
CRL’s negative CSI classified as indirect CSI evidences. However, direct CSI oriented PKC re-
vocation schemes provide a complete certificate status statement, i.e. they present both positive
CSI and negative CSI statements upon CSI validation request.
PKC revocation schemes can also be classified into: (1) push and (2) pull, based on the CSI
distribution method they use. In the case of push approach the provider (CA) of PKC revo-
cation information periodically update the relying party CSI catch. However, in pull oriented
revocation schemes the relying party itself has to fetch periodically the certificate revocation
information CSI from the provider (CA). [MAC03] classify certificate revocation schemes into
three classes: (1) periodic publication methods, (2) online query schemes and (3) hybrid schemes.
MacMichael’s classification takes PKC CSI freshness as a main criterion to classify PKC revoca-
tion schemes (see Section 3.2.4). [HOP01] [WIL99] labels partitioned CRL schemes as ‘improve-
ment to CRL’ and others like OCSP and CRT with a name ‘a complete departure from CRL’Ṫhe
phrase ‘complete departure from CRL’ is used to elaborate the architectural differences that
exist between CRL based and OCSP related revocation scheme families. Figure 3.1 summarizes
Figure 3.1: Existing Perspectives on Classifying Certificate Revocation Schemes
the different classification approaches of PKC revocation schemes explained so far. The figure
is intended to show how classification of revocation schemes addressed differently by different
researchers.
3.1. CLASSIFICATION OF X.509 CERTIFICATE REVOCATION SCHEMES 21
A PKC CSI validation can be done in an online or off-line manner. Online validation is suitable
for mission critical online transactions, which demand a real-time CSI validation all the time.
Online revocation schemes update CSI in real-time and instantly distribute them via online
trusted directory [WOH00]. off-line revocation schemes, on the other hand, update their CSI
periodically (monthly, yearly, etc). In the case of off-line revocation schemes, the revocation in-
formation is pre-computed by the CA and distributed via un-trusted directories. Unlike online
PKC revocation schemes, off-line certificate revocation schemes are not dependent on trusted
directories. Since, the integrity of the CSI can be assured by verifying the signature of the
CA [FP00] [NN00]. Online PKC revocation schemes require signing of each validation request
response in every certificate validation request transaction. Signing each validation request
transaction is highly costly operation which requires high bandwidth and excessive computa-
tional resources [BH98] [Koc98].
Mobile computing and ad-hoc networks in general characterized by independent computing units,
No Class Revocation Scheme Name

1. CRL Traditional CRL
2. Partitioned CRL
3. Segmented Dynamic CRL Distribution Points
4. CRLs Redirect CRL
5. Delta CRL
6. Indirect CRL
7. Over-Issued CRL
8. CRL Windowed Key Revocation
9. Variants Black-list CRL
10. Freshest CRL
11. Hybrid Over-Issued Segmented CRL
12. CRL Over-Issued Delta CRL
13. Variants Over-Issuing Delta CRL with Distribution Points
14. Sliding Window Delta CRL (SWD CRL)
15. Online Certificate Status Protocol (OCSP)
16. OCSP Variant Distributed OCSP
17. Certificate Revocation Status (CRS)
18. CRS Variant NOVOMODO
19. non-CRL Certificate Revocation Tree (CRT)
20. Semi-Trusted Mediator (SEM)
21. Trusted Directories
Table 3.1: Selected Certificate Revocation Schemes Classification
decoupled computing style, frequent disconnection and frequent location changes [RMP97]. As a
result, an off-line revocation scheme becomes the best revocation solution for mobile computing
and ad-hoc networks in general. In any application where connection to global Internet can not
maintained always, CSI validation scheme must not be dependent always on an outside resources
[MM03a], like OCSP responder (see Section 4.15). To maintain simplicity, in this thesis revoca-
tion schemes classified into four general classes by taking traditional CRL as a reference point
for classification. (1) Traditional CRL PKC revocation schemes: includes the original X.509
CRL. (2) Variant CRL PKC revocation schemes: includes PKC revocation schemes designed
based on the Traditional CRL concept with some sort of improvement to it. (3) Non-CRL PKC
revocation schemes: includes schemes which completely follow a different design in comparison
with the Traditional CRL. (4) Hybrid PKC revocation schemes: includes schemes which made
up by mixing two or more schemes. In this thesis, classification metrics like online vs. off-line,
positive CSI vs. negative CSI and direct CSI vs. indirect CSI are considered as architectural
evaluation metrics than classification metrics (see Section 3.2.1).
There exist a number of standardized and proprietary certificate revocation schemes in practice
and in literatures. It is difficult to include them all, thus only standardized, well publicized, or
practiced certificate revocation schemes are selected. Table 3.1 contains name lists of selected
revocation schemes in this thesis for evaluation and integration. It is common to find a single re-
vocation scheme in different publications with different names. For example, ‘Partitioned CRL’
known alternatively as ‘Segmented CRL’ or ‘Distribution Point CRL’ in addition to its name,
i.e. Partitioned CRL. Regardless of the existence of different ambiguous naming preferences
by different researchers, this thesis uses a consistent naming style. However, Appendix A lists
alternatively used names for readers’ easy reference.
3.2 PKC Revocation Evaluation Metrics

This section list out eight selected PKC revocation schemes evaluation matrices. These eval-
uation matrices mainly formulated to investigate the unique contribution of the selected PKC
schemes (see Table 3.1). Each evaluation matrices are discussed as concisely as possible, so that
the rest of the thesis (especially chapter four ) relay on them and minimize redundant expressions.
3.2.1 Design Evaluation Metrics

Design evaluation compares the pros and cons of the existing PKC revocation schemes archi-
tectural approach. It is further classified into six sub-metrics: complexity, standardization,
connectivity, and CSI evidence.
Complexity
[BIS02] in his ‘Economy of Scheme’ design principle suggests that security schemes should be
as simple as possible. [GW03] also argue that the essence of security engineering must be aimed
toward building as simple schemes as possible. Simple systems are easy to design, implement,
test and use. Complex systems by their nature introduce insecurity, since their complexity
mostly depends on uncertain (unclear) assumptions. When that assumption does not meet; the
whole security of the system fails apart so easily. On the other hand, creating hybrid PKC
3.2. PKC REVOCATION EVALUATION METRICS 23
revocation schemes out of the existing schemes can be a source of complexity. For example PKC
revocation schemes like ‘Over-Issuing Delta CRL with Distribution Points’ (see Section 4.13) are
definitely more complex than the individual Over-Issued CRL (see Section 4.7), Delta CRL (see
Section 4.5) and Partitioned CRL (see Section 4.2) which construct the hybrid scheme. A PKC
revocation scheme architectural complexity graded as Simple or Complex. Simple revocation
schemes like Traditional CRL (see Section 4.1) grouped under simple category. Complex schemes
like NOVOMODO (see Section 4.18) grouped under complex category.
Proposition 1 A secure PKC revocation scheme architectural complexity

must be as simple as possible.
Connectivity
Online revocation schemes are preferable for mission critical online transaction which needs
real time revocation information. While, off-line PKC revocation schemes are suitable, in an
environment where a consistent Internet connectivity can not be maintained always (see Section
3.1). Connectivity graded as Online, off-line, or Both, both indicates PKC revocation schemes
which uses both online and off-line connectivity for PKC revocation validation.
Proposition 2 A versatile PKC revocation scheme has to be engineered

to work both in an off-line and online connectivity orien-
tation.
Standardization
Standardized PKC revocation schemes in general have to pass through intensive testing and
review by a standardization body. As a result, mostly they are generic, readily available and
interoperable with other schemes. However, proprietary schemes did not pass through any formal
standardization processes; they might come into sight with probable glitches, compatibility and
interoperability problems.
CSI Evidence
Revocation schemes which advocate direct evidence approach are favorable over indirect one.
Since neither positive CSI nor negative CSI oriented PKC revocation schemes give a complete
validation request response. CSI Evidence evaluation graded as Negative, Positive or Full
CSI (see Section 3.1).
Proposition 3 A preferable revocation scheme has to provide discrete,

unambiguous and complete CSI evidence.
3.2.2 Performance Evaluation Metrics
The performance of a PKC revocation scheme greatly determined by two factors: one is its abil-
ity to timely generate the CSI and the other is how frequent the generated CSI can be published.
Timely generation and frequent the distribution of CSI is good to attain better performance.
As discussed in detail in the next chapter (see Chapter 4) only few revocation schemes specify
a mechanism to handle generation of CSI. However the majority of the selected PKC schemes,
setup a mechanism to make a frequent CSI publication as much as possible. Only with frequent
CSI publication freshens of CSI can be maintained.
On the other hand, periodic CSI publication creates a bottleneck problem, which greatly af-
fects the performance of the PKC revocation service and availability of the CSI. Bottleneck is
a problem of exhaustive network resource usage because of a peak request rate for CSI update.
It happens, whenever a new CSI is available in a periodic manner. The problem of availability
is better classified as security metrics; since unavailability is a one way to exploit established
security policies (see Section 3.sec). The following table summarize the tradeoffs existed be-
tween CSI generation, CSI distribution, bottleneck, and availability. A revocation scheme with
CSI generation/distribution CSI Availability Bottleneck

Periodicity Periodicity (Network Usage)
Longer longer High
Shorter Shorter Average (minimal)
Real time None None
Table 3.2: Perfomance Constraints Tradeoffs
real-time CSI availability and no bottleneck at all, can be realized in an online and push oriented
revocation scheme may be with self revocation (like PGP ) and efficient push CSI distribution
functionality. Performance Evaluation Metrics further classified into three sub-metrics: Time-
liness, Freshness and Bottleneck.
Proposition 4 PKC revocation scheme performance evaluation is a mea-

surement of the amount of time required to generate CSI,
distribute CSI and fetch that CSI.
Timeliness
It is the maximum amount of time needed from certificate compromise until its revocation
information (CSI) made available. Timeliness grades as Unclear, Real-Time, Long and Short.
Most revocation schemes do not give a mechanism to handle timeliness, in such circumstance
unclear is used as a grad for the evaluation.
Proposition 5 Timely generation of CSI upon certificate compromise re-

duces the risk associated with the misuse of a compro-
mised PKC.
Freshness
Freshness measures the length of time (elapsed time) between the most recent CSI update time
and the current time of CSI validation request. A freshest CSI can be obtained, when the
elapsed time between the most recent CSI update time and current CSI validation request time
becomes shorter. Note that: CSI freshness is not an always desirable performance improvement
requirement. There exist relying parties which do not need the freshest CSI. For them getting
the freshest CSI is unnecessarily wasting computational and communication resources and CSI
update costs. Freshness here graded as Low, Fair and High.
Proposition 6 Freshness is not an all-time requirement for a versatile

PKC revocation scheme due to its additional expenses.
Bottleneck
Especially on periodic and off-line-oriented PKC revocation schemes peak CSI validation request
happen temporarily every time a new CSI update is made available and drops later. Also in
an online and/or non-periodic PKC revocation schemes a peak update request rate can happen,
due to an increase in validation request at some point in time. The difference is in off-line and/or
periodic PKC revocation scheme the bottleneck itself is periodic in parallel with the periodic
update time, whereas it is non-uniform in online and/or non-periodic PKC revocation schemes.
Bottleneck here graded as Low, Fair and High.
Proposition 7 Bottleneck in a PKC revocation scheme can only be min-

imized, in other words it can not be totally avoided.
3.2.3 Implementation Evaluation Metrics
From the implementation perspective, dealing with the ever increasing PKC holders’ and relying
parties’ population size over time is very important. A PKC revocation scheme has to be designed
in a way that it can survive with PKI population size increase, decrease, or any irregularity in
the population size. On the other hand, some PKC revocation schemes designed to function
only with specific type of computational environment or application, they come with a limited
scope of operation. As a result their implementation becomes restricted in certain environments
only. Implementation consideration classified into two sub-metrics: Scalability and Scope.
Scalability
Scalability is the most discussed evaluation criteria in certificate revocation literatures by far.
A scalable revocation scheme, by definition, has to scale along with the number of relying
parties, certificate holders and/or PKI authorities (CAs and RAs) increases over time [IGS+ 03].
A scalable PKC revocation scheme is also the one on which the cost of its CSI computation,
communication, update and management scales less when the number of PKC holder and relying
party population size grows over time. Scalability is an insurance policy for a PKC revocation
scheme, since an increase in the number of certificate holders’ and relying parties’ population
size is a common phenomenon over time.Scalability here graded as Low, Fair and High.
Proposition 8 Scalability can only be managed, in other words it can not

be totally avoided.
Scope
The operational scope of a PKC revocation scheme can be specific or versatile. PKC revocation
schemes with specific application works only in certain environments. For example, Trusted
Directories PKC revocation scheme works only inside a corporate intranet network (see Section
4.22). On the other hand, PKC revocation schemes with versatile approach can work with a
wide range of environments and other PKC revocation schemes. Scope of a PKC revocation
scheme operation graded here as Restricted or Versatile.
3.2.4 Windows of Vulnerability

Windows of vulnerability represent the amount of time required for a relying party to get CSI
of currently compromised PKC. In most cases, it is the sum amount of time needed to generate
CSI and distribute CSI. If can also include factor like the mechanism used to communicate PKC
compromise by the holder of the PKC and performance.
Proposition 9 In reality the windows of vulnerability is greater than the

one mentioned in any PKC revocation scheme design spec-
ification, because of other factors, like bottleneck, which
hinder user from getting the CSI as intended.
3.2.5 Unique Contribution

As the main goal of this thesis aimed toward proving whether a single versatile revocation
scheme is possible or not out of the existing schemes. Properly identifying every possible unique
contribution of each PKC revocation scheme is important. The unique contribution section does
serve this purpose.
3.2.6 Resource Evaluation Metrics

Communication, computational and storage resources are costly, especially when they combined
with the scalability nature of PKI. Resource usage evaluation further classified into three sub-
metrics: network usages, Revocation information and CSI-cache-size
Network Usage
An increase in network usage can occur due to various reasons, large CSI validation message,
PKC revocation scheme architectural inefficiency, high periodicity of CSI distribution, extensive
cryptography etc. Inefficient and complex PKC revocation scheme can demand a great deal of
network resources to provide PKC validation. In off-line oriented PKC revocation schemes net-
work usage temporarily increases, every time a new CSI update is made available. In comparison
online oriented PKC revocation schemes network usage is high, since they don’t use cached CSI
for later validation like off-line oriented schemes. Network Usage here graded as Low, Fair and
High.
Revocation Information
A given PKC revocation scheme revocation information (or CSI) can be full, partitioned or
constant. PKC revocation schemes which provide full revocation information force relying party
to fetch all the available CSI without any filtering or partitioning, as Traditional CRL (see
section 4.1) does. Whereas, partitioned CRLs let the user to fetch only relevant portion of the
full CSI as Partition CRL (see section 4.1) does. On the other hand, most real-time online
PKC revocation schemes let the relying party to fetch only the CSI of a single PKC on the
validation. From the resource usage point of view, full PKC revocation information needs more
communication and computational resources than partitioned or constant ones. As a result
revocation information here graded as Full, Partitioned, or Constant.
CSI-Cache-Size
off-line oriented PKC revocation schemes uses CSI catch repository, on the relying party machine
for off-line CSI validation. The catch repository content is updated every time a new CSI update
is made available. However, online oriented PKC revocation schemes do not require CSI catch
repository on the relying party machine. Over time, as PKI scales the number of revoked PKC
also increases. PKC revocation schemes which uses distribute full revocation information and
off-line oriented require large CSI-cache. CSI-cache-size here classified in to Small, Medium,
Large and Null. Null is used for PKC revocation schemes which does not need a cached CSI at
all, like most online PKC revocation schemes.
3.2.7 Cost Evaluation Metrics

As discussed in section 2.4 the biggest PKI running cost comes from certificate revocation in
general and CSI update computation and communication cost in particular. Cost related aspects
of a PKC revocation mechanism can be divided into service provider (CA) side and relying
party side costs. CSI generation, CSI Distribution and over all revocation handling requires
computational, communication and management costs respectively, that needs to be covered by
the PKC revocation service provider. On the other hand, CSI update cost is covered by the
relying party. Cost evaluation metrics here further classified into Communication, Computation,
Management and Update Costs.
Proposition 10 Economically feasible PKC revocation scheme CSI gener-

ation, CSI distribution and CSI update must be managed,
computed and communicated in a cost effective manner.
Communication Cost
Communication cost includes infrastructural and associated network centric costs. In general, it
increases when a revocation scheme becomes highly dependent on the communication channel.
Communication Cost here graded as Low, Fair and High.
Proposition 11 PKC revocation scheme engineered to provide the fresh-

est possible CSI, architecturally complex schemes and
schemes with full revocation information in general in-
troduces high communication cost.
Computation Cost
In general, revocation schemes with high complexity or with intensive cryptographic operation
requires high computational resources. In some circumstances, computational costs are intro-
duced because of repetitive operations. Fore example, signing each and every validation request
response in OCSP [MAM+ 99]. Computation Cost here graded as Low, Fair and High.
Management Cost
Management cost of a PKC revocation scheme escalate when the scheme implements compu-
tationally and architecturally complex scheme. In contrast with centralized schemes, a PKC
revocation scheme which implements distributed approach requires relatively high management
costs. Management Cost here graded as Low, Fair and High.
CSI Update Cost
CSI update cost is need mostly by off-line oriented PKC revocation schemes. It is the cost
associated with CSI fetching when they become available (periodically) to update the local CSI
cache on the relying party machine. CSI Update cost is further graded as Low, Fair, High and
Null. Null is used for online oriented PKC revocation schemes which does not need a CSI update
or have a CSI cache.
3.2.8 Security Evaluation Metrics

Secure PKC revocation scheme has to avoid unauthorized CSI generation, unauthorized CSI
distribution manipulation (CSI modification, tampering or removal) and at the same time make
CSI readily available for the relying party. These security requirements of a PKC revocation
scheme can be generalized under CSI availability and CSI integrity security services. Since
avoiding unauthorized CSI generation and unauthorized CSI distribution manipulation can be
mitigated by integrity security service.
CSI Integrity
The integrity of PKC CSI must be protected when it is inside the provider (CA) repository, in
transit and inside the relying party CSI catch repository [IGS+ 03]. Verifying the validity of the
CA signature is sufficed to validate the integrity of a given CSI.
CSI Availability
In any PKI, a PKC revocation service must be reliably available all the time no matter what.
It must be available even if certain part of the PKI or PKC revocation service fails or attacked.
Without a reliable CSI availability, revocation scheme can be interrupted easily with Denial of
Service (DOS) attack or other related attacks. Performance degradations like network usage
bottleneck also introduced temporary delay in the availability of CSI. Proposition 15: The more
a reliable a PKC revocation scheme becomes, the more available it can be even with network
malfunction or attack.
Proposition 12 The more a reliable a PKC revocation scheme becomes,

the more available it can be, even with network malfunc-
tion or other attacks.
Chapter 4
PKC Revocation Schemes Evaluation
This chapter provides a concise functional explanation for the selected revocation schemes (see
Table 3.2). Evaluation of each revocation schemes based on a consistent metrics follows the
explanation. As a concluding remark, each schemes unique contribution and their functional
tradeoffs is justified. However, explanation of common functionalities shared by two or more
schemes is kept minimal and evaluation grades like ‘complex ’, ‘fair ’, ‘simple’, etc may not be
clarified in this chapter (see Chapter Three).
4.1 Traditional CRL

Traditional CRL [IT97] is the most widely used implementation of the original concept of X.509,
which publishes a signed and time stamped list of revoked PKCs called Certificate Revocation
List (CRLs). The list contains the serial number of revoked PKCs, the date that CRL issued
and the date the next CRL update planed to be issued. The next CRL update date latency
varies among applications; it is dependent on the CA policy and the sensitivity of the PKC.
Traditional CRL revocatin information contains full CRL (see Section 3.2.6).
Traditional CRL Tradeoffs
Traditional CRL has several shortcomings; its periodicity is the ultimate source for all the other
shortcomings. First, periodicity by its nature introduces risk of mistrust until the next update.
With a constant periodic CRL update, whenever a new CRL update made available, update
request rate gets peak and become negligible after. This fluctuation makes the scheme to use the
communication resource extensively at one point in time and briefly for another longer period.
To improve performance (avoid bottleneck) a bigger bandwidth can be used, however it is costly
and a waste of money since the requirement is temporary. Also with the increase of PKC holders,
the probability of having revoked PKC increases, which means a bigger CRL message size need
to be fetched at once.
30
4.2. PARTITIONED CRL 31
1. Design: 6. Resource:
Complexity Simple Network usage High
Connectivity off-line Revocation info Full
Standardized Yes CSI-cache-size Large
CSI evidence Negative 7. Cost:
2. Performance: Communication High
Timeliness Unclear Computation High
Freshness Low Management Low
Bottleneck High CSI update High
3. Implementation: 8. Security:
Scalability Low CSI integrity Signature
Scope Normal CSI availability Low
4. Windows of Vulnerability:
equals the periodicity of CRL publication
5. Unique Contribution:
None
Table 4.1: Evaluation of Traditional
According to [Koc98] sometimes the size of CRL needed to validate an S/MIME message over
sized of the message itself. [NH05] explains, how state Department of Defense (DoD) CRL size
grows over time, i.e. the CRL message size approached 40 MB in 2005. Therefore, traditional
CRL periodicity causes a chain of problems like low performance, high cost and low scalability.
Despite its simplicity, its problem outweighed. As a result researchers start looking for other
alternative revocation schemes and now there are a number of other alternative schemes. Even
with the existence of better revocation schemes, Traditional CRL still used widely, why?
Formal Analysis of Traditional CRL
From secure design perspective (preposition 1) Traditional CRL simplicity is the major advan-
tage of the scheme. However, the scheme needs a considerable adjustment when it is evaluated
under the rest of the evaluation metrics. Performance can be a good example for that, since
Traditional CRL does not specify a mechanism for timelines of its CSI generation (preposition
4), its CSI freshness is too low (it is periodic) and it has high risk (preposition 5). Also its full
CRL can increase the CSI size, which potentially can be a source of network bottleneck and
high cost (preposition 11).
4.2 Partitioned CRL

Partitioned CRL [OFHJ97] is specified in X.509 v2 CRL (see Section 2.3) and it is a distributed
variant of Traditional CRL. It divides Full CRL into smaller segments and makes them avail-
able from different distribution points. ‘CRLDistributionPoints ’extension on the PKC is used
32 CHAPTER 4. PKC REVOCATION SCHEMES EVALUATION
to tell the CRL distribution point, CRLReason code and issuer of the CRL. The criteria for
segmentation can be varied; it is possible to divide CRLs based on their serial number or CRL-
Reason code (see Section 2.3). CRLs can be segmented based on their CRLReason code into
those revoked because of key compromise (e.g. keyCompromise, cACompromise, etc) and those
routinely revoked (e.g. affiliationChanged, cessationOfOperation, etc). However, the main idea
behind Partitioned CRL is to prevent CRL from growing into unmanageable size.
Complexity Simple Network usage Low
Connectivity off-line Revocation info Partitioned
Standardized Yes CSI-cache-size Small
2. Performance: Communication Fair
Timeliness Unclear Computation Low
Freshness Low Management High
Bottleneck Low CSI update Low
Scalability Fair CSI integrity Signature
Scope Normal CSI availability Low
CRL Segmentation
Table 4.2: Evaluation of Partitioned
Partitioned CRL Tradeoffs
The introduction of partitioning CRL enables to reduce the size of CRL message which needs to
be updated at once. So that it minimize peak CRL update request rate (bottleneck) by making
update featching faster and distribute them over different segments. Different partitions can
also implement different periodicity to publish a new CRL update, to minimize peak validation
request. For example, shorter update periodicity for CRLs with key compromise and longer for
low priority routinely revoked CRLs. However [COO98] explains a scenario which illustrates
how partitioning CRL based on CRLReason code opens a door for vulnerability.
The fact is; it is normal to update infrequently CRLs with routine CRLReason, because of their
insensitivity. With this fact in mind, according to Cooper an attacker can compromise PKC
key and report it with a routine CRLReason code, so that it will give the attacker a relaxed
time to misuse the compromised PKC. On the other hand, if there is no permanent solution
to manage PKC holders and relying party population size scalability efficiently, Partition CRL
solution can be only a temporary solution. As the base CRL increases over time segments can
do so, unless ithere is a mechanism to partition the segments into sub-segments again and again.
4.3. DYNAMIC CRL DISTRIBUTION POINTS 33
Also, Partition CRL implements a rigid static partition, i.e. there is no way to accommodate
organizational or any other change once the partition is done.
Formal Analysis of Partitioned CRL
According to (preposition 7), it is not possible to avoid network bottleneck problem completely;
if a revocation scheme incorporates periodic CRL update. Partition CRL is no different, it only
minimize bottleneck until the CRL of individual partition grows larger. Except its contribu-
tion in performance (specifically improvement in CSI distribution) to minimize bottleneck and
improve scalability Partition CRL is same as Traditional CRL.
4.3 Dynamic CRL Distribution Points
The problem with traditional Partitioned CRL (see Section 4.2) is that the partition is fixed,
meaning the partition has to be set by the CA before the issuance of the PKC and later there is
no way to change that partition for the life time of that PKC. Static segmentation of partitions
is problematic for the following reasons. One reason, the number of actually revoked PKC
can be huge at one partition and small or null in another. On the other hand, CRL request
rate in some application is more frequent (for e.g. in ecommerce sites) than others. This
static approach can potentially create unbalanced loads between different partitions. As a result
Dynamic CRL Distribution Points1 is proposed (it is formerly called Enhanced CRL Distribution
Options [HBF98]) with two CRL extensions fields called StatusReferral and CRLScope field.
These two extension fields used to separate the location function from the validation function
in the Dynamic CRL Distribution Points scheme. StatusReferral field implements the location
function; it used to locate the latest (i.e. dynamic) location of the CRL distribution point for the
CRL at hand. Follows, CRLScope field used to validate whether the located CRL distribution
segment contains the required CSI for the CRL at hand.
Dynamic CRL Distribution Points Tradeoffs
In Dynamic CRL distribution a CRL which contains the StatusReferral does not contain the
actual CSI; instead it contains a pointer to a specific partition. The scheme in general is good in
balancing loads between existing partitions, which indirectly contribute to maintain a scalable
PKC revocation scheme with dynamically and uniformly allocation of CRL update partitions.
The scheme can also help to increase CSI availability since infrastructural resources can be
shared evenly.
1
Dynamic CRL Distribution Point can also be called Dynamic Partitioned CRL, since Partitioned CRL is a
preferred naming in this thesis; however the name Dynamic CRL Distribution Point is used to maintain consistency
with the original paper of the scheme. (see Appendix A)
Complexity Complex Network usage Fair
Standardized No CSI-cache-size Small
Freshness Low Fair High Management High
Scalability High CSI integrity Signature
Scope Normal CSI availability High
Dynamic load balancing between partitions in Partitions CRL
Table 4.3: Evaluation of Dynamic CRL Distribution Points
Formal Analysis of Dynamic CRL Distribution Points
With its dynamic approach Dynamic CRL Distribution Points can implements a truly managed
scalable (preposition 8) PKC revocation scheme with minimized bottleneck (preposition 7). Also,
the same dynamic approach can introduce complexity and management overburdens. According
to (preposition 1) complexity might introduce insecurity and high cost (preposition 11). As
Partition CRL shares most of the drawbacks of Traditional CRL, also Dynamic CRL Distribution
Points does share almost the same drawbacks.
4.4 Redirect CRL

The concept of Redirect CRL2 [AZ98] revocation scheme mainly derived from Dynamic CRL
Distribution Points (see Section 4.3) and also attempts to address the problem of growing CRL
Distribution Points. [AZ98] claimed the use of unsigned pointers by Dynamic CRL Distribution
Points to CRLs that contain a CRLScope statement will create a backdoor for DOS. As a
result, according to [AZ98] Redirected CRL implements signed redirection information to avoid
DOS. Redirected CRL is a CRL extension, which contains a set of scope statements and their
associated pointers. Scope statement tells the ranges of PKC covered by the CRL segment
(distribution point). For example, if a given CRL distribution segment covers serial number
from 5,000 to 9,000 and it is assumed its CRL list grows unmanageably. A scope statement in
2
Some literatures mix the concept of Redirected CRL with Dynamic CRL Distribution Points, in reality they
are two different schemes. [AZ98] mention Dynamic CRL Distribution Points with a name Open CRL Distribution
Point in the original paper of the scheme proposal (see Appendix A).
4.4. REDIRECT CRL 35
the Redirected CRL may indicate serial number from 7,000 to 8,000, meaning the pointer points
to another (probably new) CRL distribution segment for that range. The scheme is designed in
a way which is possible to make a repartition of CRL distribution point once the certificate is
issued with fixed CRL Partition information. Note that, a Redirected CRL pointer in practice
can point to a new CRL Distribution Point or Freshest CRL (see Section 4.11) [AZ98].
Standardized No CSI-cache-size Large
Selective load balancing for growing partitions
Table 4.4: Evaluation of Redirect CRL
Redirect CRL Tradeoffs
The possibility of repartitioning a growing CRL Distribution point after a certificate is issued
is a major benefit of Redirected CRL. Real scalability is a major advantage of this scheme; the
scheme is highly scalable since it is possible to repartition a growing partition. One concern here
might be for really growing PKI, there is a possibility of CRL growth even for the newly created
partition (in exceptionally growing CRL environment) so repartitioning of a repartitioned CRL
distribution might needed. If it is not partitioned wisely from the start the revocation scheme
will end up in loops of repartitioning already repartitioned CRL distribution point. Thus, com-
munication, computation, management and CSI update cost will be extremely high. Redirect
CRL differs from traditional CRL only by its location function [ISKP00] and the intermediate
CRL (the Redirect CRL itself) can be spoofed through CRL-substitution attacks, so consistency
check should be done somehow. Other advantage of this scheme is it can use already existing
standards (X.509 v2 CRL and X.509 v3 Certificate extension, the CRL Distribution Point Ex-
tension, see Section 2.4) and repartition is required when it is necessary only, so does the cost
associated with it. Therefore, Redirected CRL designed in a way it can handle unexpected
revocation behavior problems (unmanageably growing CRL segment) so that it can handle true
scalability.
Formal Analysis of Redirect CRL
Since it is an improvement over Dynamic CRL Distribution Points, Redirected CRL provides
the same benefit of truly managed scalability (preposition 8) and minimized network bottleneck
(preposition 7) in the expense of high management overburden and complexity (preposition 1).
4.5 Delta CRL

Delta CRL[ZHA06] is an X.509 v2 CRL standard extension (see Section 2.3). It creates a way to
partition Full CRL into Base CRL and Delta CRL. Base CRL contains a complete CRL list at a
given time and Delta CRL contains CRL update differences since the issuance of the preceding
Base CRL. An extension called deltaCRLIndicator is used to identify a CRL as Delta CRL; it
also contains a reference number to the Base CRL and all the update information regarding
the Base CRL. The central idea behind Delta CRL is, to enable a relying party which already
has the latest Base CRL, to download only smaller amount of list (i.e. Delta CRL) instead of
fetching a redundant full CRL.
Complexity Simple Network usage Fair
Standardized Yes CSI-cache-size Large
Timeliness Unclear Computation Fair
Freshness High Management High
equals the periodicity of Delta-CRL publication
Incremental (non redundant) CRL update
Table 4.5: Evaluation of Delta CRL
Delta CRL Tradeoffs
Delta CRL implements an efficient way to distribute non-redundant and freshest CRLs with
its incremental publication of CRLs. It also reduces the size of a CRL message that needs to
be downloaded at once. Its incremental update creates reduced but more frequent bottleneck
over time (see Section 4.12). Although, bottleneck is still possible as any other periodic update
schemes and specifically whenever a new Base CRL is published. Also, relying party can not
4.6. INDIRECT CRL 37
make a selective download of CRL as Partitioned CRL. Therfore, Delta CRLs relying parties
side CSI catch repository requirement is the same as Traditional CRL.
Formal Analysis of Delta CRL
The main solution of Delta CRL scheme starts with minimized bottleneck and low resource
usage. Delta CRL capabilities of increased distribution of CSI makes it possible to reduce risk
(preposition 5) and maximize CSI freshness. In comparison with Dynamic CRL Distribution
Points (see Section 4.3) and Redirect CRL (see Section 4.4), Delta CRL does not contribute much
to manage CRL scalability problem. Since scalability is the question of efficient infrastructural
resources management and not a CSI freshness problem. In addition, its management of Delta
CRL may introduce fair complexity (preposition 1) and can make it fairly costly (preposition
11).
4.6 Indirect CRL

Indirect CRL [HPFS02] is a standard X.509 v.2 CRL extension (see Section 2.3). Indirect CRL
is not a PKC revocation scheme by it self. Like Freshest CRL, it only facilitates CRL retrieval
for the convenience of relying parties. The fact is, when there is more than one CA, relying
party has to consult multiple CRL distribution points. Indirect CRL alleviate this problem
by compiling CRLs issued by multiple CAs into one CRL and make them accessible from a
single distribution point. A given CRL is identified as an Indirect CRL, when the indirectCRL
indicator flag of Issuing Distribution Point extension set to TRUE.
Standardized Yes CSI-cache-size High
Scope Versatile CSI availability High
equals the shortest next CRL update date publication
Single CRL update access point
Table 4.6: Evaluation of Indirect CRL

Indirect CRL Tradeoffs
Indirect CRL can reduce the overhead of obtaining CRLs from multiple CAs inside a single PKI
domain or inter-domain scenarios. A large PKI with several CAs may improve the efficiency
of its CRL retrieval by making them accessible via Indirect CRL. In either of the two cases,
the Indirect CRL provider has to be trusted. One problem with this scheme is; CRLs which
is collected from different CAs may have different nextUpdate date (see Section 2.3). Since
Indirect CRL scheme update all sets of CRL at once, the periodicity of all different CRL will
be equal with the shortest CRL nextUpdate date. The problem with Indirect CRL, there is no
sensitivity classification like Freshest CRL; also there is no way to avoid redundancy like Delta
CRL and there is no type classifications like Partitioned CRL. As a result, a relying party has
to engage in frequent update weather it is required or not. An increase in the frequency of
CRL publishing might increase the freshness of the updated CRL. However, without selective
approach those who do not require fresh CRL might get disadvantaged by wasting unnecessary
update, computational and communication cost.
Since it is not tied with any specific revocation scheme, from the integration perspective Indirect
CRL shows a maximum versatility. Though, it can have frequent peak update request rate
because of its shortest update periodicity, large CSI message size and extended relying party
population size. To accommodate this, extra large bandwidth and high communication cost is
a must. From the availability perspective, it is efficient for the relying party to get all CRLs
from a single distribution point, but is also efficient for an attacker to have a single point of
attack. Since a successful DOS can stop all the service. Indirect CRL greatly damage the
concept of scalability by implementing a centralize CRL distribution management. Scalability
better achieved with distributed or replicated CRL distribution approach, with the centralized
approach the list grows large very fast and shortly management will become a nightmare.
Formal Analysis of Indirect CRL
Indirect CRL drawbacks start from its complexity (preposition 1), large (full) CSI and centralized
distribution which can potentially introduce insecurity, performance degradation and high cost
(preposition 11). Its centralized approach also reduces its reliability (preposition 12).
4.6.1 Indirect Delta CRL

X.509 v3 PKC introduce the concept of Indirect Delta CRL [AL02] to enhance timelines. The
scheme inherit functionality from both Indirect CRL (see Section 4.6) and Delta CRL (see
Section 4.5), so that it follows incremental postings based on some previously published CRL
and it used to update multiple CRLs issued by a single issuer or multiple issuer (CA).
4.7 Over-Issued CRL

In Traditional CRL scheme cached CRL expiration date (nextUpdate date) is the same for CRLs
issued by a common CA. As a result, all relying parties CRL catch gets empty at the same time.
4.7. OVER-ISSUED CRL 39
This approach initiates a problem of peak update request rate, since it demands relying parties to
make update all at the same time. Over-Issued CRL [COO99] avoids this by making it possible
to have more than one overlapping CRL expiration date for CRLs. This enables cached CRLs in
relying parties’ catch to expire at different times instead of once. For example, if CRL expiration
period is 24 hour, an Over-Issued CRL can be issued every 6 hours and in four batches. At a
given time only 1/4 of the relying party needs to update their CRL and the rest (3/4) still can
have a valid CRL. It helps to reduce the peak request rate, since only those with expired CRL
have to request a CRL update.
Freshness Fair Management High
Bottleneck Low CSI update High
Non-uniform CRL expiration
Table 4.7: Evaluation of Over-Issued CRL
Over-Issued CRL Tradeoffs
Over-Issued CRL helps to maintain a balanced peak validation request rate and network resource
usage with good performance. With revocation schemes like Traditional CRL, when there is a
peak validation request there is a need for high bandwidth and that need reduce dramatically
after the peak request rate. To accommodate the worst case scenario (i.e. high peak request rate)
revocation service providers need to use high bandwidth, while this high bandwidth is unused in
most of the time except the peak request time. This generates unnecessary communication cost.
Over-Issued CRL enables a uniform distribution of validation request, it is possible to overlap
relying parties’ CRL expiration date and setup a uniform bandwidth for average and efficient
network resource usage. However, Over-Issued CRL reduce peak validation request rate and
make it to happen more frequently than it is before, i.e. it dose not avoid it totally. Except
it reduced peak validation request rate, Over-Issued CRL inherit most of the Traditional CRL
drawbacks, like high CSI catch requirement, bigger CSI message size, no mechanism to attain
timeliness and freshness. [RJK+ 00] also point out a non-repudiation possibility with Over-Issued
CRL.
Formal Analysis of Over-Issued CRL
Since Over-Issued CRL update full CRL in a frequent manner without applying any partition
to it in addition to creating a complexity (preposition 1) it can also make the scheme costly
(preposition 11). However this problem is addressed by a scheme called Over-Issued Segmented
CRL (see Section 4.11). However, the approach of over-issuing is a good example to increase
reliability (preposition 12) by redundancy to make the CSI highly available.
4.8 Windowed Revocation

After a given PKC gets compromised, its CRL must be published until the corresponding PKC
expiration date. Windowed Revocation [MJ00] proponents say; maintaining CRLs until their
corresponding PKC expires will increases the overall CRL message size unnecessarily for long
period of time. To avoid this problem, McDanniel et al. propose a scheme which enables
CAs to publish a CRL for shorter time bound called revocation window. At the same time
they propose different alternative approaches to make sure all relying parties’ gets the update
within that short period. Proposed ways includes push CRL delivery (explicit notification), IP
multicasting, revocation aggregation (like Indirect CRL, (see Section 4.5)), and missed CRL
publication announcement checking method. The scheme also advocates ‘lazy revocation’ in
which relying parties’ do not need to verify their cached PKC for its revocation status until it
is to be used.
In Windows Revocation, every PKC has a documented revocation window. Revoked PKC are
included in the CRL update for the period of their documented revocation window period. After
that period, there is no way to verify their revocation status. On Windowed Revocation when
there is no revocation status regarding a PKC, the PKC has to be re-acquired. Normally CAs
does not publish revoked PKC. Therefore, relying parties have to understand that the PKC is
revoked if it is not in the list (its revocation window is passed) and drop the PKC.
Windowed Revocation Tradeoffs
In comparison with other PKC revocation schemes Windowed Revocation attempts to provide
all rounded revocation solution, except the problem of its practical feasibility. Implementing
push CRL delivery is ‘almost‘ practically infeasible, especially for large relying party popula-
tion. Especially push CRL delivery demand both relying parties and the CA to be connected
thoroughly. Reduction of CRL message size is a major achievement of Windowed Revocation
scheme, since it is possible to reduce network usage and less CSI catch requirement.
In general, the scheme does not solve problems regarding network bottleneck, because it min-
imizes CRL validation request and introduce alternative PKC re-acquisition request for proof.
4.9. BLACK-LIST CRL 41
Connectivity On/off-line Revocation info Full
CSI evidence Full 7. Cost:
Bottleneck High CSI update Low
shorter period CRL publishing
Table 4.8: Evaluation of Windowed Revocation
Let say we have 15,000 relying party population with certain revoked CRLs. 10,000 of the re-
lying parties manage to update their CRL before the end of the revocation window. For the
others (5,000), when they don’t get the revocation status of a PKC they cached, they have to
re-acquire the PKC and confirm its absence, before they drop the PKC. In either way, relying
parties have to communicate with the CA for CRL validation or PKC re-acquisition. As a re-
sult network overhead, computation and communication costs are not significantly reduced or
avoided. The use of revocation aggregation also makes Windowed Revocation to inherit all the
problems of Indirect CRL (see Section 4.6). In summery, Windows Revocation scheme shows
functional versatility that can be adjusted with selective parameters to fulfill the needs of online
vs. off-line and implicit vs. explicit revocation needs.
Formal Analysis of Windowed Revocation
According to (preposition 2 and 3) Windowed Revocation is a fairly versatile scheme since it gives
both negative and positive CSI evidence as well as works in both off-line and online orientation.
However, it’s large CSI (which is the sum of both negative and positive CSI evidence) makes it
costly (preposition 11) and highly susceptible for network bottleneck problem.
4.9 Black-list CRL

Black-list CRL [PK93] is an attempt to create an alternative for the inherent drawbacks of short-
lived certificate (like SPKI/SDSI (see Section 2.2.3)) or X.509 variant PKC. The overhead of
re-issuing short-lived certificate is very high because of their short expiration period. In general
X.509 based PKC expiration date is relatively longer, sometimes in years. As discussed with
Windowed Revocation longer expiration date makes CRL size enormously large (see Section
4.8). As a result, Black-list CRL proposes a solution for these two problems by completely
erasing ‘expiration date ’from the certificate, i.e. the solution is based on a certificate without
an expiration date.
In Blackl-ist CRL scheme certificates and a black-list are published together. Certificates can
contain all certificate fields (e.g. name, issue date ) except expiration date. A black-list contains
lists of revoked certificates and in addition it has a start and an expiration date. As a rule of
thumb, any certificate issued before a black-list start date considered invalid. So the starting
point for certificate validation becomes validating weather a black-list expired or not. If it is
not expired, the certificate matched against the black-list list. If the certificate is not listed as
a revoked certificate in the black-list, finally certificate issue date and black-list issue date is
compared. If certificate issue date is after black-list issue date, the certificate is proved to be
valid.
However, if the black-list is expired from the very beginning one can merely declare the certificate
as invalid or check weather the black-list default expiration date is passed or not. If it is passed
the certificate is considered invalid. In exceptional cases, a black-list can expire without its
default expiration date reached. A new shorter black-list gets published if the size of the black-
list gets lengthy, without waiting for the black-list default expiration date to come. In such
condition a certificate can be accepted as a valid only if it is not listed in the black-list and
issued before the black-list start date. Therefore, with Black-list CRL scheme a new certificate
issued only when the black-list gets too long and not because the certificate gets expired.
Black-list CRL Tradeoffs
As [PK93] explained Black-list CRL is suitable in an environment where revocation is not fre-
quent and also good for onet-ime large scale revocation like corporate reorganization. In an
ideal situation, where revocation is rare, Black-list CRL can help to maintain reduced network
resource usage, CSI catch need, CRL message size and cost. Also the avoidance of periodic
CRL publication is a major contribution of Black-list CRL which maximizes the freshness of the
CSI. Since the scheme makes it possible to update revocation status incrementally (individually)
without the need to wait for a specified CRL batch update date/time.
The major problem with this scheme is, when it enters the worst case scenario, which is an en-
vironment where revocation is in commonplace. With frequent revocation Black-list CRL may
use the network approximately twice in comparison to other CRL variant schemes due to its
requirement to update both certificates and a black-list. It is only the CRL (the black-list) which
gets updated periodically in almost all other CRL variant schemes discussed so far. However,
it is an ideal scheme to make large scale mass revocation at a once. Since after new black-list
with new start date is issued, all certificates issued before the new start date gets invalid au-
tomatically, i.e. no need to maintain their CRL. With other CRL variant scheme making large
4.10. FRESHEST CRL 43
Standardized No CSI-cache-size Low
Freshness High Management Fair
Bottleneck High CSI update Low
equals the periodicity of PKC together black-list publication
Avoid PKC expiration date plus publishing PKC together
with the black-list (CRL) same time
Table 4.9: Evaluation of Black-list CRL
scale revocation at a time makes CRL message size too large at once. An organization with
dynamic organizational structure and non-static authorization (roles) can use of Black-list CRL
more efficiently.
Formal Analysis of Black-list CRL
Black-list PKC revocation scheme is also an attempt to reduce the size of CSI, like Partition
CRL and its variants (Dynamic CRL Distribution Points and Redirect CRL (see Section 4.2,
4.3 and 4.4)) in the expense of updating both PKC and CRL at the same time. As a result
the scheme is interested in improving performance and reduced resource usage, does almost no
contribution toward scalability management.
4.10 Freshest CRL

Freshest CRL [AZ98] is a standard X.509 v.2 CRL extension (see Section 2.3). It is a variant
of Delta CRL which provides a URI3 pointer to tell where to find the freshest Delta CRL from
the Base CRL. The functionality of Freshest CRL governed by two CRL extensions, namely:
CRLDistributionPoint (see Section 4.2) and FreshestCRL (originally called Freshest Revocation
Information Pointer (FRIP)). The central idea of Freshest CRL scheme is to balance between
the risk and cost of obtaining the freshest CRL. Those with high risk and a demand for timely
CRL must get it with additional cost and those with relaxed timing requirement must not pay
3
URI : Universal Resource Identifier
this extra cost. To implement this idea, Freshest CRL scheme follows a versatile approach,
for those with high freshness demand FreshestCRL pointer and for those with less freshness
requirement CRLDistributionPoint can be used. The main advantage of Freshest CRL is, since
the FreshestCRL can be issued frequently, it does not have a fixed update periodicity (i.e. almost
no time granularity). Also, catching Freshest CRL is unlikely (unnecessary) since the Base CRL
and Delta CRL updated regularly. the follwoing table shows evaluation of Freshest CRL from
the FreshestCRL point of view 4 .
Standardized Yes CSI-cache-size Low
Timeliness near Real-Time Computation Low
Bottleneck near None CSI update High
equals the periodicity of CRL(FreshestCRL ) publication
On-demand near-real time CRL updating
Table 4.10: Evaluation of Freshest CRL
Freshest CRL Tradeoffs
One implementation consideration with Freshest CRL is, since it divides the service according
to their costs, a trusted server must be used somehow [SB]. Basically the cost needed to produce
Freshest CRL has to be balanced with provider side (CA) expenditure on a trusted-server(s)
and the extra administrative services. On the other hand, the demand for Freshest CRL is un-
predictable; it can go up and down over time. As a result of these tradeoffs, when the demand
goes down the provider has to increase the cost and the relying party has to pay unnecessary
high costs for that. However, this approach pinpoints that, if it possible to reduce the associated
costs, it is always possible to get the Freshest CRL possible. Therefore, instead of looking for
another or a new PKC revocation scheme, it looks feasible solution to find a way to reduce
the administrative costs and have Freshest CRL with an acceptable cost. This scenario clearly
shows, in addition to a revocation scheme design, external environmental factors contribute cer-
4
Table 4.4 assumes Freshest CRL pointer is selected, so the evaluation presented in it graded from FreshestCRL
perspective only. CRLDistributionPoint already evaluated in Table 4.2
4.11. OVER-ISSUED SEGMENTED CRL 45
tain amount of problem tradeoffs.
[RJK+ 00] argued about a non-repudiation concern if a single CRL update provided by two
parties in different point in time, which is possible in the case of Freshest CRL. Freshest CRL
solution mainly starts from its high availability, but the high availability comes with high man-
agement, update and computational cost. It is the first mechanism to implement versatile
revocation approach based on the existing revocation solutions (i.e. Delta CRL & Partitioned
CRL).
Formal Analysis of Freshest CRL
Freshest CRL introduce a true versatility with its alternative approach which lets the relying
party to choose between FreshestCRL and CRLDistributionPoint. However, due to management
overburden and its complexity (preposition 1) it can potentially introduce high cost (preposition
11). Also, even if it provides the freshest CRL, it inherits the drawbacks from other schemes it
design generally based on (Delta CRL and Partision CRL(see Section 4.2 and 4.5)).
4.11 Over-Issued Segmented CRL

Over-Issued Segmented CRL [COO00] is a hybrid variant CRL created by combining the func-
tionality of Over-Issued CRL (see Section 4.6) and Partitioned CRL (see Section 4.2). In general
both schemes are created to reduce peak request update rate. However, the peak update re-
quest rate of Traditional CRL and Partitioned CRL is almost the same, since in both cases
there is a single period in time all relying parties wants to update their CRL catches. Over-
Issued Segmented CRL tries to combine the benefits of these two schemes into one with two
different fashions. One is to issue different Partition CRL at the same time but issue them
more frequently (i.e. property of Partition CRL (Over-Issued CRL)). The second way is, with
staggering the issuance of different partitions; issue Portioned CRL as often as necessary (i.e.
property of Over-Issued CRL (Partitioned CRL). Despite the different fashion used, the main
goal of Over-issued Segmented CRL is the same, which is reducing the peak validation request
rate.
Over-Issued Segmented CRL Tradeoffs
It is discussed (see Section 4.8) that Over-Issued CRL only makes it possible to maintain low
but more frequent peak-update-request-rate. On the other hand, PKC & relying party pop-
ulation scalability in individual segment also makes Partition CRL a temporary revocation
solution (see Section 4.2). Combining these two schemes still does not address these problems
directly. However, Over-Issued Segmented CRL relatively enables to maintain too low peak-
update-request-rate. As [COO00] explained with the second approach (staggered CRL issuance
of segments), when the number of segments increases the peak update request rate (bottleneck)
can also increases.
Complexity Average Network usage Low
2. Performance: Communication Low
Freshness Low Management Fair
Peak update request rate reduction
Table 4.11: Evaluation of Over-Issued Segmented CRL
Formal Analysis of Over-Issued Segmented CRL
Except its complexity (preposition 1) and management overhead Over-Issued Segmented CRL
provide the benefit of the two schemes, i.e. CSI size reduction and fair management of scalability.
More specifically the combined effect of these two schemes mainly aimed at reducing bottleneck
to get a better performance. As discussed in (see Section 4.7) formal analysis of Over-Issued
CRL, the scheme can also improve reliability of CSI availability. With this scheme it is possible
to provide freshest CRL only for a relying party which demands it, since the segmentation can
help for selection and over-issuing for freshness (Proposition 6).
4.12 Over-Issued Delta CRL
The idea behind Over-issued Delta CRL [COO00] is the same as the Idea of Over-Issued CRL
(see Section 4.7) except with Over-Issued Delta CRL, the Delta CRL itself over-issued instead
of the Base CRL. In an environment where the relying party needs fresh validation information
very frequently (e.g. every 10 min.), Delta CRL can not reduce the bottleneck, instead it will
make it more frequent. For such environments Cooper [COO00] suggests the use of relatively
longer Delta CRL validity period and over-issue the Delta CRL. With this scheme it is possible
to issue overlapping Delta CRL without waiting for the expiration of the Delta CRL. In other
words with Over-issued Delta CRL it is possible to issue a new Delta CRLs with overlapping
periodicity.
4.13. OVER-ISSUING DELTA CRL WITH DISTRIBUTION POINTS 47
Scalability Low CSI integrity Signature
Non-uniform Delta CRL expiration
Table 4.12: Evaluation of Over-Issued Delta CRL
Over-Issued Delta CRL Tradeoffs
Over-Issued Delta CRL takes the advantage of Delta CRL which is mainly reduction of CSI-
message-size and Over-Issued CRL which is mainly reduction of bottleneck. Consequently, it is
possible to get a revocation scheme with reduced CSI-message-size and bottleneck. Reduction
of bottleneck indirectly it improves the availability of the CSI. Smaller CSI-message-size also
makes it possible to use infrastructural resources in an efficient manner and reduced CSI update
costs.
Formal Analysis of Over-Issued Delta CRL
Over-Issued Delta CRL is an off-line revocation scheme which tries to attain online standard
freshness by combining two schemes designed to provide freshness in the first place (see Section
4.5 and 4. 7). The problem with this scheme it is not possible to provide freshest CRL selectively
only for those who needs it (preposition 6). This particular problem is addresses by Over-Issuing
Delta CRL with Distribution Points (see Section 4.13)
4.13 Over-Issuing Delta CRL with Distribution Points

As explained in the previous section (see Section 4.12) the use of Delta CRL will not reduce the
peak update request rate rather it will make it more frequent, unless an extended Delta CRL
validity period used. [COO00] propose Over-Issued Delta CRL to by assuming the revocation
scheme to have a longer Delta CRL validity time and the Delta CRL is over-issued within that
range of taht time. Over-Issuing Delta CRL with Distribution Points5 [SR03] [RS04]meant to
create additional performance improvement to Over-issued Delta CRL. With partitioned CRL
approach, which is the basic property of a Distribution Points CRL, it is possible to reduce the
Delta CRL message size. CRL partition criteria can be factored from different perspective like
CRLReason (see Section 2.4 and 4.2).
Complexity Complex Network usage Low
Scope Versatile CSI availability Fair
equals the periodicity of Delta-CRL publication
Incremental, distributed and optimized Delta CRL update
Table 4.13: Evaluation of Over-Issuing Delta CRL with Distribution Points
Over-Issued Delta CRL with Distribution Points Tradeoffs
Over-Issuing Delta CRL with Distribution Points can be a good example to show how different
PKC revocation schemes can be combined to get a better PKC revocation scheme. As already
described (see Section 4.2, 4.5 and 4.7) Delta CRL reduced CRL message size, Over-Issued CRL
and Partitioned (Distribution Points CRL) reduces peak validation request rate. Combining
them together makes it possible to get a PKC revocation scheme which has small Delta CRL-
message- size with a reduced peak update request rate. The major difference between Over-
Issuing Delta CRL with Distribution Points and Over-Issuing Delta CRL shown on the difference
of the size in their Delta CRL message size. Over-Issuing Delta CRL with Distribution Points
has a smaller Delta CRL message size, since it applies partition on the Delta CRL. However,
in both schemes the assumption of longer Delta CRL validity period will have a side effect in
the freshness of the CSI message they provide. [SR03] mention the scheme can reduce the size
of Base CRL and Delta CRL message at the same time spread out the peak update request
rate. For PKI environment with high bandwidth there is no difference between using Over-
Issuing Delta CRL with Distribution Points and Over-Issuing Delta CRL, since the addition of
5
Distribution Points CRL can also called Partition CRL (see Section 4.2, 4.3 and Apendix A)
4.14. SLIDING WINDOW DELTA CRL 49
Distribution point only helps to reduce the Delta and Base CRL message size.
Formal Analysis of Over-Issuing Delta CRL with Distribution Points
Over-Issuing Delta CRL with Distribution Points maintain versatility from the performance
point of view by providing CSI freshness which can be used selectively. Its versatility which
comes because of the integration among the three schemes can be an advantage on one hand a
drawback on the other hand. Complexity (preposition 1) is the drawback which consequently
can create high cost (preposition 11) due to high design and management overheads. Also, the
scheme does not address scalability management directly.
4.14 Sliding Window Delta CRL
Traditional Delta CRL lists all revoked CRLs since the latest issued Base CRL (see Section 4.5).
As a result the window over which the Delta CRL issued is varied, since certificate revocation in
reality happens in a varied point over time. The problem as discussed by Cooper [COO00], if a
relying party obtain the latest Base CRL at time t and later obtain a Delta CRL that reference
a Base CRL issued at time t’≥ t, then the relying party can not update its local CSI cache unless
it gets a new Base CRL. As a result the request rate for Base CRL increases when the Delta
CRL revocation window size decreases and it decreases when the Delta CRL revocation window
size increases. To avoid this problem Cooper proposed Sliding Window Delta CRL [COO00], in
which each Delta CRL revocation window made fixed and large instead of variable revocation
window of traditional CRL. Therefore, a relying party obtain the latest Base CRL at time t and
later obtain a Delta CRL that reference to a Base CRL issued at time t’≤ t do not need to
obtain a new Base CRL, if it uses Sliding Window Delta CRL, it can use the Delta CRL instead
to update its local cache. However, a relying party needs to get a Base CRL, in circumstances
where its last validation was before the time referenced that the base CRL referenced by the
current delta-CRL was issued.
Sliding Window Delta CRL Tradeoffs
Sliding Window Delta CRL is an important improvement over the Delta CRL like Over-Issued
Delta CRL and Over-Issued Delta CRL with Distribution Points (see Section 4.5 and 4.13). It
mainly helps to reduce the need for frequent Base CRL in revocation schemes which include (or
hybrid of) Delta CRL in their revocation scheme. However, advocating fixed Delta CRL windows
validity can indirectly reduce the freshness of the Delta CRL, since real time issuing of Delta
CRL for a compromised PKC can not be possible. Although, the possibility of repartitioning of
CRL distribution any time for load balancing is a major achievement of Sliding Window Delta
CRL scheme.
Complexity Simple Network usage Low
Timeliness Unclear Computation Low
Freshness Low Management Low
Scope Normal CSI availability Fair
equals the fixed Delta CRL revocation window
Reduction of request rate for Base CRL in Delta CRL based schemes
Table 4.14: Evaluation of Sliding Window Delta CRL
Formal Analysis of Sliding Window Delta CRL
Sliding Window Delta CRL is an attempt to reduce the size of CSI message as other PKC
revocation schemes does in a diferent way (for example as Partition CRL (see Section 4.2)).
The main intension behind is to reduce bottleneck and maintain better performance in the cost
of lacking freshness.
4.15 Online Certificate Status Protocol (OCSP)

OCSP [MAM+ 99] proposed by the IETF PKIX Working Group and it is an online PKC revo-
cation scheme works with a simple request-response protocol called OCSP client (relying party)
and OCSP responder (TTP). The possible OCSP responses for online PKC validation request
are: good, revoked and unknown. Good means the PKC in the validation is not revoked yet,
revoked means it is actually in the revoked PKC list and unknown means the OCSP responder
is unaware of the PKC in the validation. Each OCSP responses digitally signed by the CA or
another entity designated by the CA. OCSP is mainly designed for mission critical application
which demands more recent CSI like online stock exchange or online money transfer [MAM+ 99].
Apart from the standard OCSP of IETF, there exist variant commercial proprietary implemen-
tation of it by ValiCert, VeriSign and Entrust [ZHE03].
OCSP Tradeoffs
OCSP designed as alternative to CRL, especially to avoid downloading of CRL and get the
freshest possible CSI. The scheme enables relying party who has no immediate need in getting
4.15. ONLINE CERTIFICATE STATUS PROTOCOL (OCSP) 51
Complexity Complex Network usage High
Connectivity Online Revocation info Constant
Standardized Yes CSI-cache-size Null
Timeliness Real-Time Computation High
Bottleneck Fair CSI update Null
Theoretically equals Null
Online, real-time, fresh CSI, plus full CSI evidence
Table 4.15: Evaluation of OCSP
CSI does not receive any CSI message. Totally avoiding CRL download (to local cache) is a
turning point which makes CSI update cost and local CSI-cache requirement to zero. However,
OCSP still has a number of practical challenges to deal with. The use of TTP (OCSP responder)
demands signing every OCSP responses to make it un-forgeable, which is costly and at the same
time overburden the OCSP responder. Also, the use of trusted OCSP responder (as a TTP)
is a drawback in the PKI trust model where the CA serves as a TTP in addition, since the
trusted OCSP responder can be a single point of failure, in case of key compromise, in addition
to the CA. If the OCSP responder key gets compromised; by far there is no way to handle
this gracefully [SB06] except using a short-lived certificate (see Section 3.1). DOS attack is
reputedly discussed problem for OCSP service, since OCSP has to sign each OCSP request
query responses, an attacker can flood the OCSP responder with massive OCSP request queries
and crash the system. As described by [Tj04] OCSP error messages are not signed, attacker
can take a benefit out of it by sending a false error message as OCSP responder (masquerading
attack).
Formal Analysis of OCSP
Performance supremacy is the biggest advantage of OCSP over CRL based schemes, because
of its timely CSI generation, CSI distribution and constant revocation information. OCSP is
capable of generate and distribute full CSI evidence in a real-time fashion (preposition 3 and 4).
Since there is no need to fetch a list of CRL bottleneck also highly minimized (preposition 7).
However, the scheme can only manage scalability if its OCSP responder works in a distributed
fashion (preposition 8). Distributed OCSP addresses this demand (see section 4.16).
4.15.1 OCSP Extensions (OCSP-X)
OCSP Extension [HB99] is an effort by the IETF to make OCSP more versatile, so that it a
richer set of semantics like full path validation by the OCSP responder. OCSP-X is an optional
extension which lets relying party to delegate the validation of certificate to a trusted server.
Relying party only controls to what extent the delegation takes place. The motivation behind
this protocol comes from an attempt to create a favorable PKC revocation scheme for resource
constrained environments like embedded systems and wireless environments. Embedded and
wireless systems characterized by their constrained processing power, and low memory, at the
same time they boast longer operating life time and need minimized maintenance due to high
cost. OCSP-X tries to meet the demands of such requirements.
4.16 Distributed OCSP (D-OCSP)
OCSP solves some of the major Traditional CRL problems, however its centralized PKC re-
vocation validation approach increase network traffic and makes it a single point of attack. A
system with centralized approach (like OCSP) can potentially break down easily by intentional
or unintentional natural causes, which can range from natural disasters to planned informa-
tion warfare attack and its availability can be a nightmare. Distributed OCSP [Cor] attempt
to solve these problems by advocating a distributed architecture, which is a system composed
of multiple OCSP responders, so that OCSP responders can share workloads. According to
D-OCSP proponents, performance can drop if the distance to the data source increases. As a
result, implementing unlimited geographically scattered OCSP responders potentially enable a
relying party to choose the closest OCSP responder and get a good performance in response.
In D-OCSP there is a single authority which controls the release of CSI proofs and multiple
secret-less OCSP responders which provide the CSI proofs to relying parties6 .
D-OCSP Tradeoffs
D-OCSP gives a solution to the challenge of finding a truly scalability PKC revocation scheme,
however it has problems and some of the problems inherited form OCSP. Since each OCSP
responders has to sign the response with their private key, it has challenging tradeoffs to use
the same private key for all OCSP responders or using different private key. When all OCSP
responders use same key, it is easy for key management but it has a great risk of key exposure and
integrity problem. Although, when different keys used, key management becomes more difficult.
Despite the problems discussed, D-OCSP has a number of advantages like high availability
and high performance because of its distributed architecture. It is also highly survivable in
intentional attack or unintentional disasters.
6
D-OCSP is mainly an online validation mechanism. However CoreStreet in its white paper describes how the
scheme can be used in an off-line manner. [Cor]
4.17. CERTIFICATE REVOCATION STATUS (CRS) 53
Standardized No CSI-cache-size Null
Timeliness Real-Time Computation Fair
Bottleneck Low CSI update Null
theoretically equals , Null
Geographically distributing CSI validation
Table 4.16: Evaluation of D-OCSP
Formal Analysis of D-OCSP
D-OCSP is an attempt to make OCSP truly managed scalability by introducing distributed

approach into OCSP basic design (preposition 8). It also creates reliability into the OCSP
architecture, which is very important from the availability point of view (preposition 12). D-
OCSP shares most of the advantage and drawbacks of OCSP except OCSP scalability reliability
problems (see Section 4.15).
4.17 Certificate Revocation Status (CRS)

Certificate Revocation Status [MIC96] is an attempt to replaces CRL with a mechanism which
sends a simple data structure called Certificate Revocation Status (CRS). The CSR tells whether
PKC is revoked or not at the current date by publishing it into a public repository (un-trusted
directory). The difference between CRL and CRS comes from the fact that, CRS are short and
individualized CSI, whereas CRLs are (mostly) long and collective CSI. According to [MIC96]
computing CRS is much faster and their length is much shorter than that of signing a message
and the length of digital signature in traditional CSI like OCSP. Traditionally, the total number
of communication from directory-to-relying parties for PKC validation is enormous, since relying
party has to fetch large chucks of CRL. However, the total number of communication from CA-
to-directory for CSI update is less and even can be done in an off-line manner. CRS advocate a
new paradigm which increase the communication from CA-to-directory, in which the directory
can answer more concisely every PKC validation queries. In addition, CRS architecture minimize
the communication between directory-to-relying parties, since only a single validation query is
suffice for each PKC. However, CA-to-directory communication becomes high in CRS, since
CA has to update not only PKC whose CSI changed but all PKC. CRS directory response in
general terms contains CSI about all not-yet-expired PKC. The response is organized by PKC
serial number, and for each of them it stores at list a 100-bit value Y (for “YES”), if the PKC
is not revoked, else it stores 100-bit value N (for “NO”).
equals CRS update period (theoretically one day )
Reduction of communication burden from directory-to-relying parties
Table 4.17: Evaluation of CRS
CRS Tradeoffs
One of CRS advantage it gives full CSI evidence, meaning the revocation statement contains re-
vocation reason and a time stamp[ISKP00]. Also it greatly reduces the communication cost from
directory-to-relying parties. It is also possible for the relying party hold a succinct transferable
proof about the certificate they hold and present them along with their certificate. However, an
increased communication from CA-to-directory can over-burden the CA, since CA has to sign
a CSI for both valid and revoked PKC. [MIC96] approach to reduce the size of the signature
commented as a nave by [SB06]. Adams et al. also concerned about the idea of CRS scheme
which stores private information about every PKC and its limited granularity once the PKC
issued. As a result, they label this revocation scheme as ‘non-practical solution’ [SB06].
Formal Analysis of CRS
Providing full CSI evidence (preposition 3) and communication cost reduction in the relying
party side is a major contribution of CRS.
4.18. NOVOMODO 55
4.17.1 Fast Digital Identity Revocation
Fast Digital Identity Revocation [ALO98] is an attempt to make extension to Macili CRS (see
Section 4.17). The new improvement to CRS mainly concentrates in reducing the huge number of
communication required from CA-to-directory, while maintaining a reduced communication from
directory-to-relying parties. Under the umbrella of Fast Digital Identity Revocation [ALO98]
propose two methods: Hierarchical Certificate Revocation Scheme (HCRS) and a generalized
one. HCRS reduced the amount of communication burden from CA-to-directory by organizing
the validation information in a tree. The generalized method intended to increase performance,
but it didn’t use the hierarchical approach.
4.18 NOVOMODO
Micalis NOVOMODO [Mic02] is an improvement of his former CRS (see Section 4.17) revocation
scheme. Among the improvements made in NOVOMODO the inclusion of one way hashing
function; and avoidance of Certificate Management Ancillary Entity (CMAE) are the main once
[ZHE03]. CMAE is an entity in the PKI which provide or give enough information where to
get CSI. In NOVOMODO the CA issue CSI daily or other specific time frame. Relying party
has to tests the CSI provided mathematically to make certain about its validity. The use of one
way hash function by NOVOMODO has three advantages: hashes are 10.000 times faster to
compute than digital signature, independently of the input size the hash always output a fixed
20 byte output and hash is hard to reverse. In NOVOMODO a PKC has to include two 20
byte values unique to that PKC only. NOVOMODO can also be implemented in a centralized
and distributed manner. A centralized NOVOMODO uses a single vault to answer all validity
queries, where as a distributed NOVOMODO uses a single vault and unlimited number of “un-
trusted responders” to answer validation questions.
NOVOMODO Tradeoffs
In NOVOMODO a proof of validity and revocation is hard to forge and they are only two 20
byte. Unlike OCSP, NOVOMODO uses a bound time with predetermined accuracy (for example
the validation period can be one day or one hour etc) and consumes less bandwidth since it uses
only 20 byte validation answer (OCSP needs 256 bytes). A validation query is answered easily
by making a table look-up in the NOVOMODO, instead of complex digital signature practiced
by other revocation schemes (like OCSP). Its centralized and distributed approach showed a
great deal of versatility. Where centralized is preferable in situation where the number of issued
PKC is still small. Distributed on the other hand is preferable when the number of issued PKC
grows, so that it will be easy to balance the load between different distribution points and resist
DOS attack.
Connectivity on-line Revocation info Constant
Timeliness Short Computation Low
Freshness Fair Management Fair
Scalability High CSI integrity Hash function
equals CSI update period (theoretically one day )
Use of one way hash function, instead of signature
Table 4.18: Evaluation of NOVOMODO
Formal Analysis of NOVOMODO
NOVOMODO exhibits high versatility since it advocates full CSI (preposition 3) and also cen-
tralized/distributed implementation. As shown with other schemes distributed implementation
of a revocation scheme greatly helps to manage scalability and maintain reliability (preposition
8 and 12).
4.19 Certificate Revocation Tree (CRT)

CRT is a proprietary ValiCert technology proposed by Kocher [Koc98] as an improvement to
OCSP. CRT is designed in a way its PKC validation service replicated geographically, so that
it can be easy to balance the load across different CSI Issuers. [Koc98] approach to distributed
PKC validation capability starts from its single and highly secure validation authority which
periodically posts a signed CRT (CRL like data structure) to many CSI Issuers. CRT is a kind
of data structure which uses a binary hash tree (Merkle Tree[Mer89]), where its leaves represent
sorted revoked PKC. Validation authority signs the root of the binary hash tree and produces
a short proof to determine whether a PKC is revoked or not. A relying party can query the
nearest CSI issuer to get CSI validation response. However, every time a new PKC revocation
needs to be updated to the tree, it requires the full reconstruction of the binary hash tree.
CRT Tradeoffs
According to [Koc98] CRT is a scheme which attempt to find a PKC revocation solution which
is somehow between Traditional CRLs and OCSP. CRT unlike OCSP it uses a single digital sig-
4.19. CERTIFICATE REVOCATION TREE (CRT) 57
Connectivity on-line Revocation info near Constant
Bottleneck Low CSI update High
Scope Normal CSI availability Fair
equals the periodicity of CRT publication to CSI Issuers
Using single digital signature to secure all CSI
Table 4.19: Evaluation of Certificate Revocation Tree
nature to secure the entire validation set and also unlike Traditional CRL a relying party does
not need to consult the entire CRT. It is also possible for the relying party hold a succinct trans-
ferable proof about the certificate they hold and present them along with their certificate. CRTs
short CSI proof and single digital signature approach is a major advantage since it improves the
scheme performance and cut computational and communication costs. Even if CRT proofs are
short, its approach of providing a single validation response than a list (as CRLs does), might
leads to more PKC revocation validation requests. However, it is possible to make CRT scalable
as far as it is possible to increase the number of CRT issuers. In traditional CRL the size of CRL
grows linearly with the number of revoked PKCs. In CRT it grows as the log of so far revoked
PKC (the length of the proof is O(log n), for n leaf tree) which is a small fraction in comparison
with Traditional CRL. Although, the validation response size is still much bigger than OCSP
since the size of validation is constant in OCSP O(1). Repeatedly discussed short comings of
CRT is, the need to reconstruct the entire hash tree, every time a new revocation update needs
to be added or deleted. The re-computation of the entire CRT is expensive computationally, so
Naor’s and Nissim’s scheme (see Section 4.19.1) made some improvement on CRT particularly
to solve this challenge.
Formal Analysis of CRT
CRT promotes distributed approach which is important to truly manage PKC evocation scheme
scalability. However, it can be computationally costly since its CSI update is costly (preposition
10).
4.19.1 2-3 Certificate Revocation Tree (2-3 CRT)
2-3 CRT [NN00] (also called Authenticated Dictionary see Appendix A) introduce a search
tree that counter CRTs CSI update re-computation problem. “Kocher [Koc98] also advocates
a static hash tree approach for realizing an authenticated dictionary, ... Using techniques from
incremental cryptography, Naor and Nissim [NN00] dynamize hash trees to support the insertion
and deletion of elements using 2-3 trees”[AGT01]. The idea behind 2-3 CRT is every internal
node has two or three branches, if an element needs to be added on a particular leaf the update
done in two alternative ways. If the leaf has only two branches a third branch is simply added
or if the leaf already has three branches a new sub-tree is formulated[IGS+ 03]. For n leaf tree
search, insertion and deletion of an element can be done in O(log n) and insertion and deletion
affects only those supporting nods on its path to the root. It reduces the update cost of the
CA and CA-to-CSI Issuer upon PKC revocation. Skip-Lists PKC revocation scheme [GTS01]
is also another attempt by Goodrich, which tries to solve CRT update re-computation problem
as 2-3 CRT.
4.20 Semi-Trusted Mediator (SEM)

SEM [BDTW01] is intended to make immediate PKC revocation a reality. The scheme intro-
duces a new entity called SEM (security mediator). SEM serves as a semi-trusted server which
provides a message specific token to a PKC holder. Then the token enables a PKC holder to
use its private key, without the token a holder can not use its private key to sign or decrypt.
Therefore, with such scenario PKC revocation is as simple as instructing the SEM to stop issu-
ing the token for the PKC holder; follows a user ability to sign and/or decrypt capabilities are
revoked. The SEM architecture uses threshold RSA [Gem97], in which each RSA private key
splits into two parts. One part stays with the user and the other with the SEM server. Since the
knowledge of half-private key is not useful to drive the complete key, neither of the two parties
can sign nor decrypt a message without mutual cooperation. As a result, in order to revoke a
PKC it is enough to notify the SEM. Each SEM servers consult their list of revoked PKC upon
every service request.
SEM Tradeoffs
Besides the infeasibility surrounding in maintaining a globally semi-trusted SEM server and a
problem of DOS the scheme solves PKC revocation problem very efficiently. As X.500 directory
never been realized (see Section 2.2.1), it is unthinkable to maintain one globally semi-trusted
SEM. Even if it is maintained globally or locally, because of DOS it can be a single point of
failure. However, the scheme greatly simplifies signature validation and easily applicable in
legacy systems which does not have better processing power to validate digital signature in
the traditional way. As discussed by the [BDTW01] legacy systems have no PKC validation
capability. With the use of SEM to validate a signature does not require PKC validation, the
existence of a signature by itself is a proof for its validity.
4.21. TRUSTED DIRECTORIES 59
Complexity Simple Network usage Low Fair High
Connectivity on-line Revocation info Null
CSI evidence Null 7. Cost:
Timeliness High Computation Low
Bottleneck Null CSI update Null
Scalability Low CSI integrity Null
Scope Normal CSI availability Null
equals the periodicity of SEM update by the CA
Immediate PKC revocation
Table 4.20: Evaluation of SEM
4.21 Trusted Directories

Trusted Directories follow completely a plain approach toward PKC revocation than other
schemes explained so far. The principle behind Trusted Directory is simple, PKC is published
only if it is valid, and otherwise it is removed from the listing directory. This type of revocation
works inside organizational intranet and there is no PKC revocation check at all. From non repu-
diation perspective a relying party has no proof to a third party when the PKC gets invalid. In
addition, the trusted PKC listing directory can be a single point of attack/failure, so it requires
great deal of protection at the same time it requires continuous connectivity. The scheme is also
not accessible outside the intranet and that may create a functional limitation. NOTE: Since
this approach completely different from the usual PKC revocation schemes approach towards
revocation, evaluation and tradeoffs analysis is not included.
Chapter 5
Requirements & Integration
This chapter starts by listing out a requirement analysis for a versatile PKC revocation scheme
based on the previous chapter evaluation analysis tradeoffs. Then it tries to pinpoint and at the
same time proves, whether it is possible to unify the existing PKC revocation schemes into a
unified group in an attempt to drive a versatile PKC revocation scheme.
5.1 Versatile PKC Revocation Scheme
A versatile PKC revocation scheme is a highly generalized all rounded scheme which basically
needs to provide a solution for all or most PKC revocation needs. More specifically, from this
thesis point of view a versatile PKC revocation scheme is a scheme which accommodate as much
as possible unique features from the existing schemes. From this stand point of view; Over-
Issuing Delta CRL with Distribution Points (see Section 4.13) can be a good example since it is
a scheme created by integrating three different PKC revocation schemes. However, versatility in
this thesis can not be viewed from the integration point of view only for two reasons. First for
some revocation schemes it is very difficult to find a common ground to integrate them together
into one scheme. For example, practically integrating a scheme which uses hash value for CSI
value integrity checking (see Section 4.18) with a scheme which uses traditional digital signature
can be practically difficult. Second, it is clear that all the functionality included in the existing
schemes may not necessarily require to built-up a versatile revocation scheme. Some revocation
functionalities are redundant among many schemes and some can be replaced by other methods
superior functionalities and some may have undesired drawbacks. It is also very important to
take into consideration that a versatile PKC revocation scheme has to be engineered in a way
it can provide solutions in different manners. Freshest CRL is a good example for that, since it
provides the FreshestCRL and DistributionPointCRL based on the relying party freshness needs.
Whoever needs a freshest CSI can query the FreshestCRL for PKC validation and those with
no need for freshest CSI can still use DistributionPointCRL.
60
5.2. CONCEPTUALLY VERSATILE PKC REVOCATION SCHEME REQUIREMENT ANALYSIS61
5.2 Conceptually Versatile PKC Revocation Scheme Require-

ment Analysis
This section uses previously discussed chapters as a base to discover requirements and abstrac-
tion for an ideal versatile PKC revocation scheme. It summarizes what an ideal versatile PKC
revocation scheme must do and/or must have, from the functional and non-functional require-
ments point of view.
5.2.1 Major Stakeholders and Functional Components

The main stakeholders in an ideal PKC revocation scheme can be classified into three groups. (1)
CA, (2) PKC holder, and (3) relying party, in addition to these system stakeholders considering
some of the functional components in the system are also important. The important functional
components in an ideal PKC revocation scheme includes: (1) CRL repository/CSI validation
server, (2) communication channel between CA to CRL repository/CSI validation server and
CRL repository/CSI validation server to relying party, and (3) relying party side CRL cache
repository. Each of these stakeholders and functional components has their own functional and
nonfunctional requirements. A PKC holder needs CA to include its PKC serial number in a CRL
(other means of CSI) in a real-time whenever its PKC get compromised. Relying party in general
needs to fetch the freshest CSI possible with less CSI update cost from highly available CRL
repository/CSI validation server any time it wants to validate a given PKC. Figure 5.1 shows the
possible stakeholders and functional components involved in an ideal PKC revocation scheme.
As shown in the figure with pointing arrows, there are four possible interactions to make off-line
Figure 5.1: PKC Revocation Scheme Stakeholders and Functional Components

62 CHAPTER 5. REQUIREMENTS & INTEGRATION
oriented PKC revocation validation and three interactions if it is done in an on-line manner.
1. Interaction one: it can be an interaction initiated by the PKC holder to notify the
CA about its PKC compromise or it can be initiated by the CA itself without the PKC
holder1 . The result of this interaction is useful for CSI/CRL generation (see Section 3.2.2).
2. Interaction two: this interaction always initiated by the CA and mainly intended to
publish revoked PKC into CRL repository/CSI validation server. It is interaction from
CA to CRL repository/CSI validation server (see Section 4.17)
3. Interaction three and four: this interaction initiated by the relying party to validate
whether a PKC revoked or not on the CRL repository/CSI validation server before use.
For PKC on-line schemes it is a request response interaction (two way communication
(see Section 4.15)). Where as off-line PKC revocation schemes has to update their relying
party side CRL cache for later off-line validation (see Section 4.1).
Figure 5.1 shows the communication flow among stakeholders through the functional compo-
nents. The figure depict the life cycle of a generalized PKC revocation scheme. It is possible
to refractor the same figure (see Figure 5.2) to show some of the PKC evaluation matrices dis-
cussed so far. As shown in Figure 5.2 windows of vulnerability is the amount of time needed
from a PKC compromise till its CSI made available to public use in a CRL repository/CSI
validation server. Timeliness on the other hand, represent the time duration required from a
PKC compromise until its CSI generated (note that, it is only until it is generated, it is not
distributed yet). Freshness represents the frequency of the generated CSI publication duration
over time. The rest of the four metrics, i.e. CSI availability, network bottleneck, CSI integrity
and CSI-cache-size, come to the system when a communication between CRL repository/CSI
validation server and relying party established.
Now it is possible to combine the three interactions from Figure 5.1 with the selected evalua-
tion metrics in Figure 5.2. According to (preposition 5) the shorter the duration of interaction
one, the lesser risks a relying party need to take. Also, indirectly it means whatever the max-
imum possible freshness a PKC revocation advocates, without a shortest timeliness in its CSI
generation a relying party still has to take a considerable risk of using of a compromised PKC
(preposition 6). Therefore, the amount of time a CA needs to do interaction one is greatly deter-
mines the risk factor than interaction two. It is also clear from the figures that, the real amount
of time for windows of vulnerability is the sum of the amount of time needed to accomplish
interaction one and two, i.e. CSI generation and CSI distribution. In interaction three and four,
CSI availability is the first consideration, even if it is available there might be a network bottle-
neck temporarily; then relying party has to check CSI integrity. Finally if it is an off-line scheme
1
In some circumstances a PKC holder may not want to send a revocation notice to a CA even if its PKC needs
to be revoked. A fired employee can be a good example for this scenario, in such situation a CA has to revoke
the PKC and interaction one may not be exist as a step.
Figure 5.2: Some Evaluation Metrics of a PKC revocation Scheme
CSI-cache-size can be one factor of evaluation from the resource consumption and performance
point of view.
5.2.2 Versatile PKC Revocation Scheme Requirement Identification
This part classifies versatile PKC revocation schemes requirement into four categories: PKC
holder requirement, CA requirement, relying party requirement and general PKC revocation re-
quirements. The requirements listed below are extracted from the evaluation processes and over
all understanding of the PKC revocation mechanism discussed so far. In principle, versatility
has to accommodate opposite PKC revocation demands. Accommodating opposite requirements
might lead to a contradicting requirement specification.
For example in the previous section (see Section 5.2.1) it is said that the duration of windows
of vulnerability has to be minimized as much as possible on the first premises. On the second
premises it is defined as the duration of windows of vulnerability is the sum duration of timeli-
ness and duration of freshness. It means any thing which can reduce the duration of timeliness
and/or duration of freshness will also reduce the duration of windows of vulnerability. Frequent
CSI distribution can reduce the duration of freshness, i.e. fresh CSI can be fetched. On the other
hand, it is said that (preposition 6) increasing freshness (reduce the duration of freshness) is not
always desirable, since there are parties which does not need freshest CSI. If these statements
listed as a requirement for a PKC revocation scheme they look contradictory. In reality they are
not contradictory; instead they are alternative (versatile) approaches. In real life scenario, all
relying parties do not need fresh CSI, some constrained by CSI freshness some are not. There-
fore, a versatile revocation scheme requirement has to address these types opposite demands. A
requirement which says “freshness has to be maximized as possible” and “freshness has to be
managed, maximizing freshness is not always desirable” looks contradictory. However it can be
replaced with “freshness has to be maximized for those who need it and it must be minimized or
avoided for those who do not need it”˙
PKC holder requirements
The following short-list includes major PKC holder requirements discovered from the study
made so far with previous chapters from the PKC revocation perspective.
• Self revocation capabilities: Self revocation capabilities enable a PKC holder to revoke
its own compromised PKC.
• Minimized windows of vulnerability: After its PKC gets compromised, a PKC holder
likes CA to minimize windows of vulnerability to avoid misuse of its compromised PKC
by an adversary.
• Timely generation of CSI: to minimize PKC windows of vulnerability by minimizing

the amount of time needs to generate CSI (timeliness).
• Timely distribution of CSI: to minimize PKC windows of vulnerability by increasing

the frequency of CSI distribution (freshness), i.e. reducing the duration (its periodicity).
CA requirements
The following list includes the two major CA related requirements discovered from the discussion
made so far with previous chapters from the PKC revocation perspective.
• Cost reduction: CSI generation (computation cost), CSI distribution (communication

cost), CSI validation (computation cost) and over all CSI management cost must be min-
imized.
• Scalablity management: Scalability has to be managed dynamically in parallel with

the growth of relying party and PKC holders’ population increase.
Relying party requirements
The following short-list includes some of the major relying party related PKC revocation scheme
requirements discovered from the discussion made so far with previous chapters.
• CSI real time generation: The amount of time a CA needs to generate CSI has to be
in real-time, to minimize misuse of an already compromised PKC.
• Selective freshness: The degree of CSI freshness has to be decided by the relying party
freshness requirement.
• Shortest possible windows of vulnerability: The duration of windows of vulnerability

has to be as short as possible, to minimize misuse of an already compromised PKC. Factors
which determine windows vulnerability like timeliness and freshness has to be managed.
• on-line and off-line validation requirement: Since real-life application needs to op-
erate in both on-line and off-line manner (preposition 2), CSI validation schemes has to
incorporate both validation orientations.
• Getting full CSI evidence: a relying party has to get a validation answer for both
possible validation questions (preposition 3) like ‘’is this certificate healthy? ” or ‘’did
this PKC revoked?” The validation server need to have a capabilities, to say ‘’yes it is
healthy/no it is not healthy” or ‘’yes it is revoked/no it is not revoked” or the vice versa.
• Reduced bottleneck needs: a relying party has to get in a CSI validation service in a
acceptable delay, for that bottleneck has to be managed (preposition 7).
• CSI cache optimization: for off-line oriented PKC revocation schemes, the amount of
CSI cache they have to fetch/store has to be optimized through CSI segmentation or other
filtering mechanism.
• CSI update cost reduction: The amount of computational and communication cost a
relying party needs to enquire to update its CSI cache has to be reasonable (managed).
• Maintaining CSI integrity: the integrity of a CSI upon its generation, distribution and
in relying party cache (for off-line schemes) has to be properly protected through crypto-
graphically sound mechanism like signature or hash (see Section 4.8).
• Maintaining CSI availability: A CSI distribution/validation server(s) have to be reli-

able and designed in a way that they can still be available in a worst case scenario.
• Promoting lazy revocation: Relying parties need not to validate its cached CSI unless
the CSI required for validation (see Section 4.8).
General design requirements
The following short-list includes the major architectural related PKC revocation scheme require-
ments discovered from the evaluation made so far with the selected PKC revocation schemes.
• Simplicity has to be maintained: simplicity has to be maintained in a reasonable

manner to mitigate the security drawback which can come because of complexity (prepo-
sition 1).
• Coverage maximization: the scope of a versatile PKC revocation scheme has to be

maximized as possible to accommodate the real life versatile revocation need.
• Network usage minimization: A usable PKC revocation scheme has to use infrastruc-
tural resources in an efficiently way to cut costs and improve performance.
• Revocation information minimization: An efficient PKC revocation scheme does not

let a relying party to get unnecessary CSI (i.e. CSI validation information out of relying
party CSI validation needs scope), it has to be minimized through partitioning or let the
user to get a constant CSI for the PKC it wants to validate.
• Accommodating CSI partitioning plus constant CSI: A versatile PKC revocation

has to accommodate both CSI partitioning and at the same time provide specific CSI
validation answers. For online CSI validation, relying party CSI validation requirement
is clearly visible (a validation server can know which PKC a user wants to verify). So
it’s possible to provide a constant CSI validation answer only for the PKC that needs to
be validated, with no more or less other validation inclusion or exclusion. However, for
off-line PKC validation relying party PKC validation need can not be known before hand,
so CSI partitioning has to applied, since a constant validation is impossible.
• Accommodating dynamic CRL partitioning: from the performance point of view a

versatile revocation scheme has to accommodate a dynamic (if possible smart) partitioning
to balance the load balancing between partitions (segments).
• Promote incremental (non redundant) CRL update: a PKC revocation scheme

has to promote an incremental CSI update and reduce a redundant CSI update, since
5.3. PKC REVOCATION SCHEMES INTEGRATION 67
it can potentially introduce un-necessary a cost for the relying party and/or CSI reposi-
tory/validation server.
• Avoiding single CSI distribution point: A PKC revocation infrastructure does not
be designed in a centralized manner where the entire validation request goes to a single
CSI repository/validation server. Since a centralized approach is not reliable from the
security point of view (DoS attack is possible) and also it is hard to manage (minimize)
scalability with centralized approach. Promoting geographically distributed CSI distribu-
tion/validation is must requirement a PKC revocation scheme has to accommodate.
• Accommodating non-uniform CRL expiration: Since designing all CSI to expire at

the same time creates a bottleneck in the PKC revocation infrastructure, since following
a constant CSI expiration a constant validation request peak validation request rate can
happen. As a result, designing CSI expiration in a non uniform or overlapped manner is
necessary to balance the CSI validation/ update request rate in a periodic PKC revocation
schemes.
• Accommodating push and pull CSI delivery: A versatile PKC revocation has to
operate in a way it can distributed its CSI in explicit manner (push delivery, like post
distribution) and implicit manner (pull delivery). The usual reason is real life applica-
tion needs both distribution schemes. The un-widely used push delivery (because of its
practical infeasibility) can be the only means to get the latest CSI in mission critical en-
vironments which needs real-time CSI as it happens, not as they want to validate as it is
done in pull oriented schemes.
• Balancing communication burden: A sound PKC revocation design has to balance

the communication burden existed from CA-to-distribution/validation server and from
directory-to-relying.
• Signature minimization: A sound PKC revocation design has to minimize the number
of signature which needs to be signed upon validation of on-line PKC revocation schemes.
5.3 PKC Revocation Schemes Integration

The integration of already discussed PKC revocation schemes can be understand formally by
investigating their dependency relationship. As discussed before in (see Section 3.1) Traditional
CRL is the starting point for the history of PKC revocation scheme. Following Traditional CRL
researchers does a considerable work to improve Traditional CRL with variant CRL schemes
and hybrid CRL based PKC revocation schemes. Some researchers also propose a PKC revoca-
tion schemes which is completely deviated from the design foundation advocated by Traditional
CRL. Understanding the relationship existed between these PKC revocation schemes simplifies
the integration. Figure 5.3 and 5.4 illustrate the dependency existed between these schemes.
Figure 5.5 and 5.6 illustrate the improvement dependency exist among different PKC revo-
cation schemes.The following section will cover the improvement dependency existed between
off-line and on-line PKC revocation schemes separately. However a versatile revocation scheme
has to incorporate both Traditional CRL based schemes (off-line schemes) and non-CRL PKC
revocation schemes (on-line).
Figure 5.3: Traditional CRL based PKC revocation schemes dependency

Improvement Dependency among Traditional CRL based PKC Revocation Schemes
As illustrated in Figure 5.5, six major improvements proposed by different researchers (PKC
revocation schemes) which are: (1) revocation information segmentation (see Section 4.2), (2)
non-uniform CRL expiration (see Section 4.7), (3) incremental CSI update (see Section 4.5),
(4) aggregated CRL access point (see Section 4.6), (5) CRL with short life (see Section 4.8)
and (6) excluding PKC expiration plus publishing CSI together with the PKC (see Section 4.9).
Except the last two improvements the first four improvements conceptualy can go together,
i.e. it is theoretically possible to integrate them. Conceptually, it is possible engineer a PKC
revocation scheme which publishes a segmented CSI, where its CSI expiration done in a non-
uniform manner with incremental CSI update. If it is viewed from multiple PKC validation
service providers, it is also possible to aggregate the CSI in a centralized server. However, the
concept of centralized CSI access point has security, performance, and availability shortcomings.
From the integration point of view, the concept advocated by Windowed revocation scheme
and Black-list PKC revocation schemes can not be integrated with other schemes, since it has
completely opposing approach. However both Windowed revocation scheme and Black-list PKC
revocation schemes can be a stand alone part of the versatile PKC revocation scheme to include
their unique contribution into the versatile PKC revocation scheme. It is possible mission
critical CRL based systems might take advantage of Windowed Revocation push CRL delivery
as advantage. Where as, for systems where mass PKC revocation is common Black-list PKC
revocation scheme might be advantageous. Therefore, based on the discussion in this thesis done
so far it is possible to have only three Traditional CRL based hybrid PKC revocation schemes
can be extracted after integration. The three major theoretically root offline PKC revocation
schemes are: (1) A hybrid scheme out of Partitioned CRL, Over-Issued CRL and Delta CRL,
(2) Windowed Revocation and (3) Black-list CRL.
However, practically integrating Partitioned CRL, Over-Issued CRL and Delta CRL can be a
complex processes, since in addition to integrating these three schemes it is also necessary to
integrate their hybrids. For example, to get one version of Partition CRL, it is necessary to
integrate Dynamic CRL distribution Point and Redirected CRL together with Partition CRL.
The same has to be done with Over-Issued CRL and Delta CRL. On the other hand, integrating
Indirect CRL into any existing PKC revocation scheme is a simple task. That is because;
Indirect CRL is not really a stand alone PKC revocation scheme as other PKC revocation
schemes. It is a mechanism designed to facilitate distribution of CSI, so it can be used for the
hybrid scheme without (or with no) heavy integration design. Indirect CRL can be used with
Windowed revocation, but it is impossible to use it with Black-list CRL since it apaches CSI
distribution from a different angle (see Section 4.9).
Figure 5.4: Non CRL based PKC revocation schemes dependency

Figure 5.5: Traditional CRL based PKC revocation schemes improvement dependency
Improvement Dependency among Non-CRL PKC Revocation

Schemes
In comparison with Traditional CRL based schemes, Non-CRL PKC revocation schemes exhibit
more diversity than similarity. Researchers also done little in integrating on-line based schemes
in comparison with an attempt they made to integrate offline (Traditional CRL) based schemes.
The improvement dependency in Non-CRL PKC revocation scheme only exhibited in their
Figure 5.6: Non CRL based PKC revocation schemes improvement dependency
variant (offspring) schemes only; there is almost no cross scheme improvement dependency
among Non-CRL PKC revocation scheme discussed in this thesis. As a result, integration be-
comes a challenging endeavor with Non-CRL PKC revocation schemes. Among Traditional CRL
schemes, Over-Issuing Delta CRL with Distribution points is a good example of cross scheme
improvement dependency which is basically an out put of there completely separate PKC revo-
cation schemes (see Figure 4.3 and 4.5).
As illustrated in Figure 5.6, there are four major conceptually root approaches, which are: (1)
Traditional OCSP based (see Section 4.15), (2) CRS based (see Section 4.17), (3) Tree based
(see Section 4.19) and (4) SEM based (see Section 4.20).
One advantage of Non-CRL PKC revocation schemes is it is easy to integrate the root scheme
with its hybrids, which is because the improvement dependency is usually a minor modification
over the mechanism used by the root scheme. CRT can be a good example to support this fact.
The problem of CRT approach which is re-computing the entire CRL every time a new CRL
entry joins is improved by 2-3 Certificate Revocation Tree without making major architectural
improvement (see Section 4.19 and 4.19.1). From the integration point of view, it is easy to
integrate CRT with its hybrid (2-3 Certificate Revocation Tree), than integrating Delta CRL
with its hybrids (Freshest CRL and Sliding Window Delta CRL) which introduce a major archi-
tectural improvement over the original design of Delta CRL. Finally, even if Trusted Directories
categorized under online (Non-CRL based) PKC revocation schemes, it can not contribute much
for a versatile PKC revocation scheme. A PKI which uses Trusted Directory approach to com-
municate a PKC revocation is the same as a PKI with no PKC revocation scheme (see Section
4. 21).
In summery, with conceptual integration only seven root PKC revocation hybrid schemes are
extracted, out of twenty five2 different PKC revocation schemes explored . The complete list of
the seven major conceptually unified PKC revocation schemes are listed below.
1. A hybrid of Partitioned CRL, Over-Issued CRL and Delta CRL

2. Windowed Revocation
3. Black-list CRL
4. A hybrid of OCSP and its variants
5. A hybrid of CRS and its variants
6. A hybrid of CRT and its variants
7. SEM
Creating cross-scheme integration among this seven PKC revocation scheme is desirable if there
is a need to come up with a single PKC revocation. However, because of their contradictory
approach toward PKC revocation it is almost infeasible to integrate them. It can also argue
that, out of the seven extracted schemes, based on the evaluation (from Chapter 4) some of
them do not contribute much in practical application. For example, Windowed Revocation
even if it attempts to provide a holistic solution, its practical feasibility is highly commented as
impractical (see Section 4.8). Black-list revocation scheme also shortfalls for its huge resource
2
The number twenty five includes the four additional PKC revocation schemes discussed in brief in section
4.6.1, 4.15.1, 4.17.1, and 4.19.1.
consumption in an environment where PKC revocation is in common place (see Section 4.9).
CRS also faces a similar impracticality problem comment (see Section 4.17).
Chapter 6
Conclusion & Future Works
This chapter includes result discussion and future works of the thesis.
6.1 Conclusion
PKI has a number of open problems, despite its existence in almost every security solutions
today and its three decade maturity. Lacking of a sound PKC revocation scheme is among the
open problems. In an attempt to solve this problem, researchers did enormous amounts of work,
and then the solution ends up with endless new idea proposals and floods of new schemes. What
is missing within this fusion of new ideas and schemes is an effort toward integrating the existing
schemes. This thesis is an attempt to make some contribution to fill this gap, in addition to
evaluating, the existing PKC revocation schemes.
Throughout the course of this thesis research there were a number of challenges ranging from
wildly discussed misguided approaches toward solutions to confused naming of a PKC revoca-
tion schemes as documented in Appendix A. Some of the misconceptions can potentially lead
to a misunderstanding of the actual problem surrounding the problem area. To mention some
of them, some researchers believed that improving performance and resource usage factors can
improve scalability. Also some researchers believed that, through their new PKC revocation
scheme they can totally avoid scalability problem. The reality is very far away from these two
and any other related ideas, even if they contribute towards scalability improvement it is only a
temporary solution. Scalability is not a technical problem; it is an infrastructural management
problem. With a well coordinated and distributed infrastructural management almost any type
of PKC revocation scheme can be scalable. Scalability has to be seen as a growth in demand for
a service, and it can only be solved by expanding the service in a distributed manner. The other
misconception is; it is widely advocated that increasing CSI freshness is the ultimate solution to
solve the PKC revocation problem from its root. It seems sound solution in the front, since with
high CSI freshness the risk of using a compromised PKC can be reduced. The two drawbacks
of this thinking are; first freshness is totally dependent on the timeliness of CSI generation.
75
76 CHAPTER 6. CONCLUSION & FUTURE WORKS
Whatever the freshness a PKC revocation scheme can give in real-time or in seconds, without
timely CSI generation upon PKC compromise it can not contributing toward minimizing the
risk. Most of the evaluated PKC revocation schemes do not have a clearly defined specification
to manage the timeliness of CSI generation. Second, CSI freshness is not an all-time requirement
for all possible relying party domains. Some favor freshness some do not, since CSI freshness
by itself has network and process overhead costs. It can not be favored by those who do not
need fresh CSI. So in parallel with improving freshness, CSI generation timeliness and selec-
tively applying CSI freshness has to be considered as a closely tied factor. In addition, most
discussions regarding network bottleneck attempt to find a (new) scheme which can totally avoid
network bottleneck. In reality a network bottleneck can not be avoided, rather it is advisable
to find how it can be managed when it is happening or expected to happen with some kind of
measuring guides. The tradeoffs exist between timeliness; freshness and network bottleneck also
considerably determine the windows of vulnerability of a PKC revocation scheme. Whenever
they are badly managed, they can potentially increase the theoretical duration of the windows
of vulnerability in practice.
Another challenge is finding the balance between simplicity and multiple PKC revocation scheme
functional requirements which can potentially introduce complexity. Traditional CRL simplicity
is regarded as a major advantage of the scheme, which makes it usable even if it has a number
of security, performance and management drawbacks. An attempt to mitigate the drawbacks
of Traditional CRL and PKI in general gave birth of more complex PKC revocation schemes
and alternative PKIs like PGP and SPKI/SDIS. For example, need for self revocation and the
idea of positive CSI mainly derived from these alternative PKIs and adopted by new generation
X.509 PKC revocation schemes. Incorporating idea like positive CSI in addition to the usual
negative CSI into a PKC revocation scheme can surly introduce complexity. Also letting a PKC
holder to revoke its own PKC in addition to the usual authoritative CA driven PKC revocation
can be another source of complexity. Self revocation, positive CSI or other innovative approach
like immediate revocation by SEM definitely do good for a better and versatile PKC revocation
scheme at a cost of complexity.
In addition to the complexity, maintaining cross-scheme integration among PKC revocation

scheme is another big challenge for several reasons. One reason is the incompatibility of tech-
niques used among different PKC revocation schemes. More specifically some revocation schemes
propose a more deviated revocation idea than the usually accepted and practiced PKC revo-
cation standards and approaches. For example, Black-list PKC revocation scheme propose to
publish CRL (the black-list) together with the PKC. CRS attempt to substitute traditional CSI
validation signature with hash value. SEM introduces a concept similar with SPKI/SDSI, in
which a semi-trusted server and PKC holder has to cooperate in every use of the PKC. The SEM
architecture is mainly devised to enable immediate revocation a reality, however its approach
can not lineup with the accepted and well practiced PKC revocation standards. So conceptually
integrating Black-list, CRS, or SEM type of PKC revocation scheme with the rest of the PKC
revocation scheme might need a considerable work (if it is possible) and it is infeasible. However,
6.2. FUTURE WORK 77
integration among PKC revocation schemes which is basically a variant to certain PKC revo-
cation scheme is possible. For example, integrating Partition CRL, Dynamic CRL Distribution
Point and Redirected CRL is as simple as adding some simple features to Partition CRL. The
reason is both schemes Dynamic CRL Distribution Point and Redirected CRL created in an
attempt to improve Partition CRL, so they have a lot in common. With some PKC revocation
schemes in addition to variant integration, cross-scheme integration is also possible. Over-Issued
Segmented CRL, Over-Issued Delta CRL, and Over-Issued Delta CRL with Distribution Point
are a good example for cross-scheme integration.
Even if it is not possible to come up with a single integrated versatile PKC revocation schemes
because of the above mentioned facts, it is still conceptually possible to integrate variant and
hybrid PKC revocation schemes. In this thesis seven major integration groups are discussed.
Among the seven major groups three of them only represent a single PKC revocation scheme.
It can be arguer that those PKC revocation schemes do not have variant schemes plus they
can not be integrated with other schemes. On the other hand the conceptual integration of one
group manages to incorporate up to ten different PKC revocation schemes into one conceptual
unit. Based on the research done so far, Traditional CRL based PKC revocation schemes are the
most versatile and easy to integrate, where as Non-CRL PKC revocation schemes are the list
versatile and hard to integrate. As can be seen from the analysis done on the selected Non-CRL
PKC revocation schemes there is no cross-scheme integration attempts done so far in any of
the studied Non-CRL schemes. For example, there is no attempt done to integrate OCSP with
CRT or CRS. However, the do have a variant schemes which can be integrated each other for a
better PKC revocation scheme. For example it is possible and simple to integrate OCSP with
OCSP-X and OCSP-D, since both schemes devised to improve OCSP.
6.2 Future Work

This thesis contributes in formulating a consistent PKC evaluation metrics, deriving a gener-
alized requirement for a versatile PKC revocation scheme and centrally the actual evaluation
of different PKC revocation schemes. It argued and analyzes the tradeoffs and misconceptions
exist among PKC revocation schemes. It also classified and finally grouped PKC revocation
schemes that are believed to be conceptually integrated into a unified versatile scheme. What
is not specifically studied and discussed in this thesis is how they can be integrated in design.
Therefore, the possible future research work as extension of this thesis work can be finding a
technical design intersection point to come up with a practically unified PKC revocation scheme
design. As a result, standardization of PKC revocation process, integration among domains and
implementation can be considerably simple.
Index
Black-list, 12, 41 Over-issued Delta CRL, 46

Black-list CRL, 41 Over-Issued Segmented CRL, 45
Bottleneck, 24
Partitioned CRL, 31
Certificate of health, 12 PGP, 10
Challenge-response, 2 PKIX, 8
CRLReason Code, 15, 31 Play-Back attack, 2
CRS, 53 Pretty Good Privacy, 5
CRT, 56
Redirect CRL, 34
D-OCSP, 53 Revocation window, 40
Delta CRL, 36
Short-Lived certificates, 19
Designated key revoker, 10
Sliding Window Delta CRL, 49
Digital signature, 7
SPKI/SDSI, 5, 11
Distinguish Name, 8
Substitution attack, 15
Dynamic CRL Distribution Points, 33
Suicide bureau, 11
Freshest CRL, 43 Suicide note, 12
Global namespace, 11, 14 Traditional CRL, 30

Trusted Directory, 19
Impersonation, 1, 2
IP spoofing, 1 Web of Trust, 13
White-list, 12
Key compromise agent, 11 Windowed Revocation, 40
Lazy revocation, 40 X.500, 8, 10, 11, 14

Local namespace, 8, 11 X.509, 5, 8, 14
Man-In-The-Middle, 2
Masquerading attack, 51
Non-Repudiation, 7
NOVOMODO, 55
OCSP, 50
OCSP responder, 50
Over-Issued CRL, 38
78
Bibliography
[ACL+ 99] R. J. ANDERSON, B. CRISPO, J.-H. LEE, C. MANIFAVAS, JR. V. MATYAS,

and F. PETITCOLAS. The global internet trust register. Master’s thesis, MIT,
Cambridge., 1999.
[AGT01] A. Anagnostopoulos, M. Goodrich, and R. Tamassia. Persistent authenticated

dictionaries and their applications. In Proceedings 4th Information Security Con-
ference (ISC 2001), volume 2200, pages 379–393, 2001.
[AL02] C. ADAMS and S. LLOYD. Understanding PKI: Concepts, Standards, and De-
ployment Considerations. Addison-Wesley Longman Publishing Co. Inc., Boston,
MA, 2 edition, 2002.
[ALO98] W. Aiello, S. Lodha, and R. Ostrovsky. Fast digital identity revocation (extended
abstract). In Advances in Cryptology CRYPTO98, pages 137–152, 1998.
[Ass96] American Bar Association. Digital signature guidelines: Legal infrastructure for
certification authorities and secure electronic commerce, 1996.
[AZ98] C. ADAMS and R. ZUCCHERATO. A general, flexible approach to certificate

revocation. Technical report, Entrust White Paper, 1998.
[BCDR02] M. BURNSIDE, D. CLARKE, S. DEVADAS, and R. RIVEST. Distributed

spki/sdsi-based security for networks of devices. Technical report, MIT, Cam-
bridge, 2002.
[BCF+ 94] S. BERKOVITS, S. CHOKHANI, J. A. FURLONGM, A. GEITER, and J. C.

GUILD. Public key infrastructure study: Final report. Technical report, MITRE,
Virginia, 1994.
[BDTW01] D. Boneh, X. Ding, G. Tsudik, and C. Wong. A method for fast revocation of
public key certificate and security capabilities. In The 10th USENIX Security
Symposium, 2001.
[BGH+ 93] BIRD, GOPAL, HERZBERG, JANSON, KUTTEN, MOLVA, and YUNG. Sys-
tematic design of a family of attack-resistant authentication protocols. IEEE
Journal on Selected Areas in Communications., 11(5):679–693, 1993.
79
80 BIBLIOGRAPHY
[BH98] S. BERKOVITS and J. C. HERZOG. A comparison of certificate validation meth-

ods for use in a web environment. Mitre technical report, The MITRE Corpora-
tion, Bedford, Massachusetts, 1998.
[BHR99] S. BOEYEN, T. HOWES, and P. RICHARD. Internetx.509 public key infrastruc-

ture operational protocols ldapv2. RFC 2559, 1999.
[BIS02] M. BISHOP. Computer Security: Art and Science. Boston. Addison Wesley
Professional, 2002.
[BRA00] S. BRANDS. Rethinking public key infrastructures and digital certificates: Build-
ing in privacy. Technical report, MIT, Cambridge, 2000.
[CCI88] CCITT. Recommendation x.509: The directory - authentication framework. Tech-

nical report, CCITT, 1988.
[CD03] C. CREPEAU and C. R. DAVIS. A certificate revocation scheme for wireless

ad hoc networks. proceedings of acm workshop on security of ad hoc and sensor
networks. pages 54–61. ACM Press, 2003.
[C.E05] C.ELLISON. SPKI/SDSI. Encyclopedia of Cryptography and Security. The

Netherlands. Eindhoven University of Technology, 2005.
[CER96] CERT. Cert advisory. In CERT Advisory CA-96.21: TCP SYN Flooding and IP
Spoofing Attacks. 1996.
[COO98] D. A. COOPER. A closer look at revocation and key compromise in public key
infrastructures. In Proceedings of the 21st National Information Systems Security
Conference, pages 555–565, 1998.
[COO99] D. A. COOPER. A model of certificate revocation. In Fifteenth Annual Computer

Security Applications Conference (ACSAC’99), pages 256–264, 1999. ACM Press.
[COO00] D. A. COOPER. A more efficient use of delta-crls. Proceedings of the 2000 IEEE
Symposium on Security and Privacy, pages 190–202, 2000.
[Cor] CoreStreet. Distributed certificate validation. White Paper.
[DA99] T. DIERKS and C. ALLEN. The tls protocol version 1.0. RFC 2246, 1999.
[DH76] W. DIFFIE and M. HELLMAN. New directions in cryptography. information

theory. IEEE Transactions on Information Theory, 22(6):644–654, 1976.
[DR06] T. DIERKS and E. RESCORLA. The tls protocol version 1.2. RFC 4346, 2006.
[EFL+ 99] C. ELLISON, B. FRANTZ, B. LAMPSON, R. RIVEST, B. THOMAS, and

T. YLONEN. Spki certificate theory, 1999. RFC 2693.
[ELL99] C. ELLISON. Spki requirements. RFC 2692, 1999.

BIBLIOGRAPHY 81
[ELL02] C. ELLISON. Improvements on conventional pki wisdom. In Proceedings of the

1st Annual PKI Research Workshop, 2002.
[ELL03] C. ELLISON. Implications and problems with identity in pki. In J. Camp, editor,
Digital Government Civic Scenario Workshop, 2003.
[EMR05] S. EICHLER and B. MULLER-RATHGEBER. Performance analysis of scalable

certificate revocation schemes for ad hoc networks. In Proceedings of the The
IEEE Conference on Local Computer Networks 30th Anniversary, page 382391,
2005.
[FP00] E. FALDELLA and M. PRANDINI. A novel approach to on-line status authen-

tication of public-key certificates. In 16th Annual Conference Computer Security
Applications, page 270277, 2000.
[GCD+ 05] H. W. GO, P. Y. CHAN, Y. DONG, A. F. SUI, S. M. YIU, L. C. K HUI, and

V. O. K. LI. Performance evaluation on crl distribution using flooding in mobile
ad hoc networks (manets). In ACM Southeast Regional Conference, Proceedings
of the 43rd Annual Southeast Regional Conference, volume 2, pages 75–80. ACM,
2005.
[Gem97] P. Gemmel. An introduction of threshold cryptography. In CryptoBytes, A Tech-

nical Newsletter of RSA Laboratories, 2(7), 1997.
[GTS01] M. Goodrich, R. Tamassia, and A. Schwerin. Implementation of an authenticated

dictionary with skip lists and commutative hashing. In Proceedings of DARPA
DISCEX II, 2001.
[GW03] M. GRAFF and K. WYK. Secure Coding: Principles and Practices. OReilly,
2003.
[HAS00] V. HASSLER. Security Fundamentals for E-Commerce. Artech House Publishers,

Norwood, 2000.
[HB99] P. Hallam-Baker. Ocsp extensions. IETF Internet Draft, 1999.
[HBF98] P. Hallam-Baker and W. Ford. Internet x.509 public key infrastructure: Enhanced
crl distribution options. IETF PKIX Working Group, Internet Draft, 1998.
[HH99] R. HOUSLEY and P. HOFFMAN. Internetx.509 public key infrastructure oper-

ational protocols: Ftp and http. RFC 2585, 1999.
[HOP01] P. HOPE. Certificate revocation. In The Megazin of USENIX and SAGE, vol-
ume 26, pages 36–40. 2001.
[HP01] R. HOUSLEY and T. POLK. Planning for PKI: Best Practices Guide for De-
ploying Public Key Infrastructure. John Wiley & Sons, 2001.
82 BIBLIOGRAPHY
[HPFS02] R. HOUSLEY, W. POLK, W. FORD, and D. SOLO. Internet x.509 public key
infrastructure: Certificate and certificate revocation list (crl) profile. RFC 3280,
2002.
[IGS+ 03] J. ILIADIS, S. GRITZALIS, D. SPINELLIS, D. De. COCK, B. PRENEEL, and

D. GRITZALIS. Towards a framework for evaluating certificate status information
mechanisms. Computer Communications, 26(16):1839–1850, 2003.
[INC97] MASTERCARD INC. Set secure electronic transaction specification book 1: Busi-
ness description. Technical report, MASTERCARD INC., 1997.
[ISKP00] J.S. ILIADIS, D. SPINELLIS, S. KATSIKAS, and B. PRENEEL. A taxonomy

of certificate status information mechanisms. Proceedings of Information Security
Solutions Europe ISSE 2000, 2000.
[IT97] ITU-T. Recommendation x.509: The directoryauthentication framework. Tech-

nical report, ITU-T, 1997.
[IT00] ITU-T. Recommendation x.509: The directorypublic key and attribute certificate
frameworks. Technical report, ITU-T, 2000.
[KA98] S. KENT and R. ATKINSON. Security architecture for the internet protocol.
RFC 2401, 1998.
[KAN99] H. KIKUCHI, K. ABE, and S. NAKANISHI. Performance evaluation of public key

certificate revocation system with balanced hash tree. In Proceedings of the 1999
International Workshops on Parallel Processing (ICPP), pages 204–209, 1999.
[Koc98] P. Kocher. On certificate revocation and validation. In Preceding of the 2nd

International Conference on Financial Cryptography, 1465:172177, 1998.
[KOH78] L. M. KOHNFELDER. Towards a practical public-key cryptosystem. Master’s

thesis, MIT, Cambridge, 1978.
[KOR02] K. KORTESNIEMI. Validity management in spki. In Proceedings of the 1st

Annual PKI Research Workshop, 2002.
[KR00] J. KUROSE and K. ROSS. Computer Networking: A Top-Down Approach Fea-

turing the Internet. Addison-Wesley Longman Publishing Co. Inc, 2000.
[KWO02] T. KWON. Impersonation attacks on software-only two-factor authentication

schemes. IEEE Communications Letters, 6(8):358– 360, 2002.
[LBT02] C. Y. LIAU, S. BRESSAN, and K. TAN. Efficient certificate revocation: A p2p

approach. ASIAN 2002 Workshop on Southeast Asian Computing Research, 2002.
BIBLIOGRAPHY 83
[LK01] A. LEVI and C.K. KOC. Reducing certificate revocation cost using npki. trusted
information, the new decade challenge. In IFIP TC11 16th International Con-
ference on Information Security, pages 51–59, Boston, 2001. Kluwer Academic
Publishers.
[MAC03] J. L. MACMICHAEL. A survey and security strength classification of pki certifi-

cate revocation management implementations. Master’s thesis, Naval Postgradu-
ate School, Monterey, 2003.
[MAM+ 99] M. MYERS, R. ANKNEY, A. MALPANI, S. GALPERIN, and C. ADAMS. X.509

internet public key infrastructure online certificate status protocol ocsp. RFC
2560, 1999.
[Mer89] R. Merkle. A certified digital signature. Advances in Cryptology: CRYPTO 89,

1989.
[MFC02] J. L. MUOZ, J. FORNE, and J. C. CASTRO. Evaluation of certificate revocation

policies: Ocsp vs. overissued-crl. Proceedings. 13th International Workshop on
Database and Expert Systems Applications, pages 511–515, 2002.
[MIC96] S. MICALI. Efficient certificate revocation. Technical report, MIT, Cambridge,

1996.
[Mic02] S. Micali. Novomodo: Scalable certificate validation and simplified pki manage-
ment. In 1st Annual PKI Research Workshop, pages 15–25, 2002.
[MJ00] P. MCDANIEL and S. JAMIN. Windowed certificate revocation. Proceedings of

IEEE INFOCOM 2000, Nineteenth Annual Joint Conference of the IEEE Com-
puter and Communications Societies, pages 1406–1414, 2000.
[MM03a] M.C. MOROGAN and S. MUFTIC. Certificate management in ad hoc networks.

In 2003 Symposium on Applications and the Internet Workshops, page 337341,
2003.
[MM03b] M.C. MOROGAN and S. MUFTIC. Certificate revocation system based on peer-
to-peer crl distribution. In The 9th International Conference on Distributed Mul-
timedia Systems, Florida, 2003.
[MYE98] M. MYERS. Revocation: Options and challenges. Second International Confer-

ence on Financial Cryptography, pages 165–171, 1998. Springer-Verlag.
[NH05] R. Nielsen and B.A. Hamilton. Observations from the deployment of a large scale
pki. 4th Annual PKI R&D Workshop, 2005.
[NN00] M. NAOR and K. NISSIM. Certificate revocation and certificate update. IEEE
Journal on Selected Areas in Communications, 18:561–570, 2000.
84 BIBLIOGRAPHY
[NN05] M. NAKHJIRI and M. NAKHJIRI. AAA and Network Security for Mobile Access:
Radius, Diameter, EAP, PKI, and IP Mobility. John Wiley & Sons Ltd, West
Sussex, 2005.
[OFHJ97] P. C. VAN OORSCHOT, W. S. FORD, S. W. HILLIER, and J.OTWAY. Method

for efficient management of certificate revocation lists and update information.
United States Patent No. 5,699,431, 1997.
[oITL02] United Nations Commission on International Trade Law. Uncitral model law on
electronic signatures with guide to enactment 2001, 2002.
[P.G02] P.GUTTERMAN. Pki: It’s not dead, just resting. IEEE Computer, 35(8):41–49,
2002.
[PK93] R. PERLMAN and C. KAUFMAN. Method of issuance and revocation of certifi-

cate of authenticity used in public key networks and other systems. United State
Patent 5,261,002, 1993.
[PtCotEU99] European Parliament and the Council of the European Union. Directive
1999/93/ec of the european parliament and of the council on a community frame-
work for electronic signatures, official journal of the european communities, 1999.
[RAM99] B. RAMSDELL. S/mime version 3 certificate handling. RFC 2632, 1999.
[REV98] R. L. REVEST. Can we eliminate certificate revocation lists? In Proceedings of

Financial Cryptography 98, (1464), 1998. Springer Lecture Notes in Computer
Science.
[RJK+ 00] A. RNES, M. JUST, S. J. KNAPSKOG, S. LLOYD, and H. MEIJER. Selecting

revocation solutions for pki. In Proceedings of NORDSEC 2000 Fifth Nordic
Workshop on Secure IT Systems, Reykjavik University, 2000.
[RL96] R. L. REVEST and B. LAMPSON. A simple distributed security infrastructure.

Technical report, MIT, 1996.
[RMP97] G-C. ROMAN, P. J. MCCANN, and J. Y. PLUN. Mobile unity: Reasoning and
specification in mobile computing. In ACM Transactions on Software Engineering
and Methodology, volume 6, page 250282, 1997.
[RS04] A. Rojanapasakorn and C. Sathitwiriyawong. A performance study of over-issuing

delta-crls with distribution points. In Proceedings of the 18th International Con-
ference on Advanced Information Networking and Applications, volume 2, page
178. IEEE Computer Society, 2004.
[SB] A. J. Slagell and R. Bonilla. Pki scalability issues.
[SB06] A. Slagell and R. Bonilla. A survey of pki components and scalability issues.
Workshop on Information Assurance (WIA ’06), 2006.
BIBLIOGRAPHY 85
[SBY06] A. SLAGELL, R. BONILLA, and W. YURCIK. A survey of pki components

and scalability issues. 25th IEEE International Performance, Computing and
Communications Conference. IPCCC 2006, 2006.
[SCH95] B. SCHNEIER. Applied Cryptography: Protocols, Algorithms, and Source Code

in C. John Wiley & Sons, Inc., NY, 2 edition, 1995.
[SHMM04] J. R. SAETA, J. HERNANDO, O. MANSO, and M. MEDINA. Securing certificate

revocation through speaker verification. the certiver project. Proc. COST 275
Workshop, pages 47–50, 2004.
[SR03] C. Sathitwiriyawong and A. Rojapasakorn. A certificate revocation method us-

ing over-issuing delta-crls with distribution points. In Proceedings of the 3rd In-
ternational Symposium on Communications and Information Technologies, pages
750–754, 2003.
[S.T93] S.T.KENT. Internet privacy enhanced mail. Communications of the ACM,

36(8):48–60, 1993.
[Tj04] T. Tjstheim. A critical view on public key infrastructure. Master’s thesis, Institute
of Informatics, University of Bergen, 2004.
[WIL99] J. WILLEMSON. Certificate revocation paradigms. Technical report, Cybernet-

ica, 1999.
[WLM00] R. N. WRIGHT, P. D. LINCOLN, and J. K. MILLEN. Efficient fault-tolerant

certificate revocation. In Proceedings of the 7th ACM conference on Computer
and communications security, pages 19–24, NY, 2000. ACM Press.
[WOH00] P. WOHLMACHER. Digital certificates: A survey of revocation. Proceedings of

the 2000 ACM Workshops on Multimedia, pages 111–114, 2000.
[ZHA06] M. ZHAO. Delta crl enhancement. United States Patent No, 7,124,295, 2006.
[ZHE03] P. ZHENG. Tradeoffs in certificate revocation schemes. ACM SIGCOMM Com-

puter Communication Review, 33:103–112, 2003.
[ZIM95] P. ZIMMERMANN. The Official PGP Users Guide. MIT, Cambridge, 1995.
Appendix A
Alternative Names
There is a wide spread ambiguous and inconsistent naming is used most PKC revocation lit-
eratures. Since most proposed schemes are not standardized it is very difficult to choose one
name for a single PKC revocation scheme out of the existing alternative names used by different
researchers to refer to the same scheme. In this thesis as much as possible a consistent naming
is followed, however to avoid confusion the following table lists mostly used alternative naming
and acronyms for easy lookup.
Alternatively used PKC Revocation Names Name used in This Thesis
23CRT : 23 Certificate Revocation Tree
ACRL : Augmented CRL
Certificate Revocation 2-3 : 23 Certificate Revocation Tree
Certificate Revocation Status (CRS) : Certificate Revocation Status Directory (CRSD)
Certificate Revocation System (CRS) : Certificate Revocation Status Directory (CRSD)
CRL Distribution Point : Partitioned CRL
CRL DP : Partitioned CRL (CRL Distribution Point)
CRS Directory : Certificate Revocation Status Directory (CRSD)
DCRL : Delta CRL
Distribution Point CRL : Partitioned CRL
Distribution Points : Partitioned CRL
Enhanced CRL Distribution Options : Dynamic CRL Distribution Point
Enhanced CRL Distribution Points : Dynamic CRL Distribution Point
FCRL : Freshest CRL
ICRL (iCRL) : Indirect CRL
Naors and Nissims scheme : 23 Certificate Revocation Tree
Redirected Pointers : Redirect CRL
Segmented CRL : Partitioned CRL
Skip-Lists : Skip-List Based Authenticated Directories
SWD CRL : Sliding Window Delta-CRL
Open CRL Distribution Point : Dynamic CRL Distribution Points
On-Line Certificate Status Checking on-line : Certificate Status Protocol (OCSP)
Traditional OCSP (T-OCSP) : on-line Certificate Status Protocol (OCSP)
Hierarchical Certificate Revocation Scheme (HCRS) : Fast Digital Identity Revocation
Authenticated Dictionary (AD) : 23 Certificate Revocation Tree
86

Girma Nigusse

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Girma Nigusse

Cargado por

Copyright:

Formatos disponibles

Master’s Thesis1

Evaluating Public Key Certificate

Girma Enideg Nigusse

Submitted in Partial Fulfillment of the

the Department of Computer and Systems Science (DSV)

2 Diﬀerent PKIs vs. PKC Revocation 7

3 Classification & Evaluation Metrics 19

3.2.7 Cost Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 PKC Revocation Schemes Evaluation 30

5 Requirements & Integration 60

6 Conclusion & Future Works 75

1.1 The three Phases of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 X.509 Certificate and CRL Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Selected Certificate Revocation Schemes Classification . . . . . . . . . . . . . . . 21

4.1 Evaluation of Traditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1 X.509 Certificate and CRL life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Existing Perspectives on Classifying Certificate Revocation Schemes . . . . . . . 20

5.1 PKC Revocation Scheme Stakeholders and Functional Components . . . . . . . 61

ARL Authority Revocation List

In a networked environment the simplest possible communication can be established just by

1.1.1 Symmetric and Asymmetric Key Cryptography

1.1.2 Public Key Certificate (PKC)

1.1.3 PKC Revocation

Table 1.1: The three Phases of the Thesis

1.8 Brief Outline

Chapter 3: Classification & Evaluation Metrics

Chapter 4: PKC Revocation Schemes Evaluation

Chapter 5: Requirements & Integration

A structured discussion of findings, concluding remarks with pinpointing future re-

Diﬀerent PKIs vs. PKC Revocation

2.1 Asymmetric Encryption & Digital Signature

It must be computationally infeasible to others, to compute a similar digital signature without

2.2.1 X.509 Compliant PKI

1. RA: RA is an optional element of an X.509 PKI to which the CA delegates some of

Revocation of PGP certificate is necessary when a corresponding private key is compromised

2.3 PKC Revocation in Diﬀerent PKIs

2. Distribution of PKC status information:

• X.509: In an X.509 PKI, CA publishes CRLs through an LDAP, FTP, or HTTP

3. Content of PKC status information:

4. PKC revocation mechanisms used:

5. PKC revocation commenced by:

2.4 X.509 Certificate and CRL Format

X.509 v1 Certificate X.509 v2 Certificate X.509 v3 Certificate

Table 2.1: X.509 Certificate and CRL Fields

1. Identification: a CA validates certificate revocation requests.

2. Generation: CA generation of certificate revocation information, i.e. CRLs.

3. Storing: CA stores certificate revocation information, i.e. repository of CRLs On the

Figure 2.1: X.509 Certificate and CRL life Cycle

2.5 X.509 PKC Revocation Synopsis

Classification & Evaluation Metrics

3.1 Classification of X.509 Certificate Revocation Schemes

Figure 3.1: Existing Perspectives on Classifying Certificate Revocation Schemes

No Class Revocation Scheme Name

Table 3.1: Selected Certificate Revocation Schemes Classification

3.2 PKC Revocation Evaluation Metrics

3.2.1 Design Evaluation Metrics

Proposition 1 A secure PKC revocation scheme architectural complexity

Proposition 2 A versatile PKC revocation scheme has to be engineered

Proposition 3 A preferable revocation scheme has to provide discrete,

3.2.2 Performance Evaluation Metrics

CSI generation/distribution CSI Availability Bottleneck

Table 3.2: Perfomance Constraints Tradeoﬀs

Proposition 4 PKC revocation scheme performance evaluation is a mea-