An Eﬃcient Oﬀ-Line Reputation Scheme

Using Articulated Certiﬁcates

Roslan Ismail

, Colin Boyd

, Audun Josang

, and Selwyn Russell

ISRC, Queensland University of Technology, Brisbane, Australia

DSTC, University of Queensland, St Lucia, Australia

Abstract. A common feature practical reputation schemes is that they

are on-line which results in restrictions to both availability and scala-

bility. In order to overcome these two problems we propose an oﬀ-line

reputation scheme based on public key certiﬁcates. We introduce the

idea of articulated certiﬁcates which use proxy signatures to increase the

eﬃciency of reputation veriﬁcation. As well as being well-suited to our

problem such linked certiﬁcates may be of independent interest.

1 Introduction

Reputation schemes are systems developed to collect, analyse and propagate

users’ reputation [12]. They can be used for many purposes, but in the last few

years have emerged as a promising means for enabling electronic transactions

in e-commerce. Studies have shown that use of reputation schemes has positive

eﬀects on the eﬃciency and honesty of markets [1], and that the reputation of a

particular agent can have positive eﬀects on the agent’s gain [13].

Most current reputation schemes, especially the practical ones, are specif-

ically designed for on-line use, eBay being a prime example (www.ebay.com).

This situation is not surprising as a reputation scheme must provide real time

responses so that users’ past behaviours can be obtained immediately. Although

an on-line reputation scheme is currently preferred, it suﬀers two main diﬃcul-

ties: availability and scalability. For example, in a case of denial of service it

may not be p ossible to access the central server and so reputation values cannot

be found. If the central server is distributed to overcome such problems, then

synchronisation and consistency of data will become diﬃcult.

These problems of distributed reputation systems have much in common

with the problems of distribution of public keys. In both cases there is a need for

access to authenticated values distributed in a timely fashion. Public keys are

usually propagated through certiﬁcates formed by an oﬀ-line trusted third party.

It seems a natural idea to use reputation certiﬁcates formed in an analogous way

by a trusted third party. One of the main aims of this paper is to explore how

this may best be achieved.

Reputation certiﬁcates may be controlled by users themselves. The certiﬁed

reputation value calculated from processed feedback is communicated to the rep-

utation owner after completion of transactions with its counterparts. Reputation

Ismail R., Boyd C., Josang A. and Russell S. (2004).

An Efﬁcient Off-Line Reputation Scheme Using Articulated Certiﬁcates.

In Proceedings of the 2nd International Workshop on Security in Information Systems, pages 53-62

DOI: 10.5220/0002660200530062

 SciTePress

Table 1. The participants and their symbols

F T A feedback target is the entity who is being evaluated and gains the reputation

rating based on the feedback given by a feedback provider.

RP A relying party is the entity who relies on the feedback target’s reputation

rating to make a decision whether to proceed in a transaction or not.

C A The certiﬁcate authority is responsible for the registration of the feedback tar-

gets as well as to issue certiﬁcates to them.

CC/RA

The collection centre/reputation authority collects legitimate feedbacks and

uses them to calculate reputation rating and update the feedback target’s rep-

utation certiﬁcate.

The attribute authority is resp onsible for issuing and signing the attributes.

certiﬁcates can be obtained from reputation owners without the need to contact

a central authority. There seem to be two natural ways to realize this proposal.

1. Employ existing identity certiﬁcate technologies, for example, X.509 [5] and

PGP [15] to incorporate reputation values.

Employ a separate certiﬁcate speciﬁcally for the reputation value.

In the former option a reputation rating is regarded as one of the attributes

in the identity certiﬁcate. As a result the implementation does not require any

signiﬁcant modiﬁcation to the existing infrastructure. The latter, on the other

hand, requires a special authority to manage the reputation rating scheme. We

will compare the relative advantages of these diﬀerent options later.

This paper prop oses an oﬀ-line reputation scheme based on public key certiﬁ-

cates. The solution is ﬂexible enough to accommodate most formats of reputation

rating. Diﬀerent options are considered for how to bind the reputation informa-

tion with the identity of the subject. Our proposal, which we call articulated

certiﬁcates, can be applied in other situations when it is desired to augment or

update certiﬁcate information without re-issuing the identity certiﬁcate.

Organisation of the paper

Section 2 discusses the background of reputation

schemes. Section 3 discusses three basic solutions to implement binding between

identity certiﬁcates and reputation information. Section 4 describes our proposed

solution, its properties and the required protocols. Section 5 discusses the relative

merits with other options. Table 1 presents the notations and the symbols used

throughout the paper.

2 Reputation Systems

There has been considerable interest in reputation systems in recent years and

an extensive literature has developed [12]. Reputation systems may be roughly

classiﬁed into two activities.

Reputation calculation is the task of obtaining reputation values from a set

of feedback information. There are various properties that may be desirable

for calculation engines and reputation values may take diﬀerent formats. In

this paper we are not concerned with how reputation values are calculated,

as long as they can be represented eﬃciently in a bit string.

Reputation propagation is concerned with how to distribute reputation val-

ues to parties that require to use them. This is the area addressed in this

paper. There are diﬀerent properties that may be important, including high

availability of values and reliability. A feature that has often been neglected

is privacy of reputation values; we address this partially in this paper by

allowing owners of reputation certiﬁcates to control their distribution.

Oﬀ-line reputation propagation has been proposed by some recent authors

[4, 3]. These schemes addressed the integrity of the submitted feedbacks against

manipulation but are not suited to centralised reputation calculation. A recent

proposal of Liau et al. [7] (the LZBT scheme) demonstrated the possibility of

using certiﬁcates to represent a user’s reputation in the oﬀ-line environment. The

LZBT scheme seems promising for P2P systems because no central authority is

required to operate the scheme. However, its major limitation is that the relying

party has to contact one or more of the preceding feedback provider to verify

the validity of reputation certiﬁcates. This creates an extra burden to the service

consumers to verify the certiﬁcate.

3 Reputation certiﬁcates

Identity certiﬁcates bind the identities of users with their public keys. The cer-

tiﬁcate is issued and signed by a trusted certiﬁcate authority CA. Identity certiﬁ-

cates are typically long term and contain several attributes such as subject name,

public key, expiry date, issuer name, and certiﬁcate holder’s name. These certiﬁ-

cates are mainly used for authentication purposes. Attribute certiﬁcates [9], on

the other hand, are mainly used to provide access controls and role permissions

of an entity with regard to accessing resources. Therefore, these certiﬁcates are

often employed within organizational boundaries. Attribute certiﬁcates typically

do not contain the identity of an entity; instead they may contain attributes such

as role, access control, expiry date, the issuer name and the issuer signature.

A reputation rating can be considered as an attribute bound to an iden-

tity. Reputation certiﬁcates therefore need to be used in conjunction with an

identity certiﬁcate. There are various ways that this may be achieved. Park

and Sandhu [11] discussed three techniques to bind two certiﬁcates (the iden-

tity and the attribute certiﬁcate): monolithic, autonomic and chained signatures.

In the monolithic signature technique the identity and attribute certiﬁcate are

combined to become a single certiﬁcate which is signed by an authority. The

autonomic signature technique implements separate signatures: the identity cer-

tiﬁcate and the attribute certiﬁcate are signed by diﬀerent authorities. To bind

the two certiﬁcates certain attributes in the identity certiﬁcate are linked to the

attribute certiﬁcate. Finally in the chained signature technique the signature of

authority on the identity certiﬁcate is used as a connection link between the

identity and the attribute certiﬁcates. In the next subsections we will consider

solutions which correspond roughly to this classiﬁcation.

3.1 Combined Certiﬁcates

In this solution the identity certiﬁcate and reputation certiﬁcate are the same

object, and the reputation value is simply an additional attribute in the cer-

tiﬁcate. This corresponds to the monolithic certiﬁcate of Park and Sandhu [11].

Figure 1 depicts the abstract view of the solution. In this solution, the feedback

target and the feedback provider are required to register with the authority. A

reputation certiﬁcate is issued and signed by the reputation certiﬁcate authority.

The reputation certiﬁcate should be veriﬁed by the relying party.

FT

Reputation

Authority

RP

Issue & Update

Reputation

Certificate

Show

Reputation

Certificate

Fig. 1. Abstract view of Combined Reputation Certiﬁcate

The combined certiﬁcate oﬀers several advantages; it requires no new infras-

tructure, is straightforward to implement and requires only one operation to

verify the authority’s signature. However, it has some drawbacks.

1. The reputation authority is required to issue and manage the certiﬁcates

besides its routine task to calculate the reputation of the participants.

The reputation attribute b ecomes available to any party who has access

to the identity certiﬁcate. Users may prefer to hold their reputation values

privately except when needed for transactions.

Reputation certiﬁcates need to be updated frequently so the identity certiﬁ-

cate also needs to be issued each time the reputation is up dated.

A diﬀerent way to form a combined certiﬁcate was the smart certiﬁcate pro-

posed by Park and Sandhu [10]. The scheme uses the structure of the X.509

certiﬁcate as its basis and the extension ﬁelds in the original certiﬁcate are used

to incorporate additional attributes. Each attribute in the certiﬁcate is managed

by diﬀerent authorities. Although the smart certiﬁcate has several desirable prop-

erties, a major limitation highlighted by Chadwick and Otenko [2] is that it is

automatically invalid once any attribute is changed. We expect the reputation

rating to change frequently and the certiﬁcate needs to be re-issued each time.

3.2 Separate Certiﬁcates

The separate certiﬁcate corresponds to the autonomic certiﬁcate of Park and

Sandhu [11]. Figure 2 is a graphical representation of the solution showing the

two types of certiﬁcates used. The identity certiﬁcate is issued by the certiﬁcate

authority, while the reputation certiﬁcate will be issued by the reputation au-

thority. The certiﬁcates are linked due to shared information, in particular the

unique name (or X.509 distinguished name) from the identity certiﬁcate may be

included in the attribute certiﬁcate.

FT

CA

RA

RP

Identity Certificate

Show Identity Certificate

Show Reputation

Certificate

Reputation Certificate

Fig. 2. Abstract view of Separate Certiﬁcate

Because there are two authorities, separation of duties can be conducted

which can reduce the problem of overloading the reputation authority. The rep-

utation authority is only responsible for the calculation of the reputation, while

the certiﬁcate authority is responsible for the registration of the feedback targets.

The identity certiﬁcate is used as an identity mechanism for the feedback target.

Like the combined certiﬁcate solution, this solution also has its limitations.

1. It is costly to match the identity certiﬁcate and the reputation certiﬁcate

especially to the relying party RP who has to do three steps of veriﬁca-

tion: ﬁrst to check the validity of the identity certiﬁcate; second to check

the validity of the reputation certiﬁcate; third to match between these two

certiﬁcates.

RP cannot determine whether RA is authorized to provide reputation for

F T s. This means that relying parties have to independently check the policy

and practice statements for any issuers of attribute certiﬁcates.

3.3 Related Certiﬁcates

The idea of related certiﬁcates is to ensure that the attribute certiﬁcate has a

functional link to the identity certiﬁcate, beyond simply referring to the same

identity. This corresponds to the chained certiﬁcates of Park and Sandhu [11].

The diﬀerence from the separate certiﬁcate option is that now the binding infor-

mation in the attribute certiﬁcate depends on the C A signature on the identity

certiﬁcate. In other words, the attribute certiﬁcate is bound to a speciﬁc instance

of the identity certiﬁcate.

Using an attribute certiﬁcate related to the identity certiﬁcate as the reputa-

tion certiﬁcate is a reasonable option. However, the drawbacks already mentioned

for separate certiﬁcates still apply. Independent signature checking increases the

computational burden. The issue of authorization of the RA also applies here,

but with a diﬀerent twist. The issuer of attribute certiﬁcate is free to act inde-

pendently of the C Aof the identity certiﬁcate. However, C As may object to use

of their certiﬁcates by third parties for purposes without their consent and may

put in place legal obstacles to prevent this.

4 Articulated Certiﬁcates

From the discussion in section 3 we see that each of the previous proposals

for binding identity and attribute certiﬁcates has some drawbacks when used

for reputation certiﬁcates, although separate certiﬁcates or related certiﬁcates

could be reasonable choices. In this section we proposed a new scheme for linking

reputation and identity certiﬁcates. We called this an articulated certiﬁcate.

User Public Key

Expiry Date

Serial Number

CA ID

RA

1

ID

RA

2

ID

RA

n

ID

CA signature

Basic Certificate

User ID

Reputation Rating

RA

1

ID

RA

1

signature

User ID

Reputation Rating

RA

2 

ID

RA

2

signature

User ID

Reputation Rating

RA

n 

ID

RA

n

signature

Reputation

Certificate

Fig. 3. Abstract View of Articulated Certiﬁcate

Figure 3 illustrates the view of the proposed scheme. The properties of ar-

ticulated certiﬁcates are diﬀerent from all the options considered in section 3.

–

Articulated certiﬁcates can only be issued by entities that have been autho-

rised to do so by the identity C A. Moreover, the authority to issue may be

restricted for a speciﬁc purpose or particular time interval.

– The articulated certiﬁcate can be veriﬁed using the C Apublic key alone –

no separate certiﬁcate is required for the reputation authority.

–

The identity certiﬁcate may be used either with or without the attribute

certiﬁcate.

A major feature of our proposed solution is to use the concept of delegation

to allow the certiﬁcation authority to give power to the reputation authority

to link to the original certiﬁcate. Delegation enables RA to update reputation

rating in the certiﬁcate without invalidating the certiﬁcate. The C A delegates

his signing capability to RA using the proxy signature scheme. Figure 4 shows

the abstract view of the proposed architecture.

FT

CA

RA

RP

Delegate

Signature

Issue Certificate

Show

Certificate

Update Certificate

Fig. 4. Proposed Architecture

4.1 Proxy Signatures

Proxy signature schemes allow an original signer to delegate signing capability to

another entity, the proxy signer. The ﬁrst proxy signature scheme was introduced

by Mambo et al. [8]. Subsequently a number of schemes have been proposed in

the literature [14, 6]. For our purpose the scheme of Mambo et al. (MUO scheme

hereafter) will be employed. However, other proxy signature schemes can also be

used in our proposal. A brief review of MUO scheme follows.

System Settings: Global system parameters consist of a large prime p, a

prime factor q of p − 1, and an element g ∈ Z

∗

of order q. Computations take

place in Z

∗

unless indicated otherwise. Entity A denotes the original signer and

B denotes the proxy signer. Assume that x

is a private key for A and the

corresponding public key y

= g

and m

is a statement about delegation

which typically contains some particulars including the proxy signer identiﬁca-

tion. A one way hash function H() is used. The scheme can be divided into four

phases; generation of a proxy key, veriﬁcation of the proxy key, signing using the

proxy key and verifying the proxy signature. A small modiﬁcation is made to

the original of MUO scheme to include the hash of m

Generation of a proxy key.

A chooses a random number, k ∈

∗

and com-

putes r = g

. He proceeds to compute s

= x

H(m

) + kr mod q and then

sends (s

, r) to B securely.

Veriﬁcation of the proxy key.

Upon receiving (s

, r), B veriﬁes g

= y

H(m

)

If this equation holds B accepts it is a valid proxy key.

Signing using the proxy key. B signs message m using the proxy key s

The signed message is S(m), r where S() is any discrete log signature gen-

eration algorithm.

Verifying of the proxy signature. A veriﬁer ﬁrst calculates y

= y

H(m

)

and checks the validity of the proxy signature V ( y

, message)

= true where

V () is a the signature veriﬁcation algorithm.

Since MUO scheme is employed, the properties of the scheme of MUO are

automatically inherited into our proposal.

Unforgeablity Besides C A, only RA can create a valid proxy signature.

The third parties who are not designated as a proxy signer cannot create a

valid proxy key.

2. Veriﬁability RP can be convinced of the original signer agreement on the

signed message.

3. Identiﬁability Anyone can determine the identity of the proxy signer from

a proxy signature.

4. Undeniability Once the proxy signer creates a valid proxy signature he

cannot repudiate it.

4.2 Protocol of the Scheme

The protocol consists of six phases as follows. Execution of the phases is not

necessarily in sequential order, except that the delegation and registration phases

have to be executed prior to the other phases. Some phases may need to be

executed more than once, such as updating certiﬁcate, showing certiﬁcate and

validating certiﬁcate.

–

Delegation C A delegates signing capability to RA so that RA can update

the certiﬁcate of F T with a new reputation rating. It is assumed that both

parties C A and RA have already agreed upon the terms and conditions of

delegation beforehand which are encoded in m

. To delegate, C A executes

the generation phase of the MUO scheme by choosing a random number k

and computes r

= g

. This is followed by computing s

= x

H(m

mod q and sends (s

, r

) to RA securely. On receiving this pair RA

veriﬁes g

= y

H(m

. If this holds RA accepts it is a valid proxy

key.

–

Registration F T creates a public key y

F T

and the corresponding private

key x

F T

. y

F T

and ID

F T

are securely sent to C A for registration. A typical

certiﬁcate format of the basic certiﬁcate may be as follows:

Sig

F T

Exp

where Sig

denotes the CA’s signature and Exp denotes expiry date of

the certiﬁcate, On receiving F T ’s particulars, C A veriﬁes their validity. The

certiﬁcate is signed by C A using his private key x

and is sent to F T .

Notice that it is not essential to include the identity of the reputation au-

thorities with the identity certiﬁcate, as shown above. Instead, the RA may

be identiﬁed separately to the relying party by the certiﬁcate owner.

– Sending Identity Certiﬁcate F T is required to send his identity certiﬁ-

cate to RA for the initial contact. It can then be recorded in a database

maintained by RA until a new identity certiﬁcate is issued.

– Updating Reputation Certiﬁcate

To prevent unnecessary updating, statistics of activity of the feedback target

may be used to determine when the reputation rating should be updated.

An active user may be given a short expiry date while an inactive user has a

longer one. To issue a new reputation certiﬁcate RA signs it using the proxy

private key s

. The certiﬁcate is sent to F T . A typical certiﬁcate format

of the articulated certiﬁcate may be as follows.

Sig

ExpR

F T

F T Rating

where Sig

is the signature of RA and ExpR denotes the expiry date of

the reputation rating,

–

Showing Certiﬁcate Before any engagement with the intended RP , F T

may be required to show his reputation certiﬁcate to RP so that his repu-

tation can be evaluated.

– Validating Reputation Rating Prior to accepting the rating in the rep-

utation certiﬁcate, RP calculates y

and veriﬁes the certiﬁcate validity

based on signature to the conditions in m

. If so RP accepts the reputation

rating as a valid reputation rating.

5 Discussion

There are several advantages held by our scheme compared to other schemes.

–

Only one operation is required to verify the reputation certiﬁcate, as only the

RA’s signature needs to be checked by the relying party while the validity of

the identity certiﬁcate is veriﬁed by RA. This advantage is also shared by the

basic certiﬁcate. Separate certiﬁcates and related certiﬁcates, on the other

hand, require three computations to verify the validity of both certiﬁcates.

– There is a separation of duties between the identity CA and reputation

authority. This is generally a good security practice, and ensures that neither

is overloaded with management tasks.

– Our scheme implements tightly-coupled binding between the identity and

reputation certiﬁcates because a single identity certiﬁcate may be mapped

to multiple reputation certiﬁcates. This advantage is shared by the combined

certiﬁcate while the separate certiﬁcate implements loosely-coupled solution.

–

Our proposal has high reusability because changes to the reputation certiﬁ-

cate or the identity certiﬁcate cannot invalidate the reputation certiﬁcate.

This is shared by the separate certiﬁcate while the basic reputation and the

related certiﬁcates have low reusability because any changes invalidate them.

References

1. G. Bolton, E. Katok, and A. Ockenfels. How Eﬀective are Online Reputation

Mechanisms? Discussion Papers on Strategic Interaction 25-2002, Max-Planxk-

Institut, 2002.

D. W. Chadwick and A. Otenko. The permis X.509 role based privilege manage-

ment infrastructure. Future Generation Computer Systems, 19(2):277–289, Febru-

ary 2003.

D. Fahrenholtz and W. Lamersdorf. Transactional security for a distributed repu-

tation management system. In Proceedings of the 3rd International Conference on

Electronic Commerce and Web Technologies, volume 2455 of LNCS, pages 214–223.

Springer-Verlag, 2002.

4. M. Gupta, P. Judge, and M. Ammar. A reputation system for peer-to-peer net-

works. In ACM 13th International Workshop on Network and Operating Sys-

tems Support for Digital Audio and Video (NOSSDAV 2003), pages 144–152. ACM

Press, June 1-3 2003.

ITU-T. Recommendation X.509 Information technology - Open systems Intercon-

nection - The Directory : Authentication framework, 1997.

6. B. Lee, H. Kim, and K. Kim. Strong proxy signature and its applications. In

SCIS’2001, pages 603–608, Jan 23-26 2001.

C. Y. Liau, X. Zhou, S. Bressan, and K.-L. Tan. Eﬃcient distributed

reputation scheme for peer-to-peer systems. In The 2nd International Hu-

man.Society@Internet Conference, volume LNCS 2713, pages 54–63. Springer-

Verlag, 2003.

8. M. Mambo, K. Usuda, and E. Okamoto. Proxy signatures for delegating signing

op eration. In Proceedings of the 3rd ACM conference on Computer and communi-

cations security, pages 48–57. ACM Press, 1996.

R. Oppliger, G. Pernul, and C. Strauss. Using attribute certiﬁcates to implement

role-based authorization and access controls. In Proceedings of the 4. Fachtagung

Sicherheit in Informationssystemen (SIS 2000), Z¨urich (Switzerland), pages 169–

184, October 5-6, 2000.

10. J. S. Park and R. Sandhu. Smart certiﬁcates: Extending X.509 for secure attribute

service on the web. In Proceedings, 22nd National Information Systems Security

Conference, pages 337–348, October 18-21 1999.

11.

J. S. Park and R. Sandhu. Binding identities and attributes using digitally signed

certiﬁcates. In 16th Annual Computer Security Applications Conference (ACSAC),

pages 120–127, December 11-15 2000.

12.

P. Resnick, R. Zechauser, E. Friedman, and K. Kuwabara. Reputation systems.

Communication of the ACM, 43(12):45–48, December 2000.

13. P. Resnick, R. Zeckhauser, J. Swanson, and K. Lockwood. The value of reputa-

tion on eBay: A controlled experiment. In Working paper presented at the ESA

conference, June 2002.

14.

S. P. S. Kim and D. Won. Proxy signatures, revisited. In Proc. of ICICS’97,

International Conference on Information and Communications Security, volume

LNCS 1334, pages 223–232. Springer, 1997.

15.

P. R. Zimmermann. The Oﬃcial PGP User’s Guide. MIT Press, Cam-

bridge, MA, USA, 1995. Available at http://www-mitpress.mit.edu/mitp/recent-

b ooks/comp/pgp-user.html.