kent academic repository mangement.pdf · 2019-03-09 · research article trust management for...

Kent Academic RepositoryFull text document (pdf)

Copyright & reuse

Content in the Kent Academic Repository is made available for research purposes. Unless otherwise stated all

content is protected by copyright and in the absence of an open licence (eg Creative Commons), permissions

for further reuse of content should be sought from the publisher, author or other copyright holder.

Versions of research

The version in the Kent Academic Repository may differ from the final published version.

Users are advised to check http://kar.kent.ac.uk for the status of the paper. Users should always cite the

published version of record.

Enquiries

For any further enquiries regarding the licence status of this document, please contact:

[email protected]

If you believe this document infringes copyright then please contact the KAR admin team with the take-down

information provided at http://kar.kent.ac.uk/contact.html

Citation for published version

Wazan, Ahmad Samer and Laborde, Romain and Chadwick, David W. and Barrere, Francoisand Benzekri, Abdelmalek and Habbal, Abid M.M. and Kaiiali, Mustafa (2017) Trust Managementfor Public Key Infrastructures: Implementing the X.509 Trust Broker. Security and CommunicationNetworks, 2017 (690714). pp. 1-23. ISSN 1939-0114.

DOI

https://doi.org/10.1155/2017/6907146

Link to record in KAR

https://kar.kent.ac.uk/60311/

Document Version

Publisher pdf

Research Article

Trust Management for Public Key Infrastructures:Implementing the X.509 Trust Broker

Ahmad Samer Wazan,1 Romain Laborde,1 David W. Chadwick,2 Francois Barrere,1

Abdelmalek Benzekri,1 Mustafa Kaiiali,3 and Adib Habbal4

1Paul Sabatier University, Toulouse, France2University of Kent, Kent, UK3Queen’s University, Belfast, UK4Universiti Utara Malaysia, Kedah, Malaysia

Correspondence should be addressed to Ahmad Samer Wazan; [email protected]

Received 25 July 2016; Revised 21 November 2016; Accepted 12 December 2016; Published 9 February 2017

Academic Editor: Barbara Masucci

Copyright © 2017 Ahmad Samer Wazan et al. his is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.

A Public Key Infrastructure (PKI) is considered one of the most important techniques used to propagate trust in authenticationover the Internet. his technology is based on a trust model deined by the original X.509 (1988) standard and is composed ofthree entities: the certiication authority (CA), the certiicate holder (or subject), and the Relying Party (RP). he CA plays therole of a trusted third party between the certiicate holder and the RP. In many use cases, this trust model has worked successfully.However, we argue that the application of this model on the Internet implies that web users need to depend on almost anyone in theworld in order to use PKI technology. hus, we believe that the current TLS system is not it for purpose and must be revisited as awhole. In response, the latest drat edition of X.509 has proposed a new trust model by adding new entity called the Trust Broker(TB). In this paper, we present an implementation approach that a Trust Broker could follow in order to give RPs trust informationabout a CA by assessing the quality of its issued certiicates. his is related to the quality of the CA’s policies and procedures andits commitment to them. Finally, we present our Trust Broker implementation that demonstrates how RPs can make informeddecisions about certiicate holders in the context of the global web, without requiring large processing resources themselves.

1. Introduction

he need to identify our partners on the Internet constitutesone of the major challenges in ensuring trust on the Internet.However, multiple recent stories show that such an objectiveis far from being reached.

On the 18th of February 2015, a security expert publishedan image on Twitter [1] showing that Superish is deliveringthe certiicate of Bank of America, instead of Verisign(Figure 1). Supposedly, Lenovo integrated Superish sotwarein some of its PC models, in order to inject advertisementsrelated to Google search results for users of IE and Chromeweb browsers. Doing this, Superish can in fact intercept anyencrypted traic of Lenovo users. To solve this issue, Lenovohas issued a guide that helps users to remove Superish [2].

In a similarway andmore recently (Nov 23, 2015), anothersecurity expert showed how Dell has shipped computers thatmake their future owners vulnerable to MITM attacks [3].He showed that Dell has injected a root CA called eDellRootin two models of PCs along with its private key. he expertexplained that anyone could extract the private key and use itto sign falsiied certiicates that will be accepted transparentlyby the Dell PCs having the eDellRoot CA. Dell has providedan oicial solution to remove the root CA as well as its privatekey [4].

In both stories, the solution is to remove the CA and/orsotware from the concerned computers. However, nothingprevents similar stories appearing again in the future, andthese are not even malicious attacks. here are many moreexamples of these; for example, Ye et al. [5] have shown how

Hindawi Publishing CorporationSecurity and Communication NetworksVolume 2017, Article ID 6907146, 23 pageshttps://doi.org/10.1155/2017/6907146

2 Security and Communication Networks

Figure 1: Bank of America’s certiicate signed by Superish insteadof Verisign.

malicious web sites can trick users into believing they have asecure SSL session when they do not.

On the other hand, many other stories in the news showthat diferent CAs have either abused the trust that RPshave in them or their systems have been hacked to issuefalse certiicates. For example, in June 2011, DigiNotar, aDutch CA, was hacked. he hackers made DigiNotar signhundreds of falsiied certiicates for high proile websites suchas Google and Facebook. One year ater, DigiNotar declaredbankruptcy. Other stories showed how CAs have abusedthe trust of RPs. For example, on 23 March, 2015, Googlediscovered that China Internet Network Information Center(CNNIC) issued an unconstrained intermediate certiicate toan Egyptian company that used this certiicate to interceptcommunications of web users accessingGoogle domains (i.e.,a TLS MITM attack).

We believe that the main problem of the web TLS systemcomes from the fact that web users must trust a multitude ofentities in order to secure their transactions. First of all, theymust trust their web browsers to validateweb sites’ certiicateson behalf of them. Trusting the certiicate validators is notlimited to known web browsers because anyone has the rightto validate certiicates on behalf of web users or trick usersinto believing validation has occurred. Secondly, the sameweb user has to trust directly hundreds of unknown CAsprovided by diferent OS/browser editors, because the latterdoes not want to assume any responsibilities if somethinggoes wrong with any CA. In order to justify these boldstatements, we irst need to list the obligations [6] ofweb usersbefore they should accept a public key certiicate:

(1) Users should ensure the authenticity of the trustanchor or “root” CA (i.e., ensure that the public keyof the CA belongs to the claimed CA).

(2) Users should trust the trust anchor CA to issuecertiicates.

(3) Users should know that the subject’s certiicate isappropriate to the context of use.

(4) Users should ensure that the subject’s certiicate isvalid, as well as all the certiicates in the chain up

to the trust anchor’s certiicate or public key (i.e.,conform to the right standards).

To realize task 1, web users must get the certiicate of a“root” CA from a trusted source or by some out of bandmeans. According to RFC 5280, web users are supposedto build their trust decisions (task 2) by analysing a setof CA documents (Certiicate Policy (CP) and CertiicationPractice Statement (CPS)) to answermany technical and legalquestions like what happens when the CA does not correctlycheck the identity of the certiicate holder, or worse, whenit issues a certiicate to a person with a false identity? Whathappens if the certiicate is false and makes me lose $1000? Isthe CA responsible? [7]. Executing the validation obligation(task 4) is impossible for human users. Consequently, exceptfor task 3, no user is able to realize these tasks and must beaided by trustworthy sotwarewith trustworthy conigurationdata. It should be noted that all these tasks must be executedwhen in fact most of users do not have any knowledgeabout what certiication authorities are and, furthermore,when they are in the middle of performing some muchmore important application task (such as making a purchaseon the Internet). his was demonstrated through severalexperimental studies [8–11].

hus, web users must depend on other entities to helpthem achieve these obligations. We use the term recom-mender for those entities who provide the sotware andconiguration data. Web browsers are one of the best knownexamples that users may use. hree categories of recom-menders can be distinguished; the irst category proposesonly to realize the validation obligation (task 4) and partiallytask 3 by checking the key usage ield, such asChrome,Opera,and IE. he second category realizes tasks 1 and 2, such asMicrosot andApple by distributing trust CA lists in their OS.he third category implements tasks 1, 2, 3 (partially), and 4on behalf of users, such as Firefox.

While the aforementioned examples of recommendersare known entities, no countermeasure exists that may limitthe dependence of web users on other unknown entities.For example, any unknown mobile application developermay also realize the aforementioned obligations on behalfof smartphone web users (how many unknown web clientsexist on AppStore and GooglePlay stores?). Additionally,many mobile applications integrate embedded browsers intotheir primary services, like the Facebook application. Allthese kinds of recommenders may expose (intentionally ornot) web users to MITM attacks. Finally, any computermanufacturer may also manipulate the list of CAs (realizingtasks 1 and 2) before shipping the computers to their clients(e.g., Dell).

Trusting diferent lists of CAs (trust list) provided bydiferent OS/browser editors can make the web users con-fused. Indeed for the same website, a web user may getdiferent responses depending on the application (IE, FF, andChrome)/platform (Windows, Linux, and Android) adoptedby the user to access the website. On one hand the list of CAsis diferent from one application/platform to another. On theother hand, the quality of the validation process depends onthe understanding of the application/platform developer to

Security and Communication Networks 3

?

?

Figure 2: Web users dependence on almost anyone for validatingcertiicates.

Unconscious trust

Certiication authority

Conscious trust(contract)

Certiicate holderWeb user

?

Figure 3: Current trust model for web users.

the related standards, even when the latter may not be clearabout diferent points of validation [12].

From the trust point of view, the relation between the webuser and the recommenders is constructed on an unconsciousbasis. Indeed, users are primarily concerned with their taskin hand (Internet suring, social network, FTP client, buyinga computer, etc.) and they believe that no harm will cometo them when accepting the services of their recommenders.We call this kind of relation unconscious trust (see Figures 2and 3). his is in direct contrast to the relationship betweenthe certiicate subject and their issuing CA. In this case thesubject has made a conscious decision to trust a particular CAand has cemented this trust by paying the CA a fee for theircertiicate.

In real life, all of us make unconscious trust decisionsto handle the complexity of our world [13]. For example,we cross the streets without caring about car drivers andwe go to the street without carrying irearms. In this case,our unconscious trust is justiied by the rarity of bad events.However, this unconscious trust transforms to conscioustrust only when the frequency of bad events increases. his

supposes that humans are able to detect the dangers and badevents. However, on the Internet users are unable to detectthese problems; they depend on experts to detect them andinform them. Clearly, web users on the Internet will continueto depend unconsciously on the services of unknown entities.he major risk of this kind of relation is that the uncon-scious trust in recommenders is usually transformed intounconditional trust that gives the recommenders completediscretionary power over the web users.

hus, the repeated attacks happening every day comefrom the fact that web users trust almost everyone in theworld to validate the X.509 certiicates they receive. his factleads us to ask the question: “what is the beneit of a PKI if inthe end we need to trust almost everyone in the world, in orderto be able to use it?” We believe that the current managementof thewebTLS system is broken and that PKIwith the currentmanagement model is not it for purpose.

Diferent programmes have been proposed to improvethe current web TLS system (e.g., Certiicate Transparency[14, 15], Sovereign Keys [16], and Public Key Pinning [17]).While those programmes prove the deiciency of the currentweb TLS system, they only partially handle the problemsof the current TLS system. For example, the CertiicateTransparency programme of Google proposes a public onlinemonitoring and auditing system. he objective is to bringtransparency to certiicate issuing so that a web user candetect in real time any fake certiicate. he success of thisambitious programme depends on the participation of allTLS system stakeholders (OS providers, CAs, web browsers,and domain owners). Currently only Google Chrome andCAs that are issuing EV certiicates are included in thisprogramme. Ultimately, this will help web users uniquelyto realize task 1, but not the other tasks. hus, this kindof solution increases the dependency of web users on otherunknown entities who are partially handling the web users’needs.

It is important to consider the current TLS systemas a whole, which is built on the benevolence of all therecommenders between the certiicate subject and the webuser. We believe that providing end-to-end security betweencertiicate subjects and web users begins by the identiicationof all the responsibilities of all the recommenders interveningbetween web users and certiicate subjects. he current webTLS system must be improved to remove any source ofconfusion for web users. he PKI industry soon realized thatthe PGP approach for distributing public keys would notwork efectively or eiciently on the Internet. Havingmultiplerecommenders in PKI is moving nearer to the PGP trustmodel. Entities that are providing the obligations of web usersshould not be computer programs provided by any unknownentity in the world.

Originally, X.509 was based on the 3-cornered trustmodel (see Figure 4): the certiication authority (CA), thecertiicate holder (or subject), and the Relying Party (RP). Ina previous paper [18], we have shown that the original X.509trust model is not suicient for the Internet. We proposedthus to add a new role of Trust Broker (TB) to the originalX.509 trust model (see Figure 5). he TB is independent ofCAs and plays the roles of both technical and legal expert


Relying party

(RP)Certiicate holder

Certiicationauthority

(CA)

Indirect contractual relation

Direct contractual relation

X.509

Figure 4: Original X.509 trust model.

Relying party

Certiicationauthority

Direct trust relationship

Public key certiicate

Evaluation

Trust broker

Certiicate subject

Figure 5: he new X.509 trust model.

for helping the RPs (web users). By explicitly adding thisrole to the original X.509 trust model, the task of RPs issimpliied, and the responsibility of the entity acting as a TrustBroker can be formally engaged. From the user’s point ofview, whatever number of platforms and applications theymay use to access a website, they will always get the samerecommendation from their contracted TB to help themmake an informed decision.

It should be noted that assessing the trustworthiness ofa Trust Broker is much simpler than assessing the trustwor-thiness of all Internet based CAs. Firstly, RPs only need toassess their trust in a single TB who will then help themdecide about all certiicates from all CAs. Secondly, RPs willhave a contractual agreement with their chosen TB, based onlocal contract law, rather than having to rely on the manydiferent national contracts laws employed by the existingCAs. In essence, choosing a TB will be similar to choosingan insurance policy, which users are already familiar with.

Our contributions to the problem of trust managementfor PKIs are multiple. In [19], we clearly identiied the reasonsbehind the interoperability problems of PKIs.his has helpedus to understand the root causes behind the failure of PKIs onthe Internet (open PKI deployment model). In [18], we have

proposed to formally extend the original X.509 trust model,by adding the TB entity.his newmodel is now incorporatedin the eighth edition of the X.509 standard [20].

In [21], we proposed to quantify the quality of cer-tiicate (QoCER) to allow RPs to make a decision aboutthe certiicate. he QoCER score is calculated based onthe evaluation of the procedures announced by the CAsand their commitment to apply them. he QoCER value iscompleted by another parameter, called the quality of control(QoCTRL), which states the degree of conidence on thevalue QoCER. Although, the couple (QoCER and QoCTRL)can represent the information sent by the TB to the RP, thiscalculation model sufers from multiple issues.

Issue A.he calculation of CAs’ reputations is subject to collu-sion attack. Some recommenders (in particular unknownRPsand certiicate holders) can collude to improve the reputationof CAs or inversely to incriminate well-behaved CAs.

Issue B.his calculationmodel does not describe precisely theaggregation and the collection approaches of recommenda-tions.

Issue C.he calculationmodel does not address the scalabilityissue.his work does not help the TB entity to evaluate a largenumber of CAs in a reasonable time.

Issue D. Finally, this work was theoretical only. We did notstudy the issues related to users’ decision-making process.

he calculation proposed in [21] faces these issues becausethe four-cornered trust model was not deined at that time,and the problem of PKI interoperability was not clearlyexpressed.

In this article, we improve our original calculationmodel.he maturity that we gained from the PKI interoperabilityissue and from the 4-cornered trust model has allowed us tocome up with a list of requirements that any trust calculationmodelmust conform to.hese requirements are independentfrom any trust calculation methods. In addition, we enhanceour calculation model to comply with these requirements, inparticular:

(1) his new calculation model addresses the problemof collusion attack (issue A) by deining two groupsof recommenders: identiiable recommenders andunknown recommenders.he recommendations sentby identiied entities can be automatically acceptedbut weighted according to the degree that the TBservice believes in their recommendations. However,the TB must validate the recommendations providedby unidentiied entities before being accepted. hisincreases the reliability in the calculation. Equations(5) and (8) have been updated in Section 4.2.2 toimplement this issue.

(2) We add a preparation stage (Section 4.2.1) to thecalculation of CAs’ reputation to copewith the secondissue (issue B). he TB entity can set the types ofrecommenders, the collection method (automatic,


manual, etc.), and the types of recommendations(positive or negative) for each trust factor.

(3) he scalability issue (issue C) is handled by proposinga semiautomatic evaluation process (cf. Figure 7).heprocess is designed to be open to allow TB services todeal with diferent kinds of CAs’ policies and to avoidrefusing CAs because of interoperability issues.

(4) Finally, we have implemented this calculation modelto demonstrate the feasibility of our proposal in thecontext of the web (Section 5). his implementationhighlighted some drawbacks in the original theoreti-cal model in decision-making process (issue D). Weimprove this point by (i) sending contextual infor-mation to the RPs so that they can make informeddecisions about certiicates and (ii) returning only onequality value instead of two.

he rest of this document is structured as follows: Section 2presents the existing trust building approaches that may helpRPs to make informed decisions about certiicates. We showthat none of these approaches can be applied eiciently tohelp RPs with unknown CAs, so in Section 3 we presentour uniied approach along with a set of trust evaluationcriteria that any efective trust building approach must fulil.Section 4 presents our trust calculation model and we showhow it satisies the criteria. In Section 5wepresent a prototypeimplementation demonstrating how Internet users (RPs) canmake informed decisions about web server certiicates. InSection 6, we show how the 4-cornered trust model canimprove the security of web users. Finally, in Section 7, wepresent our conclusions and proposed future work.

2. Existing Approaches to Building Trust

here are several alternative approaches that permit a RP totrust a certiicate but all entail two important mechanisms:

(i) A contractual process for recognizing CAs: this isused to prove that a given CA meets the legal andtechnical requirements of trustworthiness and inter-operability.

(ii) A mechanism for conveying the recognition of trust-worthyCAs into theRPs computer system: this is usedto provide information about the trustworthiness ofa CA in a machine-readable format, so that whenthe RP’s sotware receives a digital certiicate it canautomatically decide to accept it or not. his isachieved via coniguration of at least one root of trust,or trust anchor, into the RP’s system by some out ofband means. Subsequently certiicate chains can becarried in an application level protocol. Providing thechain starts at an already conigured root of trust, thenthe entire set of CAs in the certiicate chain can betrusted.

he alternative approaches can be classiied into three maincategories: (1) trust topologies managed by CAs themselves,(2) a list of roots of trust managed by the RP or by a trustedthird party (TTP) that is independent of the CAs and is acting

on behalf of the RP, and (3) a hybrid approach in which rootsof trust are managed by the RP or a TTP and subordinateCAs are managed by the CAs themselves. One of the maindiferences between these approaches is their applicabilityto deployment models of PKI, closed or open. he opendeployment model is where all CAs on the Internet are ableto be trusted by RPs, whereas the closed deployment modelis where only a limited subset of CAs can be trusted.

he implementation of CA managed topologies in theopen model is not feasible. One could imagine a topologycomposed of cross-certiied national root CAs in which eachroot CA manages cross-certiication processes with theirsubordinate CAs located in their jurisdictions. However, eventhis cannot be easily achieved for several reasons:

(i) Technically, this topology cannot be implementedbecause of the diiculty of managing long certii-cation paths [22]. he validation process requiresseveral checks to be made along the certiication path(e.g., policy constraints, certiicate status, and policymappings). he complexity increases with the size ofthe certiicate chain.

(ii) his topology is similar to a general accreditation sys-tem where all CAs must be certiied by their nationalauthorities. However, countries do not have the sameviewpoint concerning the right organizational modelof PKIs. For certain countries, national accreditationmay limit innovation and competition between CAs.

(iii) Imagining that the national CAs (root or bridge)can cross-certify each other implies that a technicaland legal harmonization can be conceived betweendiferent nations. In reality this is too diicult toachieve because of cultural and legal diferencesbetween countries.

(iv) his topology requires a standardization of the certii-cation process so that a cross-certiication realized byone national CA would be accepted by other nationalCAs.However, there is no standard cross-certiicationprocess today.

Alternatively, trust in a certiicate can be recommended byany entity independent of CAs. Users in a given communityof interest can obtain information and advice from the leaderof this community about the relevance of certiicates fortheir transactions.his recommender should have a technicaland legal expertise suicient to inform its users about therelevance of a certiicate for a given type of transaction. herecommender could be a government (e.g., PKI Gatekeeperin Australia [23]) or any organization such as a sotwarevendor (e.g., Microsot or Mozilla).

In general, the recommenders create a list of minimumrequirements and recognize all CAs whose certiicates haveassurance levels greater than the minimum requirements.Web browsers are the best known examples of this approach(Microsot Root Certiicate Program [24] and Mozilla CACertiicate Policy Inclusion [25]).

In contrast to the previous approach, this approach hasonly one mechanism used to transmit the recognition ofcertiicates, which is the trust list. here is no homogeneous


way to deine or formalize the trust lists. While some lists ofcertiicates are just simple lists (e.g., stores of certiicates inweb browsers) where RPs can themselves add, edit, or deletecertiicates, others can be signed lists by the recommenderwhere RPs cannot modify the list. From an interoperabilityviewpoint, the trust list replaces the cross-certiicates used byCA managed topologies. he user trusts the issuer of the listand transitive trust extends this to the CAs contained in thelist. As a consequence, the issuer of the list plays the role oftrust anchor but is not a CA.

hanks to the independence of the recommender fromCAs and the absence of need to build certiication pathsfor the validation of certiicates, the recognition approachis more convenient to the open deployment model of PKIs.However, the current application of this approach is notoptimal for the open deployment model, for several reasons:

(i) he nature of the RP’s relation with the recommenderis not formally deined. It can be formal as in the caseof the Gatekeeper strategy [23] or nonformal as in thecase of web browsers.

(ii) he cross-recognition process is a manual nonre-producible process; it is performed manually byexperts who should examine very large documentsthat include a lot of political and legal information.

(iii) his approach provides only a binary response, rec-ognized or not. Unrecognized certiicates are notbanned to RPs since they are constantly exposed tothem and a decisionmust be made. For unrecognizedcertiicates, RPs may still be invited to inspect thepolicies of CAs to decide whether the certiicatesare suitable for their transactions or not. he bestknown example is the web browser, when RPs receivecertiicates signed by CAs that are not included in thetrust list of their browser. he RP is asked to take adecision about the untrusted CA’s certiicate.

In the hybrid approach, the roots of trust are managed bythe RP or a TTP on the RP’s behalf, and additional CAs aremanaged by the root CAs themselves. hese additional CAsare termed subordinate CAs (of the root CA) and are fullytrusted by the root CA. Consequently certiicate chains arereceived by the RP and certiicate path processing is requiredby the RP’s sotware. he hybrid approach is the one used onthe Internet today in the open deployment model.

3. The Unified Approach: A New Approach forBuilding Trust in X.509 Certificates

Establishing trust in a certiicate requiresmanaging technical,organizational, and legal issues. his task is complex, so thatonly technical and legal experts can perform it. It is notconceivable to delegate this task to unskilled people acting asRPs. To address this challenge, we propose a new approach formanaging the trust in certiicates, which we call the “uniiedapproach.”his can help RPs to take eicient decisions aboutcertiicates for both the open and closed PKI deploymentmodels.

Our approach combines the advantages of the currenttrust topologies. It goes further by realizing new criteria thatcan increase the eiciency of the RP’s trust decision, such asthe reliability of recommendations.

In the closed model, the administrators of PKIs andthe jurists of organizations play the roles of technical andlegal experts to help their respective employees to decideabout certiicates coming from other organizations. hetrust relationship between RPs and their experts is naturallycreated because they belong to the same organization. hetrust of the RPs in their administrators is not only relatedto the quality of the certiicates they provide but also ontheir ability to recommend the CAs of other organizations.In addition, the decisions of the RPs can be automaticallyconigured because the interconnection topologies are otenbuilt for a predeined number of services related to the natureof the collaboration between the organizations.

In the open model, the situation is far more complex forseveral reasons:

(i) here is no explicit and balanced predeined trustrelationship between RPs and experts. For example,web browser editors play implicitly this role as theymanage a list of trustedCAs, but there is no agreementbetween the RPs and the editors to hold the editorsresponsible for the information they provide.

(ii) he scope of the certiicate’s usage is open (i.e., notlimited to predeined speciic services). he conse-quence is that web browsers do not provide enoughinformation to make an informed decision. he rec-ommendation is binary (trusted or not recognized,e.g., an icon in the URL bar is blue or not). All trustedCAs are stored in the same trusted list; thereforeCAs with diferent trust levels are equally trustedregardless of the usage of the certiicate.

All these ad hoc solutions, either for the open (e.g., webbrowser approach) or for the closed model implicitly, includethe role of expert. he diferences lie in the nature of theentities playing the role of expert, in the type of trust linkingthe expert with the RPs, and in the nature of the informationthat the expert supplies to RPs.he role of the expert has beenadded to the latest X.509 trust model, as shown in Figure 5.his explicitly separates the role of certiicates’ manager fromthe role of expert. hus, the new trust model for X.509 PKIsis composed of four entities: the Trust Broker, RPs, certiicateholders, and CAs. Each entity in this approach has a speciictask/responsibility as follows:

(i) CAs are responsible for managing certiicate lifecy-cles.

(ii) Certiicate holders must responsibly use the certii-cates given to them by the CAs.

(iii) RPs must take decisions whether to accept certiicatesor not.

(iv) TBs are responsible for evaluating CAs on behalf ofRPs (analysis of CP/CPS, auditors, etc.).

he TB evaluates the CAs and sends recommendations toRPs for helping them to take informed decisions about


certiicates. In this case, the trust model becomes fairer toRPs because they are protected by one entity, that is, theirtechnical and legal expert. According to this model, RPsrely only on the recommendations of their technical andlegal expert and not on each and every CA presented by thecertiicate holders. he relation between the TB and the RPmust be regularized by an explicit contractual agreement. Insuch an agreement, the TB recognizes its responsibility tothe RP about its provided recommendations and respects theprivacy of the RP. he TB must be independent from theCAs. However, its relationship with CAs may be regularizedby explicit agreements, so that the TBs can transfer theresponsibility to a CA when a false recommendation isgiven due to incorrect information provided by the CA. hecontractual agreements between the RPs and the TBs can beachieved in several ways:

(i) By commercial services, similar to insurance services,whose business model is to sell recommendationsabout certiicates

(ii) By national organizations whose role is to protectconsumers

One of the main advantages of the TB approach is that itresolves the interoperability problem of PKIs by transform-ing it into a trust management problem. he persistenceof interoperability problems creates a trust managementproblem; if there was a compatibility between PKIs at thejuridical, organizational, and technical levels, there would notbe a trust management problem because there would be alimited number of classes of globally accepted certiicates,where each class met a speciic context of use. However, thecultural juridical and technical diferences between coun-tries are profound. hus this theoretical solution cannot beimplemented in practice. he TB approach does not removethe interoperability obstacles, but rather it admits theirexistence and tries to inform RPs about the risks resultingfrom the interoperability problems. his approach acceptsinteroperability problems because it handles all certiicatesregardless of the technical and legal rules applied whengenerating the certiicates. In the following sections, we irstgive a deinition of trust in a CA and then deine a listof criteria that the uniied approach must meet. Finally wepresent our underlying trust calculation model.

3.1. Trust in Certiication Authorities. he phrase “trust in aCA” has been used without explaining what it means exactlyfrom the perspective of RPs. It is important to deine thisconcept before presenting the calculation model. One shoulddiferentiate between the terms “trust in a CA” and “trust ina PKI.” hus, “trust in a PKI” implies trust in all the CAsthat a PKI contains. However, for the RP that is executing atransaction, it is only important to evaluate the trust it canhave in the CA that has signed the certiicate used in thetransaction and in every CA between this CA and the rootof trust.

Although trust seems intuitive to humans, there is no con-sensus on one single deinition. he concept of trust sufersfrom an imperfect understanding, a plethora of deinitions,

and informal use in the literature as well as in everyday life[26]. his is compounded on the Internet, where diferentmeanings and terminologies can be identiied by languageand/or culture. For example, the English language providestwo words to express two dimensions of trust: “trust” and“conidence,” while the French language knows only oneword “coniance.”he English language also provides conciseand accurate terms to refer to the partners in a trustingrelationship, namely, trustor and trustee, whereas the Frenchlanguage lacks these nouns.

he diferences between the deinitions of trust are alsofound depending on the discipline of the authors. Psychology[27], sociology [28, 29], and philosophy [30, 31] are alldisciplines that have devoted eforts to the study of trust.However, by inspecting these deinitions, we ind that theyare generic and applicable to many areas.heymay implicitlyinclude many aspects. It is therefore necessary to specify thedeinition of trust that explicitly details all the importantaspects of trust in a given area.

In our view, trust in a CA from the perspective of a RPmust be established in terms of the security and reliabilityof the CA’s services. his depends upon both human andcomputer systems. However, the characteristics on which werely to trust technological systems are diferent from those totrust humans. Jøsang [32] explains this diference in the ieldof information security as follows:

(i) he security that emerges from a human being isbenevolence to that person, while the security of asystem is the ability to resist attacks. he benevolenceof a person means that he/she is honest and straight.(S)he is honest if (s)he respects their words andstraight if (s)he respects the rules.

(ii) he reliability of a person is represented by his/herqualities such as experiences and skills, while thereliability of a system is its ability to continuallyperform a speciic task.

hus, the security and reliability of a CA’s services aredependent upon the security and the reliability of all theentities involved in the certiication process, both human andtechnological. As a consequence, we deine the trust in a CAas “Dependence on the ability of people, systems, physicallocations, and sotware of a CA, as well as on the benevolenceof the CA provider to provide the required security serviceswhile complying with the relevant legislations.”

In this deinition, we consider people are the individualsworking in both the CA’s and PKI provider’s organizations.heir security characterizes their commitments to the secu-rity policies (CP/CPS) and the relevant legislations, while thereliability represents their skills and experiences in the ieldof PKI. he security of systems and sotware is the ability ofthese entities to resist attacks, while their reliability meansthat they are capable of performing tasks continually andwithout errors.

he given deinition demonstrates the expectations ofRPs towards CAs. he expectations of certiicate holderstowards their CAs are deined through contracts. Similarly,


TB service

Other information

What is the quality of the certiicate ofthis CA?

CLoA: certiicate level of assurance

RP

Contextdetector

⟨CLOA⟩

+

Figure 6: he TB service.

the relationship between RPs and their TBs will be regular-ized through contracts.

3.2. Trust Evaluation Criteria. Trust evaluation in both theclosed and the open models of PKIs should realize thefollowing six criteria (note that we do not specify generalsotware engineering criteria such as eiciency and ease ofuse):

Criterion 1 (the evaluation process should be carried out byan expert on behalf of the RP). he recognition of a CA atthe technical and legal level is too complex for most users;therefore it should be made by an expert working on behalfof the RPs.

Criterion 2 (recommendation retrieval should be simple anddynamic). he process of retrieving trust recommendationsfrom an expert should be as simple as possible for RPs andshould be dynamic to cater for changing situations.

Criterion 3 (certiicate evaluation should be global in scope).he approach should be able to analyse all certiicates that RPsmay receive, regardless of the technical, legal, or geographicposition of the issuing CA.

Criterion 4 (recommendations should be relevant to thecontext of use). Trust recommendations must be as relevantas possible to the context of use (e.g., authentication ofFTP server, bank server, or merchant server for a paymenttransaction). his allows RPs to take the most efectivedecision without applying considerable mental efort.

Criterion 5 (the privacy of the RP should be respected). heexpert should not learn anything about the transaction theRP wishes to undertake.

Criterion 6 (the reliability of the recommendations). hetrust evaluation must consider the reliability of the trustrecommendations.

4. Trust Calculation Model

To help RPs decide about the trustworthiness of subjectcertiicates, a set of quantitative and qualitative informationis sent to them. he Trust Broker (TB), as proposed in thenew X.509 trust model, fulils the irst criterion and canset up a service that provides this information to RPs (seeFigure 6).he retrieval of recommendations can therefore bemade simple and dynamic (Criterion 2). Furthermore, there

is no need to handle long certiicate validation paths as isthe case for CA managed topologies. In the TB model, theTB is the root of trust for all CAs. Consequently, the RPonly needs to send the CA’s certiicate to the TB service. hesubject’s certiicate is not needed, since the CA applies thesame procedure to all its issued certiicates. Furthermore, thissatisies the 5th criterion or privacy, since the TB does notknowwhich certiicate holder the RP is communicating with.

he TB service returns other information that can helpthe RP to make an informed decision. For example, when anRP needs to know the liability of the CA in case of problem.he determination of any liability information is obtainedfrom the CP of the CA by the TB service and relayed as otherinformation to the RP. In addition, we have added a contextdetector at the side of the RP in order to detect the actualapplication context. By doing this, the TB service realizes the4th criterion.

At a purely quantitative level, the TB service sends ascore between 0 and 1 that represents the trustworthinessof the subjects’ certiicates in general, called the certiicatelevel of assurance (CLoA). his satisies the 3rd criterion.When the CLoA is 0, the CA’s procedures for managing thesubjects’ certiicates are judged by the TB to be very weakor nonexistent. When the CLoA is 1, the applied proceduresare judged to be very strong and faultless. he calculationof CLoA depends on multiple factors, namely, the CA’spublished procedures (QoCPS), the CA’s actual procedures(QoCA), and the conidence the TB has in the CA to adhereto its procedures (CL). his satisies Criterion 6.

To calculate the certiicate level of assurance (CLoA), wepropose the following formula:

CLoA = �√CL ∗ QoCA ∗ QoCPS, (1)

where (i) QoCPS ∈ [0, 1] represents the robustness of theCA’s published procedures in its CP/CPS documents. hevalue 0 represents the weakest procedures and 1 the strongestprocedures. (ii) QoCA ∈ [0, 1] represents the degree of theCA’s commitment to its published procedures. It is basedon recommendations provided by third parties that monitorthe real practices of a CA such as audit agencies and theRPs themselves. he value 0 represents that there is noevidence to indicate that any statements in the CP/CPShave been respected, while 1 indicates that every statementin the CP/CPS has been implemented according to therecommenders. (iii) CL ∈ [0, 1] represents the degree ofconidence that the TB has in its calculation of QoCA (weassume the TB always has 100% conidence in its calculationof QoCPS). he value 0 means either there is no evidence onwhich to calculate QoCA or the TB has zero conidence in theevidence that is there, while the value 1 indicates that there isadequate evidence for the TB to validate every statement inthe CP/CPS. CL can be 1 when QoCA is zero, meaning thatthe TB is certain that QoCA is low. (iv) � is an integer valuethat allows the TB to control the impact of CL∗QoCA on thescore of CLoA.

he maximum value of CLoA is QoCPS because QoCPSrepresents the published robustness of the CAs proceduresfor managing certiicates. However, this maximum value can


Weight of each factor

compared to other factors

List of parameterized trust

factors

Utility functions for the values

of the atomic trust factors

(leaves)

Knowledge

Calculating the

QoCPS (0 and 1)

New

values?

Analysis of new

values of atomic

trust factors

Response

from the CA

Update

Update

Update

Update

CATB

List of parametrizedtrust factors

All possible values+

Figure 7: he semiautomatic process for computing QoCPS.

be degraded because either the CA does not fully respect itsown procedures, or the TB does not have full conidence ineither the CAs stated procedures or the recommendationsabout them.his means the value of both CL and QoCA candecrease the value of QoCPS to relect the TB’s assessment ofthe overall CLoA.

4.1. Computing theQuality of the CPS (QoCPS). We introducea semiautomatic process used to determine the quality ofthe CP/CPS documents, as shown in Figure 7. We proposea technique for structuring CP/CPS documents so that theycan be understood by computers, and then an algorithmwill be used to determine the quality level of the CP/CPSdocuments (QoCPS).

4.1.1. CP/CPS Structuring. he natural language used fordescribing the Certiicate Policy and practices of a CA isone of the main obstacles in determining the trustworthinessof a CA. In order to automatically interpret the CP/CPSdocuments, we model the CP/CPS documents as a treestructure (as illustrated in Figure 8) inspired by the de factostandard RFC 3647, which deines a common frameworkfor CP/CPS documents. he structure is composed of nodesand leaves, where leaves are atomic trust factors and nodesare complex trust factors (i.e., a combination of atomic andcomplex factors).

For example, “Technical Security Controls” is a nodecomposed of the following nodes, where ≪ ≫ represents anode and < > represents a leaf:

(i) ≪Key Pair Generation and Installation≫(ii) ≪Private Key Protection and Cryptographic Module

Engineering Controls≫(iii) ≪Other Aspects of Key Pair Management≫(iv) ≪Activation Data≫(v) ≪Computer Security Controls≫(vi) ≪Life Cycle Security Controls≫(vii) ≪Network Security Controls≫(viii) ≪Time Stamping≫

he node ≪Key Pair Generation and Installation≫ is com-posed of the following nodes:

(i) ≪Key Pair Generation≫(ii) ≪Private Key Delivery to Subscriber≫(iii) ≪Public Key Delivery to Certiicate Issuer≫(iv) ≪CA Public Key Delivery to Relying Parties≫(v) ≪Key Sizes≫(vi) ≪Public Key Parameters Generation and Quality

Checking≫(vii) ≪Key Usage Purposes≫he node ≪Key Sizes≫ may have the following trust

factors (leaves):

(i) <6.1.5.f1[X,Y]> represents size � of the public key ofthe CA certiicate for algorithm�, for example, [1024,ElGamal].


Introduction

Publication and repository

responsibilities

Identiication and

authentication

Certiicate life-cycle

operational requirements

Technical security controls

Management, operational,

and physical controls

Certiicate and

CRL proiles

Compliance audit and

other assessments

Other business and

legal matters

CPS document

Key Sizes

Key pair generation

Private key delivery

to subscriber

Public key delivery

to certiicate issuer

Key pair generation

and installation

0.05

0.05

0.2

0.1

0.2

0.1

0.1

0.1 0.2

0.20.5

0.1

0.1

0.25

0.25

0.25

0.250.25

0.25

0.250.25

6.1.5.f1

6.1.5.f2

6.1.5.f3

6.1.5.f3

Figure 8: Weighted CP/CPS tree structure.

(ii) <6.1.5.f2[X]> represents the hash algorithm used bythe certiicate of CA, where � ∈ {SHA-1, SHA-224,MD5}.

(iii) <6.1.5.f3[X,Y]> represents the public key size � ofcertiicate user for algorithm �.

(iv) <6.1.5.f4[X]> represents the hash algorithm used bythe certiicate user, where � ∈ {SHA-1, SHA-224,MD5}.

he node ≪Key Pair Generation≫ may have the followingleaves:

(i) <6.1.1.f1[X]> represents cryptographic modules usedby CAs for the generation of keys according to therequirements of standard �, where � ∈ {FIPS 140-1 level 1, FIPS 140-1 level 2, FIPS 140-1 level 3}.

(ii) <6.1.1.f2[X]> represents cryptographic modules usedby users for generation of keys according to therequirements of standard �, where � ∈ {FIPS 140-1 level 1, FIPS 140-1 level 2, FIPS 140-1 level 3}.

(iii) <6.1.1.f3[X]>: generating the key pairs of the end useris performed by the user himself, where � ∈ {Oui,Non}.

(iv) <6.1.1.f4[X]>: generating of the key pairs of the enduser is performed by the CA or RA, where � ∈ {Oui,Non}.

In each leaf, the TB service deines a set of possible valuesthat are semantically known by the TB and the CA.he typesof values can be simple answers (yes/no), numerical values,dates or names of standards, and so forth. he trust factorsmust be independent of each other; if not, they must form acomplex node. We give each trust factor a reference numberthat corresponds to the section number of RFC 3647.

he obtained structured ile constitutes the knowledgeof the TB at time �. his knowledge can be represented inan XML ile. he knowledge about a particular CA can becompleted in one of two ways. Either the TB can downloadthe CA’s CP/CPS, read it, and complete the XML ile himselfwith the CA’s published values, or the TB can send the XMLile to the administrator of the CA and ask the latter tocomplete it. If the answerer inds the XML ile is suicientto represent a CA’s CP/CPS, then the quality of the CPS canbe automatically calculated (see next section). Otherwise theanswerer should indicate to the TB that new values from theCP/CPS aremissing in theXMLknowledge ile, so that theTBcan analyse them and extend his knowledge. For example, if


Table 1: Trust Utility function for the atomic trust factor 6.1.5.f1 ofKey Sizes.

Utility Algorithm

0 (256, RSA)

0 (512, RSA)

0,25 (1024, RSA)

0,8 (2048, RSA)

0,9 (2048, ElGamal)

1 (4096, RSA)

one CA uses a hash algorithm XYZ that is not present in theknowledge ile, then this should be indicated to the TB so thatit can be considered for the next version of the ile.

4.1.2. he Calculation of the Quality of CP/CPS Documents.To determine the QoCPS value, the TB must irst deine therelative importance of each factor with regard to the otherfactors (Figure 8) that comprise a complex node. he relativeimportance of all arcs leading to a node must add up to 1.0.

For each atomic trust factor, the TB uses a utility functionto deine the relative importance of each possible value withregard to the other values. For example, Table 1 representsthe utility function for the atomic trust factor <6.1.5.f1[X,Y]>of node ≪Key Sizes≫. It gives the value 0.25 if the key sizeis 1024 bits, and the algorithm is RSA. It gives the value 0.9when the key size is 2048 bits and the algorithm is ElGamal.he QoCPS value is the recursive weighted sum of all utilityfunctions for all the atomic trust factors:

QoCPS (��) = ∑�∈children(�)

�� ∗ QoCPS (��) , (2)

where (i) �� is a node and �� is a node or a leaf and (ii)QoCPS(��) = �(��) where �� is atomic trust factor. � is

the utility function. he utility function allows TBs to deinediferent strategies for trust calculations and forms part oftheir intellectual property. �� represents selected value for

the atomic trust factor ��; (iii) �� is the weight between the

factors �� and �� in the CP/CPS tree.Clearly, the values of atomic trust factors will evolve over

time. hese values may be added, changed, or even deleted.Similarly, the utility function must be able to evolve overtime. For example, the strength of a cryptographic algorithmtodaywill not be the same ater several years.he values givento the various atomic trust factors and utility functions aredetermined by the TB according to his expertise. his is hisintellectual property and will determine in part the value ofhis TB service in the market place.

Finally, in order to enable the TB to handle all CAsregardless of their technical and juridical level, the list of inputvalues for the atomic trust factors must be published by theCAs in their CP/CPSs. For example supposing that the TBservice has the following values {SHA-1, SHA-224, MD5} forthe hash algorithm trust factor. If a CA uses an algorithm notincluded in the list (such as SHA-512), the TB service analysesthis value, and it updates the corresponding utility functionand references it in the revised list of values.

4.2. Computing the Quality of CA (QoCA). he objectiveof the quality of CA (QoCA) is to show the degree ofcommitment of the CA to its CP/CPS documents. Naturally,the audit agencies are the main entities that can provideinformation about the real commitments of CAs. In fact, therole of the audit agency is very important because a lot ofpractices can be only understood and reviewed by it. By virtueof the audit agency, the authentication of the evaluated CAis guaranteed and its claims in the CPS ile are ensured. Forexample, the audit agency is the only entity that is able toverify the claim of the CA when it states that its private key isgenerated and stored in a physically secured environment.

However, the audit agency is not suicient to provide areliable guarantee of total conformity for diferent reasons[33]:

(i) Time. he veriication made by an auditing agency isneither continuous nor permanent. An audit agencyevaluates a CA every year or two.his means that theevaluation conducted a year ago may not relect thecurrent state of the CA, for example, how to ensurethat the list of revoked certiicates is available 24/7.

(ii) Number of Certiicates. An audit agency cannot verifyall certiicates issued by a CA, for example, how toverify that a CA has really respected the announcedcertiicate proile in its CP/CPS for each one ofthousands of certiicates and how to verify that noneof these certiicates are free of errors (e.g., DSAcertiicates with 2048-bit primes or RSA certiicateswith a public exponent equal to 1).

(iii) he Independence of Audit Agencies. It is diicult toguarantee the independence of audit agencies fromCAs, especially because audit agencies are paid bythe CAs to perform the evaluation. We recognize thatauditors may need the permissions of the CAs torelease their results to the TB services. Governmentsmust ensure that CAs give this right to auditors or atleast that a summary of their results is made availableto TB services.

In addition, we propose new entities that can help in verifyingthe real commitments of a CA to its CP/CPS documents:

(i) Clients of TB Service. An RP depends on the TBservice for providing her with the necessary infor-mation to take an informed decision. (S)he can alsoplay the role of a recommender to the TB service byproviding it with information about the correctnessof some of the parameters announced by a CA dur-ing certiicate validation, for example, availability ofCRLs. he RP may also be a certiicate holder so thatit can send the TB service some recommendationsabout the commitments of its CA. TB clients canonly supplement the assessment of the audit agenciesbecause many parameters of the CP/CPS such asphysical controls (e.g., ire prevention and protectionof premises), procedural controls (e.g., procedures toensure segregation of duties), or personal checks (e.g.,qualiication and experience) can only be veriied by


an audit agency. he recommendations sent by theTB’s clients may need to be veriied by the TB serviceto ensure their veracity. Among the parameters thatcan be recommended by TB clients are the following:

(a) he availability of a CA’s 24/7 revocation service:this can be analysed by the RP when validatinga certiicate. When the revocation service isnot available the RP can automatically send(negative) recommendations to the TB service.

(b) he certiicate proile can be veriied automati-cally by an RP, to say whether it conforms to thedeclarations in the CA’s CP/CPS documents ornot (e.g., key usage extension). he TB providesthe RP with this when it sends the CLoA.

(ii) Competitor TB Services. TB services can share theirexperiences with other TB services who they knowor compete with, in order to help determine the realcommitment of a CA. his is similar to insurancecompanies sharing information today. In addition,cooperation between TB services can facilitate certainactions, such as the conirmation of the actual exis-tence of a CA or an audit agency. he relationshipsbetween TB services could be regulated throughbilateral agreements or trade associations. Bilateralagreements can be easily constructed, because all TBservices have the same motivation, which is increas-ing the scope and eiciency of their evaluations.Each TB service can control the impact of other TBservices on its inal result (CLoA, CL, etc.) accordingto the trust it has in the competitor TB service.Competitor TB servicesmay be reluctant to cooperatewith other TB services, especially when they arecompeting in the same market, but trade associationshelp competitors to collaborate. TB services that aredominant in diferent markets may cooperate formutual beneit. For example, a French TB servicemaycooperate with a Japanese TB service so that they canexchange useful information about CAs’ certiicatesused by their clients.

hus, we have a participative system that can be used tocompute the QoCA. We propose to apply these trust andreputation management approaches in order to compute thisvalue. We have selected the REGRET model [34], which is amodular approach formanaging trust and reputation. It takesinto account three dimensions:

(i) he Personal Dimension. It refers to direct interac-tion between entities. When entity A gives certainpromises to entity B, then entity B scores entity Aaccording to its real commitment to its promises. Forexample, seller A sets a date for the delivery of aproduct to customer B. If the product arrived aterthat date, then entity B negatively scores seller A basedon the negative impact of the delay. If the productarrived on time, entity B positively scores seller Abecause it has respected its promises.

(ii) he Social Dimension. With the social dimension,the REGRET model adds the ability to relect thecharacteristics of complex social relationships usingthe group concept. In many societies, a person inher-its the reputation of the group to which it belongs.When direct experiences with an entity are missing,the reputation of its group gives initial expectationsabout the behaviour of the entity. In the same way,an entity may use the experiences of the members ofits own group, or the group of the unknown entity, tocomplete its expectations about the unknown entity.However, we do not consider the group that the CA isa member of when calculating the reputation of thatCA. In our case, the social dimension is calculatedbased on the recommendations sent by clients of theTB and other TBs it has a relationship with.

(iii) he Ontological Dimension. he REGRET modelassumes that the reputation of a person is not asingle and abstract concept, but rather a multifacetedconcept. For example, the reputation of an airline isbased on the reputation of its aircrat, its baggagehandling, its check-in procedures, and its on boardcatering. In turn, the reputation of an aircrat summa-rizes the reputation of the maintenance service, themanufacturer, the engine, and other characteristics.hese types of reputation and the way they arecombined is the ontological dimension of reputa-tion. Note that each person could have a diferentontological structure to combine reputations and adiferent way to moderate their importance. In ourcase the ontological dimension of trust in a CA is theamalgamation of many diferent atomic trust factorsarising from the CP/CPS documentation.

In order to calculate the QoCA using this model, the natureof the recommendation values should be changed. Insteadof the recommenders providing their personal evaluationsto the TB, they should provide the actual values of theCA parameters; then the evaluation of these parameterscan be made by the TB service. For example, when a CAstates in its certiication policy that the download time of aCRL list should not exceed 30ms, the recommenders valueshould be the actual time, for example, 40ms, and not itsrecommendation score, for example, a number between 0and 1. When calculating the QoCA, the following stages areproposed for the TB service.

4.2.1. Preparation Stage. he TB service should consider anumber of important points for each trust factor:

(i) Types of recommenders: the TB must determine foreach trust factor which recommenders can validateit. he list of recommenders depends on the natureof the trust factor and some can be validated only byaudit agencies.

(ii) he collectionmethod of recommendations: this maydifer according to the nature of the trust factors andrecommenders. Audit agencies could send periodicreports to the TB service containing all the real values


found during the audit (subject of course to the agree-ment of the CA).he RPs, the certiicate holders, andother TB services could send their recommendationseither spontaneously, periodically, or on request. Forexample, for the trust factor “the availability of the24/7 revocation service,” the RPs could periodicallynotify the TB service about this factor, while forthe trust factor “in case CA is compromised, theCA should spontaneously notify all subscribers andRPs about the compromise” the collection could bespontaneous. On request collection can be achievedthrough various techniques including the use ofquestionnaires, web forms, and e-mail messages.

(iii) Types of recommendations: the TB must determinewhether the recommenders should send positiverecommendations (when conirming promises) ornegative ones (in case of nonfulilment of promises).

4.2.2. Calculation Stage. To calculate the value of QoCA, theTB service should take into account the personal, social, andontological dimensions. Two types of recommenders shouldbe considered in the calculation: identiiable recommenders,which are audit agencies, competitor TB services, certiicateholders, and client RPs, and unknown recommenders, whichare RPs who are not clients and whose identities are notknown by the TB service.

he identiication of the recommenders helps in imple-menting anticheating mechanisms that neutralize suspectrecommendations. he recommendations sent by identiiedentities can be automatically accepted butweighted accordingto the degree that the TB service believes in their recom-mendations. he weight factor indicates the impact that therecommender can have on the inal score. Determining thisweight factor is part of the intellectual property of the TBand is one of the factors in distinguishing between TBs.Recommendations provided by unidentiied entities must bevalidated by the TB before being accepted. If the cost ofthe validation of a speciic trust factor is low, for example,checking that an OCSP server is available or not, then bothnegative and positive recommendations from unidentiiedRPs can be accepted; otherwise the TB service should onlyvalidate negative recommendations as these show that theCAis failing in some respect.

Each recommender sends a recommendation � that hasthe following form:

� = (�, ca, �, V, �) , (3)

where the entity � (sender) indicates the set of actual values Vof the atomic trust factors � when it had an experience witha certiication authority ca at time �.

Let � be the set of all possible recommendations. Wedeine ��→ca�� ⊆ � as the set of the recommendations sent by �about ca for the atomic trust factor ��:

��→ca�� = {� = (��, ca�, ��, V�, ��) ∈ � | �� = �, ca�

= ca, �� = ��}(4)

he QoCA for the personal dimension of trust factor ��for the certiication authority ca can be calculated by the TBservice (�) as follows:

QoCAPersonal (��→ca�� ) =∑�∈��→ca�� (��, ��) ∗ ��

� , (5)

where (i) ��→ca�� represents all the personal evaluations of

the TB service (�) about the ca for the trust factor ��.(ii) �� is the diference between the value promised in

the CPS and the actual value calculated by the TB servicefor the recommendation �. (iii) �(��, ��) is a time-dependentfunction that gives more importance to the most recentrecommendations, where �� is the current time and �� is thetime when recommendation � has been stored. We do not ixthis function, because this function can be deined in severalways depending on the type of trust factor. his is part ofthe intellectual property of the TB. (iv) � is the number ofevaluations stored in ��→ca�� .

�� can be calculated using this function:

�� ={{{{{{{{{

� (��) ∗ 100� (��)

� (��) < � (��)

1 otherwise,(6)

where (i) �� is the measured value of trust factor ��, (ii) ��is the promised value by the CA in its CPS for the trust factor��, and (iii) � is the utility function.

QoCASoc(��) is the QoCA value for the social dimensionof each atomic trust factor (��); it can be calculated as follows:

QoCASoc (��) = ∑�∈�

��QoCAPersonal (��→ca�� ) , (7)

where (i) � is the global set of identiiable recommenders,including auditors, RPs, and competitor TBs and (ii) �� is aparameter associated with each recommender �. It is used tocontrol the impact of each recommender on the inal scorewhere ∑�∈� �� = 1. his forms yet another component of theintellectual property of the TB.

For each trust factor, the personal dimension and thesocial one can be combined to obtain one trust score asfollows:

Eval (��) = � ∗ QoCAPersonal (��→ca�� ) + �

∗ QoCASoc (��) ,(8)

where (i) �, � are conigurable parameters that control theimpact of the personal and social dimension on the inalscore, where � + � = 1.

he ontological dimension allows the TB to calculate the

inal value of QoCA.he QoCAOnto value for a leaf or a nodecan be calculated as follows:

QoCAOnto (��) = ∑��∈children(��)

�� ∗ QoCAOnto (��) ,(9)


where (i)QoCAOnto(��) = QoCASoc(��)when�� is an atomictrust factor, (ii) �� is a leaf or a node, and (iii) �� is theweighting factor between nodes �� and �� in the tree CP/CPS.Each TB will have their own values for the various weightingfactors.

he inal value of QoCA is QoCAOnto for the factorCPSdocument which is the root of the CP/CPS tree:

QoCA = QoCAOnto (CPSdocument) . (10)

4.3. Calculation of the Conidence Level (CL). he conidencelevel (CL) states to which extent the TB service is conidentabout the calculation of QoCA. Many factors can be consid-ered, but here we considered the three major factors:

(i) Number of Recommendations. For each trust factor,a minimum threshold of recommendations is set. Ifthe threshold is not reached then the reliability of thetrust factor cannot be established.When a trust factorcan only be evaluated by audit agencies, the thresholdis set to 1, otherwise it should be greater than 1.

(ii) RecommendationsHeterogeneity.hemore the valuesof recommendations are homogenous, the more thecalculation of QoCA is reliable. his factor is nottaken into account when the recommender is an auditagency.

(iii) Recommendation Dates. he more recent the rec-ommendations are, the more reliable they are. hisparameter is considered for all types of recom-menders.

he CL for the personal dimension and for the trustfactor �� is the convex combination of the three functionsrepresenting the three aforementioned factors:

CLPersonal (��→ca�� ) = �� ∗ �� (��→ca�� ) + ��

∗ �� (��→ca�� ) + �Decay

∗ Decay (��→ca�� ) ,

(11)

where (i) �� + �� + �Decay = 1 allows the TB to controlthe impact of each factor on the inal score and forms partof its intellectual property. (ii) ��(��→ca�� ) = {sin((1/2 ∗��)|��→ca�� |), |��→ca�� | ∈ [0, ��]; 1,Otherwise}; (iii) |��→ca�� | isthe carinality of ��→ca�� ; (iv) �� is the threshold ater which

the conidence value always becomes 1; (v) ��(��→ca�� ) = 1 −∑�∈��→ca�� |�� − �| gives a value between 0 and 1. he value 0

indicates that the recommendations are so diferent (i.e., notreliable). he value 1 indicates that the recommendations arehomogenous and can be considered reliable. � is the averageof the recommendations values. (vi) Decay(��→ca�� ) is a time-

dependent function that gives values between 0 and 1. It isused to indicate the freshness of recommendations owned byan entity.

CLSoc represents the CL value ater considering the socialdimension. It can be calculated as follows:

CLSoc (��) = ∑�∈�

��CLPersonal (��→ca�� ) , (12)

where (i) � is the global set of identiiable recommenders,including auditors, RPs, and competitor TBs and (ii) �� is aparameter associated with each recommender �. It is used tocontrol the impact of each recommender on the inal scorewhere ∑�∈� �� = 1. his forms yet another component of theintellectual property of the TB.

For each trust factor, the personal dimension and thesocial one can be combined to obtain one trust score asfollows:

Eval (��) = � ∗ CLSoc (��) + �

∗ ∑�∈�

��CLPersonal (��→ca�� ) . (13)

(i) � and � are conigurable parameters that control theimpact of the personal and social dimension on the inalscore, where � + � = 1.

he ontological dimension allows the TB to calculate the

inal value of CL. he CLOnto for a leaf or a node can becalculated as follows:

CLOnto (��) = ∑��∈children(��)

�� ∗ CLOnto (��) ,(14)

where (i) CLOnto(��) = CLSoc(��) when �� is an atomic trustfactor, (ii) �� is a leaf or a node, and (iii) �� is the weightingfactor between nodes �� and �� in the tree CP/CPS. Each TBwill have their own values for the various weighting factors.

he inal value of CL is CLOnto for the factor CPSdocu-ment which is the root of the CP/CPS tree:

CL = CLOnto (CPSdocument) . (15)

4.4. Discussion. Our trust model ofers two principal advan-tages; irst, it relects the diferent points of view of TBs byallowing them to conigure their own expertise into theircomputations. Second, it resolves the problem of interop-erability by adopting a calculation method based on utilityfunctions and weighting factors. Indeed, the utility functions�(��) and the weight factors �� allow several diferent

strategies for trust calculations.It should be noted that our evaluation system is designed

to consider not only technical issues but also juridical ones.hus, it is impossible to ix these trust metrics as theyrelect the lavour of TBs and their own expertise andpreferences. It is true that some trust factors can be objectivelymeasured, but their relevance for a given application remainsa subjective matter. For example, it is clear that SHA-512is stronger than SHA-256 for the trust factor of the hashalgorithm. But the relevance of SHA-256 for an applicationsuch as web server authentication is still a subjective questionfor experts. Chadwick and Basden [35] have demonstratedthis phenomenon by asking PKI experts to prioritize the


TB Service

Decisionhelper

Recommendationcollector

Decisions

store

Decision taking

Recommendations collecting

Relying partyCertiicate holder

Figure 9: he prototype architecture.

PKIs trust factors.he study concluded by demonstrating thediiculty in reaching a consensus among experts. Chadwickand Basden gave several reasons for this diiculty.

Our trust model enables the resolving of interoperabilityproblems. In fact, TBs can adapt their calculation modelsto meet the needs of their clients as well as the context ofuse. For example, in Greece, a certiicate has legal efect, ifthe retention period of electronic records is over 30 years,while in Spain it is only 15 years [36]. he utility functionthat processes this trust factor can give a high importancefor a certiicate that has a retention period of 15 years whenthe certiicate is used in Spain and low importance when thecertiicate is used in Greece. Another example is the use ofpseudonyms in certiicates. Most European countries, exceptEstonia and Bulgaria [36], authorize the use of pseudonymsin certiicates.he TB service is able to deal with this problemof interoperability between European countries using utilityfunctions. When a certiicate with a pseudonym is used inEstonia or Bulgaria, the utility function that processes thistrust factor gives a value of 0 for this certiicate.

Finally, our calculation system prevents collusion fromunidentiied entities. However, collusion from identiied enti-ties is diicult to prevent, especially if the number of conspir-ators is greater than the number of honest entities. However,each TB will be contractually linked to the identiied entities(audit agencies, other TBs, and users). If something goeswrong, the conspirators can be prosecuted.

5. Prototype in the Web Context

We have implemented a prototype in the context of the web,where the RPs are human entities accessing various websitesvia a web browser. Certiicate holders are the users whopurchase certiicates for their web servers. Our prototype TBweb service comprises two principal components (as shownin Figure 9):

Trust factor list

XML parser

Calculation of

CLoA, QoCPS,

QoCA, and CL

Recommendations

collection

TB Service

Figure 10: he TB service modules.

(i) Decision helper component: this component helpsRPs make contextually informed decisions aboutcertiicates.

(ii) Recommendation collector component: this compo-nent collects recommendations sent by client RPs.

he TB service consists of the following modules(Figure 10):

(i) he trust factors list module contains the TB’s list oftrust factors in XML format.

(ii) he XML parser module processes the XML trustiles provided by either the cooperating CAs or theTB (for noncooperating CAs). Each trust ile containsthe answers to the list of trust factors for one CA,relecting its certiication policies andprocedures (i.e.,values for the trust factors).

(iii) he recommendations collection module collects therecommendations sent by client RPs.

(iv) he calculation module computes the CLoA, QoCPS,QoCA, and CL.


<!ELEMENT KeySizes (f1 615, f2 615, f3 615, f4 615)><!ATTLIST KeySizes id (6.1.5) #REQUIRED><!ELEMENT f1 615 (#PCDATA)><!ATTLIST f1 615 KeySize (256| 512| 1024| 2048| 4096| other)#REQUIRED algorithm (RSA| ElGamal | Merkle-Hellman | other) #REQUIRED><!ELEMENT f2 615 (#PCDATA)><!ATTLIST f2 615 Hash (SHA-1 | SHA-224| MD5 | other) #REQUIRED><!ELEMENT f3 615 (#PCDATA)><!ATTLIST f3 615 KeySize (256| 512| 1024| 2048| 4096| other)#REQUIRED algorithm (RSA| ElGamal | Merkle-Hellman | other) #REQUIRED><!ELEMENT f4 615 (#PCDATA)><!ATTLIST f4 615 Hash (SHA-1| SHA-224| MD5 | other) #REQUIRED>

Listing 1: he Key Size trust factor for a particular TB service.

<KeySizes id=” 6.1.5 ”><f1 615 KeySize=” 1024” algorithm=”RSA”/><f2 615 Hash=”MD5”/><f3 615 KeySize=” 1024” algorithm=”RSA”/><f4 615 Hash=”MD5”/>

</KeySizes>

Listing 2: An example trust data structure for a particular CA.

In addition we have implemented a Firefox extensionmodule that modiies the way that Firefox handles certii-cates, by irst communicatingwith the TB service.heTB ser-vice interacts with CAs and with RP clients. In the followingsection we give more details about these interactions.

5.1. Interaction between TB Service and CAs. he list of trustfactors is made public by the TB service. It is constructedusing the XML DTD format. For example, we have deinedthe DTD component for the leaf “Key Sizes” as shown belowin Listing 3. his depicts the structure of the leaf “Key Sizes”in the CP/CPS tree. It contains four atomic factors of trust:“the size of the CA’s public key and the key algorithm,” “thehash algorithm used for the CA’s certiicate,” “the size of thepublic key of the user’s certiicate and its key algorithm,” and“the hash algorithm used for the user’s certiicate.”

Each cooperating CA picks up the trust factor list andreturns an XML ile that contains answers to the atomicfactors (see Figure 11). he cooperating CA sends this ileback to the TB service in order for it to determine theQoCPS. For noncooperating CAs, the TB must retrieve theCA’s CP/CPS and answer the questions themselves. (S)he canthen submit the resulting ile to the XML parser. he XMLcomponent for the node ≪Key Sizes≫ trust element can takethe form presented in Listing 2. If a CA uses a value that is notalready referenced in the DTD list of trust factors, then theactual value must be labelled as “other” before the trust ile isreturned to the TB (see Listing 3). For example, for the trustfactor “Key Sizes,” a CA may use the value “SHA-512.” his

<KeySizes id=”6.1.5" ><f1 615 KeySize=” 1024” algorithm=”RSA”/><f2 615 Hash=” other”> SHA-512</f2 615><f3 615 KeySize=” 1024” algorithm=”RSA”/><f4 615 Hash=”MD5”></f4 615>

</KeySizes>

Listing 3: An example trust data structure returning a valueunknown to the TB service.

Trust factor list

XML parserRecommendations

collection

TB Service

CA

Calculation of

CLoA, QoCPS,

QoCA, and CL

Figure 11: Interaction of TB service with CAs.

value is not included in Listing 1 for this particular TB service,so the QoCPS cannot be analysed automatically. When theTB service receives the trust ile, it should update the utilityfunction for this new value and update the list of referencedvalues in the DTD.

5.2. Interaction between TB Service and Clients. here aretwo types of interactions between the TB service and itsRP clients: interaction for helping clients to make informeddecision about certiicates and interaction for receiving rec-ommendations from clients about certain trust factors ofCAs.

5.2.1. Helping Clients to Make Informed Decision. here arefour main actors in this case (Figure 12):


Manage trust in CAs (calculate CLoA)

Make decision about a

certiicate

Ask for CLoA

Conigure URL of TB service in the web

browser

Forward the CA certiicate to the TB client

Manage decision databaseWeb browsers

TB client

TB

Web user

Validate the certiicates’ ields

Co

ntr

act

bas

ed r

elat

ion

Figure 12: he main actors in 4-cornered based validation system.

(i) he RP: the end user that will ultimately make thedecision to accept or reject a certiicate. he RPchooses its own web browser.

(ii) he browser extension module (TB client): the entitythat allows RPs to communicate with TB services.It manages the decisions of RPs about certiicates.It should also provide an interface to enable RPs toselect the TB service that they wish to depend on. Ourobjective is to make web browsers totally transparentin the decision-making process.

(iii) heTB service: the entity that calculates the certiicatequality information.

(iv) he web browser: the entity that forwards the CAcertiicate to the TB client.

Figure 13 illustrates the diferent steps that we haveimplemented to realize the validation of certiicates.

When a user contacts a web service via an TLS connec-tion, for example, to make an online payment, the user wantsto be assured that their information is sent to the correct webservice and that any received information comes from theright service.

he web server initially sends its certiicate to the webbrowser. It is not possible at this point in time for the webbrowser to discover the RP’s intended use of the certiicate.his is because the server’s web page can deine severalcontexts of certiicate use. For example, when a user vis-its the site https://www.somesite.com, the homepage mayhave two forms that deine two diferent contexts of use;the irst form allows the user to connect to the serverhttps://www.login.somesite.com and the second form allowsthe user to register by sending information to the server

https://www.register.somesite.com. Before sending themper-sonal or conidential data to either of these servers, the user’sbrowser must retrieve the server’s address and extract thecertiicate that is used to determine if (s)he can trust thecertiicate of the server for the speciic context. We haveidentiied three diferent contexts of use for a user sendingpersonal or conidential data to a web server:

(1) Connection login: the user will send a usernameand password to the web server and thereater willestablish a secure session duringwhichmanydiferenttypes of transaction may take place, for example,database access, ile access, and online transaction.

(2) Registration: the user will send her personal informa-tion to the web server in order to create an account.

(3) Payment: the userwill send her bank account or creditcard details to the server in order to buy a product.he user may or may not be logged in.

Our extension module monitors the behaviour of the userto see when (s)he will send their personal information to aserver. When the user clicks on the send button, the moduleextension suspends the sending, extracts the certiicate, andrequests the quality information about the certiicate from theTB service. he TB service returns the quality informationsigned by its public key (which was conigured into the exten-sionwhen the user chose her trusted TB service).hemoduleextension will then ilter the returned information based onthe certiicate’s context of use.When the context of use cannotbe determined then it shows themost informative/qualitativeinformation about the certiicate to the user.

he browser extension tries to automatically determinethe context of use based on the content of the personal data


Web user Web browser TB client TB service

ForwardCA

certiicateto TBclient

Ask forcertiicate

qualityinformation

he CA isknown bythe TB?

Yes

Yes

Yes

No

No

No

Inform theweb userwith thewarningmessage

Send awarningmessageto the TB

client

Calculateinformation

quality ofCA

certiicate

Qualityinformation

haschanged?

Decision

already

taken?

Show

information

quality to

web user

Sign qualityinformation and send

it to TB client

Takedecisionabout the

CAcertiicate Register

web userdecision

Figure 13: Illustration of certiicate validation steps.

being requested. For example, when a single ield of type“password” exists in a web form, we assume the form is usedto allow users to login to the server. When there are twoields of type “password,” we assume the form is used forthe registration of new users. When there is a ield of typecredit card type or credit card number, we assume a paymentis about to be made. However, we recognize that this is notalways the case and that there are other caseswherewe cannotdetermine the intended use of the certiicate. Consequently,we have prepared a simple questionnaire (see Figure 15) thatappears when the user irst wants to send information to aserver over a TLS connection.his allows the user to conirmor alter the automatically determined context of use.

he quality information returned to the user in case ofconnection login (see the GUI in Figure 14) is as follows:

(i) CLoA, called Identity Assurance in the GUI

(ii) he name of the certiicate holder, called ContactedWeb Site in the GUI

(iii) he name of the certiication authority, called IdentityVeriied By in the GUI

(iv) A link towards the certiicate’s CP/CPS, called Agree-ment of Certiicate Usage in the GUI

Figure 14:Making a decision about a certiicate used for connectionlogin.

(v) he inancial protection ofered to the client by theCA, in case of false certiicate information

Any additional information that might be important to theclient is sent by the TB service. For example, when the userwants to buy a product, the allowed maximum money topay for the purchase is critical information (Figure 16). If the


Figure 15: Determining the context of use for a certiicate.

Figure 16: Making a decision about a certiicate used for providingpayment information.

client wants to purchase a product whose price is higher thanthe protection ofered by the CA in its CP, then he/she losesthe right to be fully covered by inancial protection.hus it isimportant to inform the client about this fact.

When the user makes a decision about a certiicate, werecord this decision and the context of use in a local storeof the web browser along with the CA’s certiicate and CLoAscore. In this way, the extension module will not ask the userto remake a decision about the same context of use for anyweb server certiicate issued by the same CA. However, theextension will ask the user to remake a decision about anyof the CA’s issued certiicates if its quality information haschanged since the last time the decision was made or thecontext of use is diferent.

When the user wants to connect to or register with aserver, the allowed decisions are only “accept” or “reject” thecertiicate. But when the client wants to send informationrelated to a commercial transaction, the decision becomes“refuse/terminate the transaction,” “accept only for thistransaction,” or “accept for all transactions.” We have addedthe middle option allowing a decision to be taken for eachtransaction because the risks associated with a payment varyaccording to the amount of the transaction. We thereforeadapt our user interface to the context of the certiicate’s use.

5.3. Recommendations Collecting. he TB service can auto-matically collect recommendations when its RP clients areusing server certiicates. here are several trust factors thatcan be automatically veriied by the browser extension. In

our prototype, we monitor the proiles of certiicates and theavailability of OCSP servers.

heTB service sends to the browser extensionmodule theproile of certiicates issued by the server’s CA.he extensionchecks the server’s certiicate against the certiicate proile andnotiies the TB service when a violation is detected.

In addition, we verify the requirements imposed on cer-tiicate proiles of “extended validation” certiicates. Accord-ing to the guidelines of the CA/Browser Forum [37] ExtendedValidation (EV) certiicates must meet a number of strictrequirements concerning the subject name, the crypto-graphic algorithms, the key usage ield, and revocation infor-mation. Our TB service deines the XML proile presented inListing 4 that contains all these requirements.

When the browser extension detects any problem relatedto a certiicate’s proile, it asks the user for permission to sendthe certiicate to the TB service, along with the identiiedproblem. In addition, the browser extension also checks theavailability of OCSP servers and reports to the TB servicewhen one is not available.

Before recording any recommendations about a CA, theTB service checks if they are correct or not. If correct, itrecords a positive or negative recommendation about theconcerned trust factor.

6. How Can the 4-Cornered Trust ModelImprove the Security of Web Users?

Superish and the other incidents demonstrate one fact:no one has assumed the responsibility or liability for anyconsequences related to these incidents. From a theoreticalpoint of view, only the CAs are liable to the web users incase of problems. In practice, web users are not able toprosecute CAs because they are not technically able to provethe responsibility of CAs.

Nevertheless, even when the web users are able to provethe responsibility of CAs, they will not be protected com-pletely. Superish and eDellRoot incidents have shown howit is possible to intercept the TLS communications of webusers without necessarily compromising the systems of CAsor asking them to issue false certiicates.

he main reason for this situation is that the web TLSsystem is designed so that web users must depend on amultitude of entities, other than CAs, in order to secure theirtransactions. As an examplewewill compare the intermediateentities in the case of the current validation system with theentities implied in the case of our proposal.

Figure 17(a) shows an example of the entities that areintervening in the current validation system. his representsa web user that uses a Windows OS and uses diferent webbrowsers for suring the web, including Firefox. he irstimportant issue to note is that web users do not have anyassigned tasks to achieve. Everything is executed withouttheir knowledge. From a usability point of view, this issue canbe seen as an advantage. However, from the security point ofview, the current validation system compromises the securityof web users because they depend on unknown entities tosecure their transactions. In Figure 17(a), we recognize that


<?xml version= 1 .0? ><CertProile>

<! Verisign CA id of EV Certiicate ––><CAId value=” 3 C : 48 : 42 : 0D : FF : 58 : 1A : 38 : 86 : BC : FD : 41 : D4 : 8A : 41 : DE” /><Proile Version value=” 5.0” /><Subject type=” ield” component=”O” presence=” Obligatory” /><Subject type=” ield” component=”CN” presence=” Obligatory”value=” dnshostname” valueExclude=”∗” /><Subject type=” ield” component=”C” presence=” Obligatory” /><Subject type=” ield” component=”L” presence=” Obligatory” /><Subject type=” ield” component=”ST” presence=” Obligatory” /><! –– : this ield MUST contain the Registration (or similar)Number assigned to the Subject by the Incorporating or RegistrationAgency in its Jurisdiction of Incorporation or Registration––><Subject component=” Object␣Identiier.∗2␣5␣4␣5.∗” Type=” ield”presence=” Obligatory”/><!–– : he validity period for an EV Certiicate SHALL NOT exceedtwenty seven months.––><Validity type=” ield” value=” 27” />

<DigestSignatureAlgorithm value=” (SHA-1|SHA-256|SHA-384|SHA-512)” /><KeySize component=” Key␣Size” value=” (1024|2048)” />

<!–– : MUST be present and SHOULD NOT be marked critical. he set ofpolicyIdentiiers MUST include the identiier for the CAs extendedvalidation policy.––><Certiicate Policies type=” extension” critical=” Not␣Critical”presence=” Obligatory” value=” oid” /><!–– : SHOULD be present and MUST NOT be marked critical. It MUSTcontain the HTTP URL of the CAs CRL service. his extension MUSTbe present if the certiicate does not specify OCSP responder.––><CRL Distribution Point type=” extension” critical=” Not␣Critical”presence=” Obligatory” value=” httpservicehost” /><!–– : SHOULD be present and MUST NOT be marked critical. SHALLcontain the HTTP URL of the CAs OCSP responder. his extensionMUST be present if the certiicate does not contain acRLDistributionPoint extension.––><Authority Information Access type=” extension” critical=” Not␣Critical”presence=” Obligatory” value=” httpservicehost” /><!–– : the presence of key usage extension is optional. If present,the CA ield MUST be set false.––><Basic Constraints type=” extension” critical=” Not␣Critical”presence=”optional” value=” false” /><!–– : the presence of key usage extension is optional. If present,bit positions for keyCertSign and cRLSign MUST NOT be set––><key Usage type=” extension” critical=” Not␣Critical”presence=” Optional” valueExclude=” (Certiicate␣Signer|CRL␣Signer)” />

</ CertProile>

Listing 4: Example of XML proile for EVS certiicate.

Microsot and Mozilla are the “oicial” TBs because they arethe entities that realize tasks 1 and 2 on behalf of theweb users.We have put the term oicial in quotation marks because theweb users did not delegate oicially Microsot or Mozilla toachieve tasks 1 and 2 on behalf of them. If something goeswrong, Microsot and Mozilla will not refund web users incase of problems. In addition, certiicate distributers do nothave the obligation to help web users to prosecute malevolentCAs in case of loss.

he Superish incident was produced because Lenovohad an access to the list of CAs provided by Microsot.Lenovo injected the certiicate of a self-signed CA and usedits sotware Superish to intercept the TLS communicationsof Lenovo users (i.e., MITM attack). Naturally, users arenot able to detect such kind of problems, because thecurrent validation system is designed so that everythingis executed transparently without the knowledge of webusers.


Manage trust in CAs (calculate CLoA)

Make decision about acertiicate

Ask for CLoA

Conigure URL of TB service in the webbrowser

Forward the CA certiicate to the TB client

Manage decision databaseWeb browsers

TB client

TB

Web user


Contract

bas

ed r

elat

ion

?

Versus

Manage CA trust lists

Make decision about acertiicate

Web browsers (category 1)

(category 2)

Web User

g y

Illegitimate TB3


rela

tio

ns

g

(category 3)

?

Unconscious

dep

end

ence

“O�cial” TB1

“O�cial” TB2

(a) (b)

Figure 17: A comparison between the current validation system and the 4-cornered validation system.

he MITM attacks would not be possible if the integrityof the trust list is guaranteed, that is, ensuring that theOS/Browser editors and web users are the only authorizedentities to modify the trust lists. Unfortunately, this is notenough because web users have to use web browsers to com-plete the validation process. Web users may use known webbrowsers such as Google Chrome and Firefox, but they mayuse also unknown ones for completing the validation process.Georgiev et al. [38] demonstrate that SSL certiicate validationis completely broken in many security-critical applicationsand libraries.hemain reason is that developers tend to badlyconigure the APIs of diferent SSL implementations (suchas JSSE, OpenSSL, and GnuTLS) and data-transport libraries(such as cURL).

Finally, from the usability point of view, the currentvalidation system confuses the web users. In the currentvalidation system, the roles that the intermediate entitiesshould play are not clearly deined. Any intermediate entityhas the right to execute one or more of the obligations ofweb users. For example, Firefox has selected to achieve thefour tasks whereas Google Chrome achieves only tasks 3(partially) and 4. If one web user uses Google Chrome ontwo diferent platforms (e.g., Windows and Linux) (s)he mayget diferent validation results for the same website becausethe trust list of Windows is not the same as Linux. On theother side, if one web user uses Firefox and Google Chromeon the same platform (e.g., Windows) (s)he may get also twodiferent validation results for the same website because thetrust list of Mozilla is not the same as Windows.

he 4-cornered trust model solves the aforementionedproblems by creating a physical relation between the RP andthe TB, who is a technical and legal expert in the domainof PKI. RPs (web users) need only one certiicate, which isthe public key certiicate of the TB. Instead thus of having toobserve the integrity of ininite trust lists, RPs need only toobserve the integrity of one public key certiicate, regardless

of the nature and number of platforms and applications usedby them.

With the 4-cornered trust model, whenever a user getsa new platform, (s)he should link their platform to thevalidation service proposed by the TB with whom the userhas a contract. It should be possible to choose from a setof available TBs. Coniguring the TB consists only in settingthe URL and the certiicate of the TB service. Any sotwareinstalled on the platform of the user must use the selectedvalidation service. he OSs have to remove the ability ofsotware to realize validation services, especially when a userselects a TB.

With 4-cornered validation system, the web browsers arecompletely neutralized. he only task that they should makeis to forward the certiicate of the website to the TB client.hus, if the web user has chosen an unknown web browserto surf the web, this will not afect the security of his TLStransactions (Figure 17(b)).

In real scenarios, the TB might be misconigured or haspoor sotware. his will not cause problems for the webusers because the web user is insured by the TB for anyloss or damage (s)he may sufer. herefore, the user doesnot lose out if the TB makes a mistake for any reason. hisis not the case for a misconigured CA trust list, wherethe user does lose out. he only way to compromise thesecurity of user’s transactions is to misconigure the TBsetting. his can be easily protected. For example, the X.509V3 certiicate has an extensions section that allows addingadditional information to X.509 certiicate. Consequently, TBmay include a new extension in its certiicate that containsthe URL of its validation service. During each request, theTB client shall compare the requested URL with the onecontained in the certiicate of the TB. he advantage of ourproposal is that each user is linked to only one TB and not tomultiple TBs. It is a fundamental improvement of the PKI’strust model that has been adopted in the newX.509 standard.


In addition, multiple implementations might be proposedby diferent TBs. his is good from a security perspective.If one implementation is used by all TBs, one law in thisimplementation means that all TBs are lawed.

7. Conclusion and Future Works

he original X.509 trust model is only appropriate for theclosed deployment model of PKIs, in which the RPs andsubjects both have predeined relations with the CAs. It is notappropriate for the open deploymentmodel where the RP hasno explicit relationship with any CA.

he existing trust approaches are not adapted to theneeds of RPs to make informed decisions in the PKI opendeployment model. As a result, PKIs remain isolated islandsin the open model. Each PKI seeks to comply only with therequirements of the jurisdictionwhere the premises of its rootCA are located.hus, the RPs have to handle this PKI (lack of)interoperability issue. he various harmonization attemptsat regional and international level have not come up with asolution to the PKI interoperability problem.

PKI trust management is extremely complex; thereforeonly technical and legal experts can perform it. It is notconceivable to delegate this task to the RPs who generallyare “normal” people. hus, X.509 has deined a new entityin its upcoming trust model, called the Trust Broker (TB),who is a technical and juridical expert. his new approach totrust management is applicable to both the closed and opendeployment models of PKI. We have deined six criteria fortrust evaluation that this approach should follow.

Contrary to the 3-cornered trust model, the applicabilityof the 4-cornered model does not depend on the goodpractices of the CAs and their certiicate holders. he TBvaries its scores about the CAs, according to their com-mitments to their policies and to their commitments forensuring that their certiicate holders remain responsible ortake appropriate actions in case of malpractice.

Based on these six criteria, we have proposed a trustcalculation model, which identiies and quantiies the qualityof certiicates. his quality information is represented by ascore between 0 and 1 indicating the quality of the certiicate(CLoA). his is computed from the quality of the CA’sprocedures (QoCPS), the ability of the CA to conform toits published procedures, and a conidence level between 0and 1 indicating the reliability of the quality calculation andother information that depends on the context of use of thecertiicate. To calculate the values of CLoA we have proposedthe following:

(i) To transform policy documents (CP/CPS) into aformat that can be understood by computers since thenatural language used to describe the policy of a CAis one of the main obstacles to determining trust in aCA

(ii) Based on RFC 3647, we have structured CP/CPSdocuments as a hierarchical tree composed of nodesand leaves

(iii) To integrate the role of RPs, certiicate holders, andcompetitor TB services to supplement the work ofaudit agencies in evaluating the real practices of CAs

(iv) To calculate the quality of CAs (QoCA) based on theREGRET model, while allowing TBs the lexibility toincorporate their own intellectual property in orderto gain competitive advantage over other TBs

he trust relationship between the RP clients of a TB serviceand the TB is an important issue. We propose that itshould be a contractual relationship that gives warranties andcommitments to the RP clients. he trust that a client musthave in its TB should not be based on the evaluation strategyadopted by the TB. Chadwick and Basden [35] has showedthat even PKI experts cannot reach a consensus about theimportance of a CA’s security parameters. As a consequence,the RP’s trust should be that the contracted TB will make itsbest eforts to protect them, but if something goes wrong, thewarranties of the signed contract will efectively alleviate theproblem.

Finally, we have chosen to implement a prototype systemin the context of theweb to showhow Internet users canmakeinformed decisions about web server certiicates, aided by aTB, without compromising their privacy.

In the short-term, we propose to conduct some usabilityexperiments to measure the advantages that our prototypeofers to end users.

In the long-term, further work must be conducted toenrich the assurance information presented to users. heCLoA information is important but not suicient to give theoverall assurance level for a transaction. he provision ofassurance services requires the intervention of other entitieswhose natures and roles depend on the context of a trans-action between the interested parties. For example, attributeauthorities may be required to assure end users that theservices do possess certain attributes.he role of these entitiescan be extended according to the context of a transaction.We need to extend this work to deal with all elements of thechain of a transaction. Each element, depending on its role,mustmeet certain criteria.hus, instead of providing only theCLoA score, the system could provide a score including thelevel of quality of all elements of the chain.

Competing Interests

he authors declare that there is no conlict of interestsregarding the publication of this paper.

References

[1] Lenovo, “Superish attack,” 2015,https://twitter.com/kennwhite/status/568270748638318593.

[2] Lenovo,Guidelines for removing superish, 2015, https://support.lenovo.com/fr/en/product security/ps500066.

[3] Dell, Dell edellroot, 2015, http://www.dell.com/support/article/us/en/19/SLN300321.

[4] Dell, “Guidelines for removinf the ca of dell,” 2015, http://www.dell.com/support/article/fr/fr/frbsdt1/SLN300321?c=fr&l=fr&s=bsd&cs=frbsdt1.


[5] Z. Ye, S. Smith, and D. Anthony, “Trusted paths for browsers,”ACM Transactions on Information and System Security, vol. 8,no. 2, pp. 153–186, 2005.

[6] J. Marchesini and S. Smith, “Modeling public key infras-tructures in the real world,” in Public Key Infrastructure, D.Chadwick and G. Zhao, Eds., vol. 3545 of Lecture Notes inComputer Science, pp. 118–134, Springer, Berlin, Germany, 2005.

[7] A. Jøsang, I. Glenn Pedersen, and D. Povey, “PKI seeks atrusting relationship,” in Information Security and Privacy: 5thAustralasian Conference, ACISP 2000, Brisbane, Australia, July10–12, 2000. Proceedings, vol. 1841 of Lecture Notes in ComputerScience, pp. 191–205, Springer, Berlin, Germany, 2000.

[8] R. Dhamija, J. D. Tygar, and M. Hearst, “Why phishing works,”in Proceedings of the SIGCHI Conference on Human Factors inComputing Systems (CHI ’06), pp. 581–590, ACM, Montreal,Canada, 2006.

[9] J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, and L.F. Cranor, “Crying wolf: an empirical study of SSL warningefectiveness,” in Proceedings of the 18th Conference on USENIXSecurity Symposium (SSYM ’09), pp. 399–416, USENIX Associ-ation, Montreal, Canada, August 2009.

[10] R. Dhamija and L. Dusseault, “he seven laws of identitymanagement: usability and security challenges,” IEEE Securityand Privacy, vol. 6, no. 2, pp. 24–29, 2008.

[11] R. Biddle, P. C. Van Oorschot, A. S. Patrick, J. Sobey, andT. Whalen, “Browser interfaces and extended validation SSLcertiicates: an empirical study,” in Proceedings of the ACMWorkshop on Cloud Computing Security (CCSW ’09), pp. 19–30,New York, NY, USA, November 2009.

[12] A. S. Wazan, R. Laborde, D. W. Chadwick, F. Barrere, and A.Benzekri, “Which web browsers process ssl certiicates in astandardized way?” in Emerging Challenges for Security, Privacyand Trust, D. Gritzalis and J. Lopez, Eds., vol. 297 of IFIPAdvances in Information and Communication Technology, pp.432–442, Springer, Berlin, Germany, 2009.

[13] N. Luhmann, “Familiarity, conidence, trust: problems andalternatives,” in Trust: Making and Breaking Cooperative Rela-tions, D. Gambetta, Ed., chapter 6, pp. 94–107, Department ofSociology, University of Oxford, 2000.

[14] Google, Certiicate transparency project, 2015, https://www.certiicate-transparency.org.

[15] L. Chuat, P. Szalachowski, A. Perrig, B. Laurie, and E. Messeri,“Eicient gossip protocols for verifying the consistency ofcertiicate logs,” in Proceedings of the 3rd IEEE InternationalConference on Communications and Network Security (CNS ’15),pp. 415–423, IEEE, Florence, Italy, September 2015.

[16] Electronic Frontier Foundation, Sovereign keys project, 2015,https://www.ef.org/fr/sovereign-keys.

[17] R. Sleevi, C. Evans, C. Palmer, and Google Inc, “Public keypinning extension for HTTP,” Tech. Rep. Rfc7469, 2015, https://tools.ietf.org/html/rfc7469.

[18] A. S.Wazan, R. Laborde, F. Barrere, andA. Benzekri, “heX.509trust model needs a technical and legal expert,” in Proceedingsof the IEEE International Conference on Communications (ICC’12), Ottawa, Canada, June 2012.

[19] A. S. Wazan, R. Laborde, F. Barrere, A. Benzekri, and D. W.Chadwick, “PKI interoperability: still an issue? A solution in theX.509 realm,” in Information Assurance and Security Educationand Training, pp. 68–82, Springer, Berlin, Germany, 2013.

[20] ITU,Current Status of the Eighth Edition of x.509 Standard, 2016,http://www.itu.int/itu-t/aap/AAPRecDetails.aspx?AAPSeqNo=5686.

[21] W. A. Samer, L. Romain, B. Francois, and B. AbdelMalek,“A formal model of trust for calculating the quality of X.509certiicate,” Security and Communication Networks, vol. 4, no.6, pp. 651–665, 2011.

[22] W. T. Polk and N. E. Hastings, “Bridge certiication authorities:connecting b2b public key infrastructures,” 2000, http://csrc.nist.gov/groups/ST/crypto apps infra/documents/B2B-article.pdf.

[23] Gatekeeper PKI Framework, “Cross recognition policy,” 2009,https://www.finance.gov.au/sites/default/iles/Cross RecognitionPolicy.pdf.

[24] Mozilla, “Mozilla CA certiicate inclusion policy,” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/.

[25] Microsot, Microsot root certiicate program, 2009, http://technet.microsot.com/en-us/library/cc751157.aspx.

[26] S. P. Marsh, Formalising trust as a computational concept [Ph.D.thesis], Department of Computer Science and Mathematics,University of Stirling, 1994.

[27] M. Deutsch, Cooperation and Trust: Some heoretical Notes,Nebraska University Press, 1962.

[28] N. Luhmann, Trust and Power, John Wiley & Sons, 1979.

[29] B. Barber, Logic and Limits of Trust, Rutgers University, 1983.

[30] A. Baier, “Trust and antitrust,” Ethics, vol. 96, no. 2, pp. 231–260,1986.

[31] D. Gambetta, “Can we trust trust?” in Trust: Making andBreaking Cooperative Relations, D. Gambetta, Ed., pp. 213–237,Blackwell, 1988.

[32] A. Jøsang, “he right type of trust for distributed systems,”in Proceedings of the the workshop on new security paradigms(NSPW ’96), pp. 119–131, Lake Arrowhead, Calif, USA, Septem-ber 1996.

[33] A. S. Wazan, R. Laborde, F. Barrere, and A. Benzekri, “Validat-ing X.509 certiicates based on their quality,” in Proceedings ofthe 9th International Conference for Young Computer Scientists(ICYCS ’08), pp. 2055–2060, IEEE, Hunan, China, November2008.

[34] J. Sabater and C. Sierra, “Regret: reputation in gregarioussocieties,” in Proceedings of the 5th International Conferenceon Autonomous Agents (AGENTS ’01), pp. 194–195, Montreal,Canada, June 2001.

[35] D. W. Chadwick and A. Basden, “Evaluating trust in a publickey certiication authority,” Computers & Security, vol. 20, no. 7,pp. 592–611, 2001.

[36] J. Dumortier, S. Kelm, H. Nilsson, G. Skouma, and P. vanEecke, “Study for the European Commission: the legal andmarket aspects of electronic signatures,” Tech. Rep., EuropeanCommission, 2003.

[37] CABrowser Forum, “Guidelines for the issuance and man-agement of extended validation certiicates v1.5.2,” https://cabforum.org/wp-content/uploads/EV-V1 5 2Libre.pdf.

[38] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V.Shmatikov, “he most dangerous code in the world: validatingSSL certiicates in non-browser sotware,” in Proceedings of theACM Conference on Computer and Communications Security(CCS ’12), pp. 38–49, ACM, Raleigh, Calif, USA, October 2012.

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery

Hindawi Publishing Corporation

http://www.hindawi.com Volume 2014Hindawi Publishing Corporation

http://www.hindawi.com

Journal ofEngineeringVolume 2014

Submit your manuscripts at

https://www.hindawi.com

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances in

OptoElectronics

Hindawi Publishing Corporation http://www.hindawi.com

Volume 2014

The Scientiic World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014

SensorsJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks
