A comparison between traditional

Public Key Infrastructures

and Identity-Based Cryptography
Kenneth G. Paterson1

Geraint Price

Information Security Group, Mathematics Department,

Royal Holloway, University of London,
Egham, Surrey, TW20 0EX.
{kenny.paterson,geraint.price}@rhul.ac.uk

Abstract
With the recent acceleration in research into Identity-based Public Key Cryptography
(ID-PKC), we consider this an opportune moment to compare and contrast ID-PKC with
more traditional Public Key Infrastructures (PKI). Because of the similarity in the nature
of both approaches, we aim to identify the distinguish features of each. In doing so, we
highlight the important questions to be asked when weighing up the benefits and
drawbacks of each.
Keywords: Public Key Infrastructure, Identity-Based Cryptography, Asymmetric
Cryptography, Digital Signatures, Certificates, Non-Repudiation.

1 Introduction
With the recent increase in research focused on Identity-based (or Identifier-based) Public
Key Cryptography (ID-PKC), we set out to compare these systems to more traditional
Public Key Infrastructure (PKI) systems using certificates. Our work is focused on
architectural, key management and associated issues; we do not consider implementation
details in any great depth. The main goal of this article is to ask the question What are
the differences between these systems from a practical viewpoint?.
The main technical difference between the two systems is in the binding between
the public and private keys and the means of verifying those keys. In a traditional PKI,
this is achieved through the use of a certificate. In an ID-PKC mechanism, the binding
between the private key and the authenticity data is managed by a Trusted Authority (TA)
at the point of request, while the binding between the public key and that data can be
done by anyone at any point.
We identify the technology behind ID-PKC as being a useful addition to the
security practitioner's armoury. However, we wish to tackle the notion prevalent in many
existing discussions about the extent to which ID-PKC avoids trust problems encountered
in certificate based PKIs. While ID-PKC certainly does provide a new technological
means of managing trust, it does not avoid the problems inherent in this difficult task.
1

Supported by the Nuffield Foundation NUF-NAL02

The remainder of this paper is organised as follows. In Section 2 we provide an

overview of the two technologies. In Section 3 we discuss some of the issues relevant to
the design of a security architecture using either mechanism. The main focus of this paper
is on how the keys and the associated rights are managed under these mechanisms and is
covered in Sections 4 and 5 respectively. In Section 6 we discuss emergent hybrid
mechanisms that have the potential to overcome some of the drawbacks of ID-PKC in
certain scenarios. We conclude in Section 7 with a discussion of the main issues raised
throughout the paper.

2 Technological Overview
In this section we provide a brief technical overview of both traditional PKIs and IDPKC.
Both technologies are variants of asymmetric cryptography, a concept introduced
by Diffie and Hellman [1] in the mid-70s. Until their groundbreaking paper, all cryptosystems had relied upon symmetric cryptography where both communicating parties
shared a copy of the same key. In the model of [1] a related pair of keys are generated.
The user retains the one half of the key for private use, while allowing the other half to be
made public. The private key can then be used to either decrypt a document that has been
encrypted under the corresponding public key, or to sign a message which can then be
verified with the public key.
The main difference between the two variants of asymmetric cryptography that
we focus on here is in the generation of the keys. In traditional asymmetric mechanisms,
which underpin most PKI products on the market today, the key pair is generated from
random information unrelated to the method identifying that key pair within the system.
As such there is a requirement for a certificate to bind the public key to its particular use.
In contrast, the key pair in an ID-PKC environment is generated explicitly from
data that is of relevance to the usage of the key. For example, a user's encryption and
decryption keys may be derived from their identity within the system in which it is to be
used.
We expand our review of PKI and ID-PKC in Sections 2.1 and 2.2 respectively.
We conclude our technological overview in Section 2.3 with a discussion of how the
security policies that make use of these keys can reflect the underlying technology.
2.1 Public Key Infrastructures
Public Key Infrastructures (PKIs) are currently the primary means of deploying
asymmetric cryptography. In this paper, when discussing PKIs we are referring to
infrastructures that support the deployment of traditional asymmetric cryptographic
algorithms, such as RSA [2]. Because of the inherent public nature of the encryption or
verification keys, the integrity of the public keys is usually protected with a certificate.
The PKI is the infrastructure that supports the management of keys and certificates.
As well as the keys and certificates, the core components of a PKI are:

Certificate Authority (CA) : The CA is the entity that generates the certificates.
It is responsible for ensuring the correct key is bound to the certificate, as well as
ensuring the certificate content.
Registration Authority (RA) : The RA is responsible for ensuring that the user
that receives the certificate is a legitimate user within the system. The
functionality of the CA and RA is sometimes carried out by a single entity.
Certificate Storage : In most systems certificates (as well as update information
such as Certificate Revocation Lists) are stored in a CA managed database.
Software : For the certificates to be of use, the software that is going to use the
certificates need to be aware of what the certificate content represents within the
scope of the system security policy.
Policies and Procedures : Although the core of a PKI is mainly technical, there
is, by necessity, a strong requirement for ensuring that the mechanisms are used
correctly. The Certificate Policy (CP) and Certification Practice Statements (CPS)
define the how the certificates are generated and managed. They also define the
role of the certificates within the broader security architecture.
In a traditional PKI, one can choose where the key pair is generated. The keys can
either be generated by the CA for the client, or the client can generate the keys for itself
and provide a copy of the public key to the CA to certify. The choice of mechanism will
largely be dictated by the security policy of the system. It will also be influenced by the
key usage. If a signature key is likely to be used to support non-repudiation, then it is
better that the key is generated by the client. In the case of a decryption key that is used to
keep company information confidential, it might be prudent to have the CA generate (or
have access to) the key so that there is always a means of recovering encrypted
information.
2.2 Identity/Identifier-Based Public Key Cryptography
One of the difficulties inherent in running a PKI is in the managing of the certificate and
associated key. Identity and subsequently identifier based cryptography was created
as a means of overcoming this problem. Shamir [3] was the first to propose such a
scheme in which the key itself is generated from some publicly identifiable information,
such as a person's e-mail address. His original scheme provided a signature algorithm, but
could not be used for encryption. It is only recently that an efficient identity-based
encryption system was proposed by Boneh and Franklin [4].
The core difference between an ID-PKC and a traditional asymmetric algorithm in the
means of generating the keys. The difference is identifiable in two ways:

As mentioned above, in both the signature and encryption variants, the public keys
are generated from publicly identifiable information. This allows a client A to

generate the public key of another client B without having to do a search in a

directory or ask B for a copy of their key.
Because of the mathematics that underpin the algorithms, the creation of the private
key requires the knowledge of a master secret that is held by the Trusted Authority
(TA), who is the analogue of the CA in a PKI.

Recently, it has been recognised that an identity need not be the only determinant of a
client's public key. For example, information such as the client's position within an
organisation, the validity period for the keys, etc. can be included in the data used to
derive the key pair. This results in the broader concept of identifier-based public key
cryptography.
Because the TA is directly responsible for the generation of the private key in an IDPKC mechanism, there is an inherent escrow facility in the system. This may or may not
be desirable. This forces a change in the role of the trusted third party within the system.
In a PKI, the CA is concerned with validating the authenticity of the information present
in the certificate, whereas, in an ID-PKC the TA is directly responsible for generating and
distributing all keying material within the system.
There is also the requirement that TA and client are able to set up an independent
secure channel for the distribution of private key material. This channel needs to protect
both the authenticity and confidentiality of the private key.
Although the idea of using a client's identity as the base for their key pair is very
appealing, it does not come without consequences. The two main issues that will
influence the discussion in the remainder of this paper are as follows:

Coping with the practicalities of implementation are not insignificant. If we take

revocation as an example, because we cannot revoke a person's identity, there is a
requirement for additional input to the key generation process. If we include validity
dates, key usage, etc. then a push toward broader use of identifying information
results, leading naturally to identifier-based cryptography. We will return to
revocation issues in Section 4.3.
The authenticity of the information that is used as the identity or identifier is now
crucial to the security of the system. In a PKI, the certificate is supposed to
demonstrate the authenticity of identifying information. In ID-PKC, because a private
key may be generated after the public key, the TA may not have validated the
authenticity of the information relating to the key pair prior to the public key's use.
For example, A might use information it thinks is valid to generate a public key for B,
but the information A uses could either relate to the wrong B, or may be completely
invalid in the eyes of the TA.

2.3 Policy Interaction

In closing the discussion in this section we will outline what we see as one of the main
questions to be answered when deciding whether a system should use PKI or ID-PKC as
its cryptographic mechanism. This is: how do the security policies of the communicating
parties interact with those of either the CA or the TA?

As mentioned previously, because the TA is explicitly in charge of the generation

of the private keys in an ID-PKC system, it can verify its security policy each time it
hands out a new private key to a client. In the case of the CA in a PKI, the policy is
verified at the time of certification, but it is generally left up to the client encrypting the
information to verify the certificate content in the light of its own security policy.
While neither of these are design principles is strict we could, for example,
mimic the requirement to always fetch a new key from a TA within a PKI the way in
which the information flows through the system is an important consideration when
deciding on which mechanism to use.
Expanding on the example given above, it would seem more natural to implement
an ID-PKC for short term keys where the policy at the TA might change regularly.
Conversely, it would seem sensible to use a PKI in a widely distributed environment, or
in one where the individual policy of each client took a significant role in the policy of
the system as a whole.

3 Architectural Issues
ID-PKC was introduced as a means of circumventing the difficulties associated with
certificate management within PKIs. This has lead to a difference in the way the two
proposed mechanisms are architected. In this section we briefly look at the way in which
this might affect the choices made when deciding between the two as a security
architecture.
In the following list, we outline the architectural issues as we see them:

On first inspection, there appears to be a potential for ID-PKC to develop more

lightweight implementations at the client end. This is due to the lack of requirement
for storing separate certification, identification and keying information. Provided the
authenticity of such information could be verified, this could be useful for scenarios
such as mobile systems, where knowing the identity of the other contact point in an
interaction could be enough to generating keying information on the fly.
It would appear that a PKI would be the implementation of choice in a widely
distributed system. The ability for clients to generate their own key pairs to be
certified by a CA which need not directly be in their security domains could provide
benefits in some scenarios. For example, the use of third party CAs to certify SSL
server keys would be difficult to replace using ID-PKC. The key escrow facility
inherent in ID-PKC would probably not sit well with a corporation wishing to secure
its Internet gateway using an SSL-enabled server.
Within systems where the security is heavily centralised (i.e. where all users have to
trust the CA/TA explicitly anyway) there doesn't seem to be a great deal of difference
between PKI and ID-PKC. The choice of which mechanism to implement is likely to
come down to how the protocols that use those mechanisms fit in the wider
architecture of the system. This is similar to the situation where there is often little to
choose between a symmetric and an asymmetric system in applications where nonrepudiation is not a concern.
In distributed systems where it's difficult to manage a revocation mechanism (e.g.
mobile systems), one way which PKIs aim to deal with the problem is to use short

lived certificates. This might be addressed more efficiently using ID-PKC, as the
system would only require partial synchrony for the sender to generate a currently
valid key for the recipient.
One of the proposed benefits of PKIs is that they can be organised into hierarchies
which reflect the internal structure of a large organisation or group of organisations.
While this might seem provide an advantage for PKIs, recent work by Gentry and
Silverberg [5] develops mechanisms for implementing similar hierarchies in an IDPKC context.
An area where a PKI seems to have a distinct advantage over ID-PKC is in the
consequences of the compromise of the CA/TA. While the compromise of a CA is
disastrous to the future secure running of the system, if the system has been designed
carefully, then all past encrypted traffic is still secure. If the TA within an ID-PKC
system is compromised and the master secret revealed, by the very fact that the
attacker now knows the secret from which all keys are derived, the attacker can now
decrypt all previously encrypted information. The same would be true of signature
keys. As a result, any signature on a document that had not been independently
timestamped could be called into question.

4 Key Management
In this section, we analyse the differences between PKI and ID-PKC by examining the
way in which they manage keys. We separate our discussion into three topics: generation
of public keys, generation of private keys and revocation of keys.
When discussing the generation of keys we concentrate on the following four
questions: Who generates the keys, when are the keys generated, where are the keys
generated and how are the keys generated?
4.1 Generation of Public Keys
In this section we look at the generation of the public halves of the key pairs and how that
might affect the design of a security service built on top of them.
In terms of the questions we ask with regards to key generation, here are the
differences between public key generation in the two schemes:

Within a PKI, the public key is generated at the same time as the private key. This
limits the creation of the public key to either the CA or the client. Within an ID-PKC,
the public key can be generated by any client within the system. Moreover the public
key can be chosen by any client in the system. It is then incumbent upon the other
party to obtain the matching private key from the TA this is the essence of
identifier-based PKC.
Within a PKI, the keys are generated prior to the issuance of a certificate. The validity
of the binding between the public and private keys should be checked by the CA
before issuing the certificate. Within an ID-PKC, because of the separation between
generation of private and public keys, a public key can be generated at a different
time to the private key and hence also at a different time to the validation of the
issuance of the private key.

Within a PKI, the public key is either generated at the CA or by a process which the
client deems to be trustworthy. In an ID-PKC, the public key is generated at the site
of the client who wishes to use the public key.
Within a PKI, the public key usually results from a process that makes use of a
random secret input to generate both public and private keys. In an ID-PKC, the
public key is generated from public information.

The ability within an ID-PKC, to generate a public key from public information at a
time that is different from the generation of the private key provides us with perhaps the
biggest difference between ID-PKC and PKI. Chen et al [6] use this feature of ID-PKC to
enable the control of work-flow within a system. In brief, their proposal allows the client
to encode a policy specifying conditions under which decryption can take place. The
client wishing to decrypt the message must then demonstrate compliance with the policy
to the TA before it is issued with the corresponding private key.
We now examine how these differences manifest themselves in terms of keys for
encryption and signature verification.
Encryption For ID-PKC, the client generating the ciphertext can generate the
encryption key pair without having to know the identity of the client who will decrypt the
message. This has the potential benefit of having the policy compliance encoded directly
into the encryption key. For PKI, the client would need to know the public key that was
related to the private key to be used to decrypt the message in advance usually the
decryption key bound to the recipient's identity. This would seem to make it less flexible
than ID-PKC. However we can mimic this ID-PKC functionality in a PKI by encrypting
the message directly for the CA and attaching the decryption policy to the ciphertext.
Signature verification For ID-PKC, the verification key is generated from the
signer's identity. This can be carried out either by the signer, who then attaches the
verification key to the signed message, or by the verifier who calculates it at the time of
verification. In a PKI, the verification key is created at the same time as the signing key
and the certificate containing the verification key often accompanies the signature. Within
a signature scheme a public key is only of any use when verifying a signature, which
implicitly requires the prior generation of a private key. Because a PKI allows the signer
to attach a certificate to the signature, it seems that ID-PKC's advantage of being able to
generate keys independently holds little advantage in this scenario.
Because of the close relationship between the generation of both public keys and
private keys, we combine some of the issues raised here with the discussion at the end of
Section 4.2.
4.2 Generation of Private Keys
In this section we analyse how the way in which private keys are generated in each
approach can potentially affect its usage.
The main difference between the two approaches, in terms of generation of the
private key, is that with ID-PKC, the key has to be generated by the TA. On the other

hand, in a PKI there is a choice of having the private key generated by the CA or the
client.
This enforcement of the private key generation by the TA within ID-PKC raises
concerns of escrow and/or privacy surrounding the management of private keys. This
might be of benefit to an encryption scheme in a business environment where the
company owns the data, but is drawback in an implementation for digital signatures
which might want to offer non-repudiation. Boneh and Franklin [4] propose a means of
circumventing the escrow problem by using multiple TAs and threshold cryptography.
Collusion between independent TAs would then be required for a copy of the private key
to be generated.
While the notion of who generates and controls the key is of interest to those in
the academic community, it is also becoming an important issue for those running
signature applications. The EU Directive on Electronic Signatures [7] states that a key
used as an Advanced Electronic Signature should be under the sole control of the
individual who is named in the Qualified Certificate.
Before entering further into the discussion of the relative merits between PKI and
ID-PKC in this area, we note that our discussion in Section 6 outlines recent research that
could potentially be used to overcome the drawbacks of private key generation in IDPKC schemes.
We now analyse the differences in private key generation for ID-PKC and PKI.
We do this by separately considering encryption and signatures.
Decryption For ID-PKC the private key needs to be provided to the decrypting
party by the TA. Whether this key will be fresh for this particular session/message
depends on whether the client generating the ciphertext used a long term or short term
public key. This is a policy decision influenced by the system security policy in
conjunction with the policy of the client carrying out the encryption. For PKI the public
encryption key used is usually the client's long term key bound to their certificate,
although a short term key could also be used. If a long term key is used, there seems to be
little difference between the two schemes. The main difference comes to light when we
consider the creation of session-oriented private keys whose release is managed by the
TA, as in the work of Chen et al [6].
Signature creation For ID-PKC the private key is generated by the TA and given
to the client. Because signature schemes should uniquely identify the creator of the
signature, the inherent key escrow in ID-PKC makes it a less attractive choice. For PKI,
the key is either generated by the CA or the client. This ability to chose who generates the
private key offers PKI an advantage in terms of flexibility over ID-PKC. A proposed
benefit of ID-PKC over PKI the separation between the public and private key
generation does not immediately appear to be of use here, as we discussed in Section
4.1.
We now discuss some of the issues raised when analysing the differences between
the management of keys in ID-PKC and PKI:

It would appear that in an ID-PKC implementation, the TA needs to retain a database

of every ID to which a key has been issued under the current system parameters.

Otherwise, there is potential for the following scenario to arise: A key could be
generated, used, and either revoked or removed at the end of its natural life-cycle. At
some point in the future, another client could request a key with the same ID, maybe
with a legitimate reason the users share a common name. The two users will now
share the same public/private key pair. At first glance it would appear that a similar
problem was inherent in PKI, in that the same ID could be certified, but there is a
difference. In ID-PKC, because of the inherent link between ID and public key, the
keys will actually be the same. In a PKI implementation, the keys are generated
separately and usually using some client controlled randomness. This means that the
keys will almost certainly be different even if the identities are the same.
A related issue is raised if we consider the standard ID-PKC solution to the above
problem. This is to include, as part of the identity, additional detail such as date of
birth, position in organisation etc. The more worried one is about duplication within
the system, the more the content of the identity starts to mirror the content of the
certificate in a PKI. Where does this leave us? The client now has to contend with two
issues when generating another client's public key. What is the correct form in which
the identity should be created? What is the content of each field type, such that the TA
will give the corresponding private key to the correct recipient? By going down this
path, we end up with a similar set of standards problems that are faced by the
implementors of PKIs. How does a client know what each field in an identifier is
meant to represent? There must be agreement between communicating parties and the
TA. Thus, we note that removing the certificate from the system does not solve all the
problems that are of relevance to certificate management.
Both previous points are specific problems encountered when we realise that in IDPKC, the public keys and the identity are inexorably linked. In a PKI the separation is
clear. Whether this is considered a benefit or a drawback can only be resolved when
considered in light of a particular application.
There is a potential safety issue when considering the generation of public keys in an
ID-PKC scheme. Because it is the client which chooses the identity which is used to
generate the public key, they could chose an identity for which the TA will not release
the corresponding private key. This could leave the intended recipient unable to read
vital information, or result in the need for manual intervention and override. Such
intervention may not be convenient if, say, the private key generation is done in a
hardware security module.

4.3 Revocation
Revocation is one of the main difficulties faced by implementors of PKIs. While ID-PKC
does not have a certificate per se, the issue of how to manage the identity/identifier
relevant to a particular public key has so far received very little attention. This problem is
analogous to the problem of certificate management in a PKI. In this section we will
argue that revocation could potentially become as large a concern for ID-PKC as it
currently is for PKI.
Here are the three main issues we see for revocation in ID-PKC:

As mentioned in the previous section, keeping track of identities that have been
issued within the system is a potential problem for key management. Because of the
strong link between keys and identities in ID-PKC, revoking a public key requires the
revocation of the associated identifier. This problem is acute if the identifier is one
which could be inconvenient to change (such as an e-mail address). But these are
precisely the identifiers that are easily predicted by the entity attempting to
independently generate a valid key for an intended recipient. This suggests that less
predictable identifiers would need to be employed. For example, the inclusion of
issue numbers in identifiers is conceptually simple, but leads to identifiers that are
difficult to predict. So in actual implementations it is likely that more complex
identifiers, which are built on top of a client's identity, will provide the input to the
key generation function. This means that there is likely to be a higher degree of
complexity in the part of the system which managers those identifiers than might at
first sight appear. This is related to the issue about form and content of identifiers
noted in Section 4.2.
Because of the inherent binding between identifier and key in ID-PKC, there is a
potential drawback in terms of re-certification. At a recent PKI workshop, we saw a
demonstration for a product which separated the storage of private key and certificate.
The private key was stored on a smart card, while the certificate was stored on the
hard drive. This allowed the organisation to change the certificate content through recertification without needing to go through the more expensive procedure of issuing
the clients with a new private key. An exact replica would be impossible to achieve in
an ID-PKC system.
When considering the issue of revocation, Boneh and Franklin [4] proposed merging
the date with the client's identity to provide the identifier for the key (e.g. the string
Alice,12MAR2003 could provide the input for the key generation function). The
argument provided is that the re-issuance of keys on a per time basis obviates the
need for a revocation mechanism. This mechanism raises a few problems. If we force
all legitimate users to request fresh keys every day (or even every hour if a finer
degree of control is needed), then it forces the TA to be on-line for a greater
proportion of the time and may significantly increase the TA workload. The ability to
remove the need for an on-line server is one of the benefits of using asymmetric
cryptography in the first place. It could be argued that having an OCSP or CRL server
in a PKI has the same drawback. This is not necessarily true: A CRL can be
distributed by a server that is not the root CA. Another problem with Boneh and
Franklin's model of revocation is that it requires an independent secure channel
between the channel and the TA for the transportation of the fresh keying material. In
a traditional PKI the registration, key generation and certification procedures should
be among the most heavily guarded. Applying this same level of security daily in an
ID-PKC could make the process inherently difficult to manage.

To put it more succinctly, revocation in a PKI requires reliable and timely distribution
of authenticated information. Revocation in an ID-PKC, using the methods discussed
here, requires the reliable and timely distribution of confidential information.

5 Rights Management

In this section we analyse the differences in the manner in which rights are handled in
PKIs and ID-PKC systems. The term rights in this discussion encompasses anything that
the possession of a key and/or related certificate/identifier allows the client to do. For
example, a right could be The right to view confidential report X or A, being a
purchase manager, can sign orders up to a value of $10,000. As such, we use the term
in as neutral a form as possible, to highlight the fact that rights represent any extension of
the services which encryption and signature algorithms provide.
We separate our discussion here into the issues surrounding the generation and
verification of these rights.
5.1 Rights Generation
In this section we introduce the basic means by which rights are represented in each
mechanism and how these representations are generated. We split our discussion into two
parts, one concerning rights implemented using signatures and the other, rights
implemented using encryption.
Signing
PKI In PKI, the signing key is usually bound to an identity. Depending on the
system policy, the right to sign is either implicit in the verifier knowing who the signing
party is, or it is explicit through a binding to an authorisation mechanism. The
authorisation mechanism could be a more traditional Access Control List, a separate
Privilege Management Infrastructure (PMI), or be contained in the client's identity
certificate. The right to sign for a particular purpose is assessed either by the CA when
generating the identity certificate or by the authority in charge of the separate
authorisation infrastructure.
ID-PKC In an ID-based scheme, it would appear that the same principles apply.
The popular choice for a signature creation key is likely to be some variant of the signing
party's identity. The right to sign is likely to be implicitly recognised between signer and
verifier, or more explicitly contained in an additional mechanism, similar to those
discussed above for PKIs. Again, the right to sign will be assessed at the time of creation
of the signature key or when the identity is bound to the associated authentication
mechanism.
Encryption
PKI Traditionally PKIs have been primarily associated with authentication rather
than authorisation (SPKI [8] being the notable exception). In most commercial PKI
systems, the identity certificate is used to authenticate the client to a separate
authorisation infrastructure. As in the discussion on signatures above, the right to decrypt
can either be implicit or explicit. For example, Alice may know Bob personally and thus
be willing to use the encryption key in Bob's certificate this may be the case in when
using e-mail security software. Alternatively, Alice might want to see Bob's credential as
a line-manager before passing on an encrypted version of the payroll file. In both cases,

the right to decrypt is generated when the identity certificate or authorisation token is
generated.
ID-PKC As with PKIs, the right to decrypt can be generated at the same time as
the private key, in advance of the decryption. One of the proposed benefits of using IDPKC is that the public encryption key can be generated by the party encrypting the data in
advance of the corresponding private key having been generated. If used in this manner,
the right to decrypt is effectively generated when the client encrypting the message
generates the public key, but the subsequent verification of that right does not happen
until the TA generates the corresponding private key, which may happen at some point in
the future.
5.2 Rights Verification
We now turn our attention to how the verification of rights might take place. Our goal in
this section is to understand how the means by which these rights are verified affects the
design of the system. To achieve this, we keep our discussion at a generic level and
develop our argument by analysis of the following three factors for signatures and
encryption:
Who : Who is capable of carrying out the verification?
When : When is the verification carried out in relation to the right generation?
Where : Is there a physical or logical relationship between generation and
verification which might affect the security policy?
We note that in an attempt to keep our analysis as broad as possible, we describe
the most logical means of implementing the rights verification functions.
Signature Verification
We separate the analysis of PKI and ID-PKC systems.
PKI
Who In the case of signature verification, anyone who can use the public key
associated with the signature key can verify the signature. This does not necessarily mean
that they will be able to accurately verify the associated rights that may be bound to the
public key through a certificate. One of the influencing factors would be whether the
verification of the right to sign was implicit in the sense that A knows B, or explicitly
through some other mechanism.
When The verification occurs when the client verifying the signature carries out
the signature validation. In terms of time, this could potentially be far removed from the
time that the signature was created. This flexibility in separation is potentially both a
benefit and a drawback. If the signature is created on a document that may need to be
verified multiple times by multiple parties, then this is a benefit. If, on the other hand, the
signing party's right to sign may be brought into question in the future, there is an
argument for re-validating the right to sign as close as possible to the time at which the

signature is created. An example where this might present a problem would be a signature
system that provided non-repudiation. If a signature on a particular document was
generated at roughly the same time as a revocation was issued, determining the true order
of events could be difficult.
Where Because of the nature of a traditional public key and its associated
certificate, the verification could be conducted at a logically or physically remote site to
the signature. This is considered one of the great strengths of public key cryptography.
ID-PKC
Who In a similar manner to PKI, anyone with access to the public key
corresponding to the private key can verify the signature. As mentioned previously, that
does not necessarily imply that they can accurately verify the right associated with that
signature. This will depend on the security policy of the system and the parties involved.
If the right is implicit, then it is the security policy of the relying party that governs the
right. If the right is explicit, then the relying party needs to be able to process the
associated authorisation structure.
When The timing of the verification is likely to be similar to a PKI. The
verification of the right to sign will happen when the signature is checked by the relying
party.
Where Once again, there is the potential for the signature to be verified
somewhere that is logically and physically remote from the signing party.
Decryption
Again, we analyse potential PKI and ID-PKC systems separately.
PKI
Who Who verifies the right will depend on how the system is built. If the PKI is
set up with an encryption key in the certificate, then it is likely to be the client encrypting
the data. If the PKI is only used as an authentication front end to a separate authorisation
mechanism, then it is likely to be the policy monitor for the authorisation mechanism.
When If the verification is carried out by the client encrypting the message, then
right is likely to be verified when the encrypted message is being generated. This might
happen at a time that could realistically be far ahead of when the recipient decrypts the
message. There is a danger here that the original right might have expired or have been
revoked in the meantime. If there is a monitor controlling access to the data, then the
right should be checked as the data is being released to the recipient.
Where If the right is being checked implicitly or explicitly by the encrypting
party, then this happens in a place that is potentially logically remote from the recipient.
In the case of an access monitor, then the location is likely to be carefully chosen to be
within the same logical or physical security domain as the recipient.
ID-PKC

Who In a similar manner to PKI, who does the verification will depend on how
the system is implemented. If the encryption key is generated from the user's long term
secret key, then it is likely to be the client encrypting the message. If the client is allowed
to control the generation of the public key according to their security policy as
proposed by Chen et al. [6] then the verification of the right to decrypt is carried out by
the TA that generates the private key for the recipient.
When If the client encrypting the message uses a long term key, then the right to
decrypt is verified at the point of encryption. If the key is a sender-chosen key generated
specifically for that encryption, then the rights verification should happen at the point at
which the TA hands out the decryption key to the recipient.
Where As in the case of the PKI, if the encrypting party carries out the
verification, this could potentially be anywhere. If the key is chosen by the sending client,
then this would happen at the TA, who is a trusted server within the security domain.
We now discusses some of the main issues raised by our analysis in this and the previous
section.

There is a relationship between the management of rights and the revocation issues as
discussed in Section 4.3. When you use a right (e.g. to verify a signature, encrypt a
document to a colleague), you need to know at that point whether the right has been
revoked or not. It is this verification is the right to carry out a task that poses one of
the problems in implementing a PKI. With ID-PKC, the act of rights verification can
be bound closely (both in terms of time and space) to point at which the verification is
carried out. This is carried out through the use of client chosen short-term keys with
the recipient having to retrieve the associated private keys from the TA. While
discussing the future of PKI, Gutmann [9] recommends a similar binding when
implementing a PKI. At first glance, it would appear that such strong binding between
verification and CA/TA, if required, can be carried out more cleanly in an ID-PKC
implementation.
There are scenarios where the right to decrypt, in a PKI system is only generated and
assessed immediately prior to decryption, rather than when encryption takes place.
This results in a mechanism which is very similar to one that proponents of ID-PKC
claim as a benefit of their approach. An example of such a system might be an
encrypted file store on a server. A client wishing to access the encrypted material asks
a monitor for read rights. The right might then be generated on the fly as part of the
rights verification process.

These two points highlight the fact that both PKI and ID-PKC systems ultimately
work in a similar manner. It would appear that ID-PKC lends itself naturally to situations
where the TA should be given governance over policy decisions. In a PKI, the ability for
any client to verify the content of a certificate means that policies set by the CA can
potentially be independently assessed by the client in relation to client-oriented policy.

6 Beyond PKI and ID-PKC

The focus of this paper has been to make a comparison between ID-PKC and PKI. Here
we cast a glance towards some recent developments in research in the area of models for
infrastructures supporting the use of public key cryptography [10, 11].
6.1 Certificate-Based Encryption
In [10], Gentry introduced the concept of Certificate-Based Encryption (CBE),
with a view to simplifying revocation in traditional PKIs.
In Gentry's model, an entity B's private key consists of two components: a
component which that entity chooses for itself and keeps private, and a component which
is time-dependent and is issued to B on a regular basis by a CA. This second component
can be transmitted over a public channel from the CA to B.
Matching the two private key components are two public key components. The
first of these matches B's own private component and is assumed to be readily available
to any entity A who wishes to encrypt a message to B. The second public component can
be computed by A using only some public parameters of the scheme's CA together with
the current time value and the assumed value of A's public key.
In encrypting a message to B, A makes use of both public components. Because of
the structure of the CBE scheme, A is then assured that B can only decrypt messages
encrypted by A if B is in possession of both private components. Thus the second private
component acts as an implicit certificate for relying parties: one that a relying party can
be assured is only available to B provided that B's certification has been issued for the
current time period by the CA. The security of CBE depends critically on the CA binding
the correct public key into B's implicit certificate in each time period. Thus (quite
naturally), the initial registration of users and their public keys must take place over an
authentic channel and be bootstrapped from some other basis for trust between B and the
CA.
This approach can significantly simplify revocation in PKIs: notice that there is
no need for A to make any status checks on B's public key before encrypting a message
for B. So there are no CRLs and no requirement for OCSP. Nor are any certificates
actually needed by A; rather A needs to be in possession of what it assumes is a copy of
B's public key and an authentic version of the CA's public parameters. (Rather, an
implicit certificate is needed by B in order to decrypt for this reason, perhaps
Certificate-Based Decryption would be a better name for the CBE concept.)
However, the basic CBE approach of [10] does have a major drawback: the CA
needs to issue new implicit certificates to every user in the scheme in every time period.
A granularity of one hour per time period is suggested in [10]; this substantially adds to
the computation and communication that takes place at the CA for a PKI with even a
small user base. The basic CBE approach can be regarded as effectively trading
simplified revocation for an increased workload at the CA. It can even be argued that
CBE loses the one key feature enjoyed by a traditional PKI: that the certificates issued by
the CA allow the CA to distribute trust in an almost off-line manner (the CA needs only
to be on-line to perform a revocation function). A number of enhancements to the basic
CBE approach are also presented in [10]. These reduce, but do not completely eliminate,
the work that must be carried out by the CA.

The specific instantiation of CBE given in [10] builds on ideas developed in

Boneh and Franklin's identity-based public key encryption scheme [4]. The details of
Gentry's specific CBE scheme are beyond the scope of this paper.
6.2 Certificateless Public Key Cryptography
Independently of Gentry's work, Al-Riyami and Paterson [11] proposed another
new model for supporting the use of public key cryptography. The key feature of the
model of [11] is that it completely eliminates the need for certificates, hence the moniker
certificateless public key cryptography (CL-PKC). The technical means by which it does
so is actually rather closely related to that used in [10]: a user A's private key is composed
in two stages. In the first stage, an identity-dependent partial private key is received over
a confidential and authentic channel from a trusted authority (called a key generation
centre, KGC). In the second stage, the user produces his private key by combining the
partial private key with some secret known only to the user.
The user also publishes a public key which matches the private key. However, this
public key need not be supported by a certificate. Instead, an entity A who wishes to rely
on B's public key is assured that if the KGC has done its job properly, then only B who is
in possession of the correct partial private key and user-generated secret could perform
the decryption, generate the signature, etc.
In fact, CL-PKC allows A to use B's public key but to choose an identifier for B.
In order to decrypt A's message, B must then fetch the correct partial private key from the
KGC. Thus CL-PKC supports the temporal re-ordering of public and private key
generation in the same way as ID-PKC does.
CL-PKC combines elements from ID-PKC and traditional PKI. The schemes are
no longer identity-based: they involve the use of B's public key which is no longer simply
derived from B's identity. However, as we have already discussed, when using ID-PKC in
practice, it is rare that the public keys will depend on identities alone. On the other hand,
CL-PKC avoids the key escrow inherent in ID-PKC by having user-specific private
information involved in the key generation process. And CL-PKC does not need
certificates to generate trust in public keys; instead this trust is produced in an implicit
way. This would appear to make CL-PKC ideal for systems where escrow is
unacceptable, but where the full weight of PKI is untenable. For example, it might be
well suited to a mobile e-commerce application where signatures are needed to ensure
non-repudiation of payments.
Perhaps not surprisingly, it is possible to convert a CL-PKC encryption (CL-PKE)
scheme into a CBE scheme la Gentry: if B's identity in the CL-PKE scheme is extended
to include a time period along with the public key, then the CL-PKE scheme effectively
becomes a CBE scheme. On the other hand, if one omits certain fields from the
certificates in a CBE scheme, one obtains an encryption scheme that is functionally
similar to a CL-PKE scheme. Differences do remain: in the strength and scope of the
security models developed in [10] and [11], as well as in the technical details of the
schemes' realizations.
In closing this brief introduction to recent work, it is worth re-iterating that CBE
as presented in [10] is formulated within the confines of a PKI setting and is aimed at
simplifying revocation, while CL-PKC attempts to break free from the mental

straightjacket imposed by ID-PKC and PKI. Time will tell to what extent these relatively
new research ideas see further development and eventual deployment in applications.

7 Discussion & Conclusions

We draw this paper to a close with an overview and summary of what we consider the
key points we have raised through our analysis, followed by some conclusions.
7.1 Key Points
Although we have discussed various issues as they have arisen during each section, the
following list represents a summary of what we consider to be the most salient points
raised in this paper:

The strong binding between an identity and a key in an ID-PKC could potentially
provide a benefit in systems where there is a strong binding between user and the
identifier of the communication end point. An example of this might be mobile
networks, where the encryption channel might be set up through knowledge of the
recipient's physical address.
With ID-PKC, the verification of the rights used in the system can be more readily
bound to the private key generation process at the TA. However, as is often true in
security, the differences in what you can achieve are not always restricted by the
how of the underlying mechanism. It is possible to emulate much of what ID-PKC
has to offer within a PKI implementation by having the client that generates the
encryption send an accompanying policy statement to a monitor (Section 5.2).
The message flow and interaction between clients can become an issue. On the face
of it, a two-pass protocol is not much worse than a one-pass protocol, but if the link
over which the messages flow can easily become congested, the saving could be
important. If an ID-PKC implementation could guarantee that a client generating a
public key generated it correctly, then it could deliver the saving of not having to
perform a certificate look-up.
How the policies of the communicating parties interact is an important consideration
when choosing whether to achieve security using a PKI or an ID-PKC system. As we
mentioned in Section 5.2, it would appear that ID-PKC could provide a more natural
implementation in a situation where a centralised security policy should be checked
regularly. By contrast, the very nature of a certificate makes a PKI more useful in a
situation where the policy should be controlled locally at the client using a certificate.
Liveness of the trusted authority (CA or TA) is a potential issue. As mentioned in our
discussion on revocation (Section 4.3), one of the ways in which revocation might be
handled in ID-PKC would require the TA to be on-line potentially more often than a
CA in a PKI.
The explicit dependence of the public key on the identity/identifier in ID-PKC could
potentially become a hindrance in applications that might require flexibility in their
certificate structure without having to go through the associated distribution of new
keying material.

7.2 Conclusions
Although research interest in ID-PKC is very strong at the moment, it is a relatively new
technology in comparison to PKI. In our article, we have sought to explore what
separates ID-PKC from PKI. Our initial judgement, admittedly made in the context of
little or no commercial deployment of ID-PKC systems, is that there is very little to
separate the two. Perhaps the important input when deciding whether to adopt PKI or IDPKC is the different way in which the two technologies naturally generate and verify
rights and keys.
As with symmetric and asymmetric cryptography, the deciding factors when
choosing between PKI and ID-PKC are likely to be environmental. This influence of the
constraints surrounding the implementations are likely to be greater given that there
doesn't seem to be such a strong separating factor as the ability to provide nonrepudiation is between symmetric and asymmetric cryptography.

References
[1] W. Diffie and M. Hellman. New directions in cryptography. IEEE Transactions on
Information Theory, IT-22(6):644-654, 1976.
[2] R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures
and public-key cryptosystems. Communications of the A.C.M., 21(2):120-126, February
1978.
[3] A. Shamir. Identity-based cryptosystems and signature schemes. In Advances in
Cryptology CRYPTO 84, volume 196 of LNCS, pages 47-53. Springer-Verlag, 1984.
[4] D. Boneh and M. Franklin. Identity-based encryption from the Weil pairing. In J.
Kilian, editor, Advances in Cryptology CRYPTO 2001, volume 2139 of LNCS, pages
213-229. Springer-Verlag, 2001.
[5] C. Gentry and A. Silverberg. Hierarchical ID-based cryptography. In Y. Zheng, editor,
Advances in Cryptology ASIACRYPT 2002, volume 2501 of LNCS, pages 548-566.
Springer-Verlag, 2002.
[6] L. Chen, K. Harrison, D. Soldera, and N.P. Smart. Applications of multiple trust
authorities in pairing based cryptosystems. In G.I. Davida, Y. Frankel, and O. Rees,
editors, Infrastructure Security, International Conference, InfraSec, volume 2437 of
LNCS, pages 260-275. Springer-Verlag, 2002.
[7] EU Directive 1999/93/EC of the European Parliament and of the Council on a
Community
framework
for
electronic
signatures,
December
1999.
http://europa.eu.int/eur-lex/pri/en/oj/dat/2000/l_013/
l_01320000119en00%120020.pdf.

[8] C. Ellison. SPKI requirements. IETF RFC

http://www.ietf.org/rfc/rfc2692.txt.

2692,

September

1999.

[9] P. Gutmann. PKI: Its not dead, just resting. IEEE Computer, 35(8):41-49, 2002.
[10] C. Gentry. Certificate-based encryption and the certificate revocation problem. In E.
Biham, editor, Advances in Cryptology EUROCRYPT 2003, volume 2656 of LNCS,
pages 272-293. Springer-Verlag, 2003.
[11] S.S. Al-Riyami and K.G. Paterson. Certificateless public key cryptography. In
Proceedings of Asiacrypt 2003, Lecture Notes in Computer Science, 2003. to appear.