an advanced certificate validation service and architecture based on xkms

SOFTWARE – PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2011; 41:209–236Published online 24 August 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.996

An advanced certificate validation service and architecture basedon XKMS‡

Antonio Ruiz-Martınez∗,†, Daniel Sanchez-Martınez, C. Inmaculada Marın-Lopez,Manuel Gil-Perez and Antonio F. Gomez-Skarmeta

Department of Information and Communications Engineering, University of Murcia, 30100 Murcia, Spain

SUMMARY

The appearance of some laws that make the electronic signature (e-signature) legally equivalent to the hand-written signature (under some circumstances) has favoured its use in different fields, such as e-commerceand e-government. In these fields, the e-signatures associated to some documents have to remain validover long periods of time. For these kinds of e-signatures, Advanced Electronic Signature (AdES) formshave appeared. These forms specify the information to include along with the e-signature so that it remainsvalid for a long time after its creation. Basically, this information comprises signers’ certificates, a set ofcertificates up to a trust anchor, certificate validation responses, etc. These data can be gathered by usingdifferent Public Key Infrastructure-compliant protocols. However, the support of different protocols iscomplex for clients. XML Key Management Specification (XKMS) appeared with the aim of simplifyingthe certificate management, but it only supports a simple validation mechanism that does not provide theinformation needed for long-term validation. As a solution to this problem, we have extended XKMSby defining an advanced certificate validation service to support the obtaining of validation data neededfor different scenarios, such as the building of AdES forms or validation data registries. This extensionalso defines the different components needed to support this kind of a service. Furthermore, the definedservice has been implemented and incorporated into an e-government infrastructure. Copyright q 2010John Wiley & Sons, Ltd.

Received 3 September 2009; Revised 14 June 2010; Accepted 16 June 2010

KEY WORDS: certificate validation; Advanced Electronic Signatures; service-oriented architecture;XKMS; validation data

1. INTRODUCTION

The use of electronic signatures (e-signature) can guarantee non-repudiation in electronic commerce(e-commerce), business (e-business) and government (e-government) transactions. Moreover, somelaws, such as the directive 1999/93/EC of the European Parliament and Council [1] and theUNCITRAL Model Law [2] have appeared to guarantee that if the e-signature is developed insome circumstances, it can be considered legally equivalent to the handwritten signature. Thisacknowledgment has favoured an increase in the number of e-business/commerce/governmenttransactions. Thus, paper documents are now being replaced by electronic documents.

Some of the signed documents generated in the mentioned transactions have to be stored overlong periods of time due to legal requirements [3, 4]. Some examples of these documents are

∗Correspondence to: Antonio Ruiz-Martınez, Department of Information and Communications Engineering, Universityof Murcia, 30100 Murcia, Spain.

†E-mail: [email protected]‡This article is an extended and revised version of ‘ACVS: an Advanced Certificate Validation Service in Service-Oriented Architectures’. Published in Proceedings of the Third International Conference on Internet and WebApplications and Services (ICIW’08). pp. 297–302, Athens (Greece), 2008.

Copyright q 2010 John Wiley & Sons, Ltd.

210 A. RUIZ-MARTINEZ ET AL.

e-invoices, title-deeds, etc. In order to be able to validate a signed document over these longperiods, we need to include some of the validation data that were used to validate the signaturewhen it was stored [5]. These validation data can be signers’ certificates, a set of certificates fromsigner’s certificate up to a trust anchor, Online Certificate Status Protocol (OCSP) [6] responses,Certificate Revocation Lists (CRLs), Authority Revocation Lists (ARLs) [7], etc. For this purpose,some signature forms, such as CMS Advanced Electronic Signature (CAdES) [8] and XMLDSigAdvanced Electronic Signature (XAdES) [9], have been proposed. The inclusion of these validationdata is performed at different moments in time. Some data can be included at the time of creatingthe signature, others can be included just before creating the e-signature and validating it. Finally,some of them can be included some time after the validation (if the data are not available, e.g. CRLs)or periodically, to avoid cryptographic and information weaknesses (timestamps). Another possiblesolution, which is different from Advanced Electronic Signature (AdES) forms (CAdES/XAdES),is that the validation data, instead of being included in the signature, are stored and made availablein a validation authority or in a validation data registry (an independent entity that could use avalidation authority to obtain validation data and store them) [10]. These registries may be neededin addition to AdES forms, since there are some forms, such as AdES-C, that do not include thevalidation data, but only references to them.

For validation of an advanced e-signature, we need to perform two main processes: pathconstruction/discovery up to a trust anchor and path validation [11, 12]. Path construction can becarried out by means of different protocols, such as Lightweight Directory Access Protocol (LDAP)[13] or Server-based Certificate Validation Protocol (SCVP) [14]. To carry out path validation,there exist several mechanisms, such as CRLs and OCSP/SCVP responses. An analysis of thedifferent mechanisms can be found in [15]. To perform this process we have to support differentPublic Key Infrastructure (PKI) protocols with complex syntax and semantics. Furthermore, thisprocess can suppose an important overhead for some thin clients, such as Personal Digital Assis-tants (PDAs) or mobile devices, which have limited resources. As a solution to these problems,the XML Key Management Specification (XKMS) [16] was proposed.

XKMS is based on Service-Oriented Architectures (SOA) [17] and defines several protocolsfor registering, distributing and obtaining information about public keys. Its definition as a Webservice is due to the fact that it helps to create interoperable services [18]. This also facilitates itsintegration with many services that are offered in e-commerce and e-government platforms, whichare migrating their services to SOA architectures based on Web services.

XKMS, for the purpose of validating a certificate, defines a Validate service. Its main drawbackis that it only returns whether the certificate is valid or not without any additional informationabout the validation protocol or the validation data used. Therefore, the information providedby this service is not enough to recover the information needed to create long-term signaturesaccording to AdES forms. The only element we can recover is the signer’s certificate, which, inturn, can also be recovered with the Locate service. However, we need to recover the validationdata used.

The aim of this paper is to present a solution to the problem of managing validation data fromthe XKMS service to be used to create long-term signatures or to store them in a validation dataregistry. For this reason, we propose a system architecture with different elements that shouldparticipate in order to cope with long-term signature (creation and validation) and the storage ofvalidation data. This solution can be useful as a basis for other standards related to Web services,such as SAML or XACML, as well as for some scenarios, such as e-government platforms,e-invoices, registered electronic mail (REM), mobile platforms and grid infrastructures.

The main contribution to this architecture is the extension of XKMS Validate and Locateservices to customize certificate validation and return the validation data needed. Along with theseextensions we also define the modules that should be included in the service to support them. Thisdesign is modular and supports the use of different PKI solutions as well as the extension with newprotocols and new PKIs. Additionally, we have defined an authentication mode based on Payword[19] to support lightweight authentication in XKMS when there is a long-term relationship betweenthe client and the server.

Copyright q 2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2011; 41:209–236DOI: 10.1002/spe

CERTIFICATE VALIDATION SERVICE AND ARCHITECTURE 211

Our proposal facilitates both the obtaining of these validation data and the migration of currentXKMS services to this new specification, named XKMS-ACVS (Advanced Certificate ValidationService). These extensions and architecture have been implemented and are part of the e-governmentplatform of the University of Murcia. Later, we present both the platform and the scenario wherethis service is being used.

This paper is structured as follows: Section 2 introduces the background information related tothe creation and validation of advanced e-signatures. Section 3 presents the components that are partof the advanced certificate validation architecture whose key component is the validation authoritythat offers the advanced validation service. Its specification is described in-depth in Section 4.Section 5 presents an SOA-based e-government infrastructure that incorporates our proposal.Section 6 analyses and discusses the related work. Finally, Section 7 presents the conclusions andfuture work.

2. CREATION AND VALIDATION OF ADVANCED ELECTRONIC SIGNATURES

This section introduces different issues related to the creation and validation of e-signatures thatremain valid over long periods of time and some scenarios of use. Our aim is to establish thecontext and explain the problems that arise when dealing with advanced e-signatures.

Currently, in e-government, e-business and e-commerce systems, the use of the e-signature isfundamental for supporting different kinds of transactions. In general, these transactions have somedocuments to be signed. The e-signature of such documents is expressed according to formats,such as PKCS#7 [20]/CMS [21] or XMLDSig [22]. Some of these e-signatures have to remainvalid over long periods of time. For this purpose, AdES forms have been proposed.

AdES forms (CAdES [8] and XAdES [9]) are based on the incorporation of some additionalinformation in the PKCS#7/CMS and XMLDSig formats. These AdES forms can be createdby both the signer and the verifier. Basically, the elements included (details in Section 2.2) arevalidation data: the certificates used to validate the e-signature and the certificate status information(CRLs, OCSP responses, etc.) to prove that the certificates were valid at the moment the signaturewas created. Furthermore, some timestamps are included to prove the existence of these data at amoment in time.

2.1. Use scenarios of advanced electronic signatures

These advanced forms are required for some scenarios, such as the exchange of electronic invoices(e-invoices), a fundamental process in e-business/government transactions. In these e-invoicesauthenticity and integrity are preserved thanks to e-signature. Without the validation of thee-signature at issuance time, the validity of the e-invoice cannot be guaranteed. However, in manycases, this is not enough. Owing to legal requirements, the receiver of the e-invoice has to store itfor some time period. During this period the e-invoice Directive [3] establishes that the authenticityof the origin, the integrity and the readability must be preserved.

In order to support long-term signatures, the signature of the e-invoice has to be according tosome AdES form. The specific form depends on the technical specification indicated by a particulargovernment for its country. Some governments that are working on this kind of signature are theGerman and Spanish Governments, e.g. Spanish government requires XAdES-X-L.

Another scenario of application is the e-mail. Currently, the e-mail is one of the most importanttools in e-business and e-government. However, e-mail systems do not provide enough securityservices to be trusted. In response to this need, REM services have been proposed [23]. In thesekinds of systems, the goal is to provide origin authentication and proof of delivery and for thispurpose, AdES forms are used.

As a final scenario, it is worth mentioning that in some countries, such as Spain, the exchangeof e-dossiers between different public agencies is regulated. These dossiers are signed according



to the XAdES signature to guarantee the origin, integrity and authentication of the informationexchanged.

Owing to these needs and for the various documents where AdES forms can be used, someprofiles have been defined [24, 25]. These profiles establish the specific AdES form to use and theelements to include in a particular type of document.

Next, we explain the various AdES forms, the information needed to create them, how to obtainthis information, etc.

2.2. Electronic signature and AdES forms

Currently, the standard formats available for e-signatures are PKCS#7/CMS and XMLDSig. Theformer is based on the ASN.1 data model, whereas the latter is based on the XML data model. Bothformats basically allow expressing the same information: data to be signed (optional), algorithmsused, certificate or a reference to the certificate; and the signature value itself.

In the e-signature validation process we not only need to verify whether the document is correctlysigned, but also whether the certificate used was valid at the moment the signature was generatedor at the moment the validation is being performed. Specifically, the validation of an e-signatureinvolves:

• The verification of the e-signature value.• The validation of the data associated to the e-signature (set of certificates up to a trust anchor,certificate status of each certificate in the complete certification path). These certificates mustbe valid at the moment the signature was performed. Thus, we need to recover the differentcertificates up to a trust anchor and perform the validation of the status of each certificatein the path (details on this process in Section 2.3). Neither PKCS#7/CMS nor XMLDSigdefines how to incorporate this information.

• The verification of the existence of the signature at a specific moment in time. For thispurpose, timestamps are used.

When e-signature validation is performed at a time close to the moment when the e-signaturewas produced, the information previously mentioned might be recovered easily. However, if thise-signature has to be stored to remain valid over long periods, we may take problems whenverifying this signature much later: the certificates set could be unavailable, some keys couldbe compromised—signer’s key, Certification Authority (CA)’s key, etc.—the algorithms used togenerate signatures and/or certificates could become weak, etc.

To overcome these possible problems, the use of the AdES forms is proposed [3]. Then,we describe the different forms defined in AdES specifications and the different informationincorporated in each of them.

2.2.1. AdES. AdES specifications [8, 9] were proposed with the aim of defining several advancede-signatures that remain valid over long periods of time and that are compliant with the EuropeanDirective of e-signature [1].

Next, we briefly mention the different forms and the information included in them. We go fromthe simplest to the most complex. Each form includes the information defined by the previous one.For this reason, in each form we only describe the new information included. Each form involvesinserting a set of signed and/or unsigned properties over the basic signature formats (CMS orXMLDSig). These forms are:

• Basic electronic signature (AdES-BES): It includes the signing certificate (or a digest of it)as a signed property. It can also include other signed and/or unsigned properties, such assigning time, data object format and signer role.

• Explicit policy-based electronic signature (AdES-EPES): It is built from CMS/XMLDSig orfrom AdES-BES forms. It includes a signed property to indicate a reference to the signaturepolicy used.



• Electronic signature with time (AdES-T): It adds a timestamp of the signature as an unsignedproperty.

• Electronic signature with complete validation references (AdES-C): It adds the references(certificate hash, issuer and serial) to all the certificates used to validate the signature. It alsoincludes the references to all revocation data used in the signer and the CA certificatesvalidation.

• Extended signatures with time indication forms (AdES-X): It adds one or more timestamps toprotect the information inserted previously in AdES-C.

• Extended long signatures with time (AdES-X-L): It adds the set of certificates (not the refer-ences) to all the certificates used to validate the signature and all the revocation data neededto validate the signer and CA certificates.

• Archival electronic signatures (AdES-A): It adds a timestamp to protect the information insertedin AdES-X-L. At a certain time, a new timestamp can be inserted to protect the signaturefrom algorithms and cryptographic material weaknesses.

2.3. Certification path processing

In this section we describe the process to be carried out to validate a certificate. We also mentionthe main existing mechanisms used for this purpose and for recovering the validation data needed.

For validating a certificate, the following steps must be executed:

1. Building one or more candidate certification paths between the certificate to validate andone established trust anchor. This is called path construction/ discovery. This task can becarried out by a client performing a recursive search through multiple directory protocolssuch as Directory Access Protocol (DAP), LDAP, HyperText Transfer Protocol (HTTP) andFile Transfer Protocol (FTP). The client can also delegate this task to a server. The setof requirements that a delegated protocol should satisfy are specified in Delegated PathDiscovery (DPD) [26]. Some protocols that satisfy those requirements are SCVP and ECPV(Efficient Certificate Path Validation). This latter mechanism is analysed in more detail inthe following section because we have considered some of its components for our validationauthority architecture.

2. Checking that each certificate in the certification path is valid. This implies checking thatits structure is correct and satisfies certain constraints (e.g. path length constraints, nameconstraints, etc.), that it is within its established validity period, it has not been revoked, andthe issuer’s signature over the certificate is valid. This step is called path validation. Thisprocess can be performed directly by a client with the help of several mechanisms, such asCRLs (and ARLs) and OCSP responses, or even through an XKMS system. This task canalso be delegated. The requirements that should satisfy a delegated server are described inDelegated Path Validation (DPV) [26]. Both SCVP and XKMS satisfy them.

The process consisting of these two steps is referred to as certification path processing[11, 12, 27]. In order to facilitate this complex process, XKMS has been introduced. We analyseit in Section 2.3.2 as it is an essential part of our proposal.

2.3.1. ECPV. ECPV scheme [28] is designed only for PKIs based on X.509 certificates, in whichclients can delegate the certification path processing. This scheme is based on one or more Certifi-cate Path Validation Authorities (CPVAs). These authorities build and analyse candidate certifica-tion paths according to the trust anchors in which a relying party trusts and the policies/constraintsestablished by it. These certification paths are called Certificate Path Validation Trees (CPVTs)which can be used later by the relying parties to carry out a local validation in an offline manner.

The ECPV architecture is composed of the following components:

• Subject module: Authorized clients that can request to the relying parties the validation oftheir user’s certificates.



• Relying party module: It receives the requests from the clients and forwards, on their behalf,the validation requests to the corresponding CPVA. This last component provides all therequired information for the building and validation process (i.e. certificate to be validated,trust anchors and validation policies).

• CPVA module: The CPVA performs the process of path discovery (building the CPVTs) andvalidation. This module is divided into the harvester and analyzer submodules, which arein charge of gathering the required information from the different PKIs (e.g. CA certifi-cates, CRLs, OCSP responses) and building CPVTs based on relying parties’ requirements,respectively.

• CA module: This module represents a specific underlying local PKI with its own internalcomponents (the CA, its RA, the public repository and OCSP responder).

ECPV is a good distributed scheme, operating either as an autonomous entity or in a federatedmode, to validate X.509-based certification paths, although it presents some disadvantages thatshould be taken into account. First, ECPV can only manage X.509 digital certificates. This entailsa negative consideration since other formats have to be supported (SPKI, PGP and attributescertificates). Second, this scheme does not consider that future non-repudiation checking operationscould be carried out. Thus, although validation data might be stored, they are not used later.Finally, ECPV does not provide any mechanism by means of which clients can select the validationprotocol needed for validating certificates requested by them.

2.3.2. XKMS. XKMS [16] is a W3C recommendation not tied to specific protocols defined bythe underlying PKIs, thus making clients totally independent of the complex process of thoseprotocols. XKMS is also part of the WS-* security related to protocols and can constitute the basisof other proposals, such as WS-Authorization, WS-Federation and WS-Policy.

XKMS is a Web Service which involves exchanging trust information between clients andthe underlying PKIs. Clients are able to use, in a simple way, different PKI solutions (based ondifferent specifications, such as PKIX, SPKI or PGP) with many different protocols which thesePKIs could be using.

This means that clients can outsource the processing of key management to a dedicated server toreduce substantially the complexity, high processing and memory requirements of the underlyingprotocols. Thereby, XKMS is an attractive solution when small devices are being used by clients.Furthermore, XKMS uses XML as an exchange format to express the services for certificatemanagement, thus being able to use a variety of tools for processing its XML-based messages.These tools are also used to process the specific formats associated with the secure exchange ofinformation in XML used in XKMS, such as XMLDsig and XML Encryption.

Regarding the scope of this work, one of the main components defined in XKMS is the XMLKey Information Service Specification (X-KISS), which defines two services. The first calledLocate, resolves <ds :KeyIn f o> elements for gathering the corresponding public key certificatesin order to validate or decrypt secure messages.

The second service, called Validate, performs the same function as Locate and, in addition,clients may obtain an assertion specifying the status of a given public key, which will depend ona single set of validation criteria. However, Validate entails some disadvantages that should betreated. On the one hand, it is not able to return any validation data, such as a set of certificates(or references to them) up to a trust anchor, CRLs and OCSP responses. On the other hand, clientsare not able to specify which validation protocol should be used by the service to validate thecertificates requested by them. Thus, the validation results could vary depending on the protocolchosen by the corresponding PKI. For example, suppose that Validate uses a CRL mechanism tocheck the revocation status of the certificates. When a certificate becomes revoked it is possiblethat it could not be considered as revoked until the new CRL is issued by its corresponding CA.By using other validation mechanisms, such as OCSP, new revoked certificates are instantly deemednot valid.

XKMS can offer the service used to access a validation authority. This authority, in order toperform the certification path processing, needs a set of modules. In the following section, we



analyse SAVaCert, a proposal that covers this open issue. This proposal is analysed for the differentcomponents in it that define our validation authority architecture.

2.3.3. SAVaCert. SAVaCert [29] is a Secure client-server Architecture for the Validation of X.509Certificates. Clients can delegate only path discovery for performing an offline validation locally, orboth path discovery and validation together. This architecture comprises several modules, definedin a suitable level of abstraction, to allow developers to choose the most appropriate protocols andvalidation mechanisms (both on the client and server side).

On the clients’ side, there exists the possibility of configuring some parameters to control thebehaviour of the validation process. Between those parameters we can emphasize:

• Indication of what information used during path processing must be returned.• Set of acceptable certificate policies for the CAs in a certification path.• Other specific parameters for the selected protocol between client and server.

Regarding Certificate Validation Server defined by SAVaCert, the main modules involved in thevalidation process are the following:

• Validation module: This is the module in charge of building and validating the certificationpaths for a given certificate. As it is based neither on a particular cryptographic library noron the certificate management library, developers can freely choose the underlying protocolsand mechanisms.

• Storage module: It is appointed to store and/or retrieve certificates, revocation data andpolicies.

This architecture is not complete enough since it does not consider several aspects essential foran ACVS; namely, an element that carries out authorization operations to control accesses to theservice, support for asynchronous operations, management of profiles (not only service profilesbut also user ones) and management of service policies.

3. ADVANCED CERTIFICATE VALIDATION ARCHITECTURE

In this paper we propose an ACVS to support the building of validation authorities that allowthe obtaining of the validation data needed for the building of AdES forms and validation dataregistries. For this purpose, we present the following contributions:

• The extension of the XKMS Validate and Locate services as well as an improvement of theauthentication mode of XKMS. The aim of our extensions is to facilitate XKMS to provide thevalidation data used in the certification path processing of a certificate according to the clientneeds. We have defined it as an extension to maintain backward compatibility with the currentXKMS systems and to facilitate the process of migration to the new service proposed. Thus,the client that already uses XKMS need not develop the business logic to perform certificationpath processing and support different PKI protocols. We also facilitate the adoption of ourproposal for those that have to support this functionality when developing AdES forms or avalidation authority. Even for those who already support the business logic of certification pathprocessing and several protocols, our proposal simplifies their applications, their maintenanceand update, since the incorporation of new protocols and algorithms would be provided by theXKMS with our extensions instead of having to include them in their application. We havenamed this extended specification of XKMS XKMS Advanced Certificate Validation Service,hereafter XKMS-ACVS. To a server that supports this specification we refer as XKMS-ACVSserver.

• The definition of the different modules that should have a validation authority that supportsan advanced validation service based on XKMS-ACVS.



Figure 1. Architecture system.

Before providing a detailed description of these elements, in this section we present the differentelements that are part of the architecture where our service is integrated. In Figure 1 we showthe elements that compose the system and the relationships drawn between them. The elementsare: clients, the XKMS server that supports our extension (XKMS-ACVS), PKIs and PrivilegeManagement Infrastructures (PMIs), which issue the certificates to be validated and offer differentvalidation mechanisms for this purpose. The elements communicate with each other by usingdifferent protocols, such as XKMS, LDAP and OCSP. The components are described in thefollowing sections.

3.1. PKI and PMI

PKIs (in Figure 1) are responsible for managing the complete life cycle of identity certificates.One of the most important functions is to provide information about the status of a certificate bymeans of different mechanisms/protocols, such as CRLs, delta CRLs, OCSP and SCVP. We needto simplify how end users access those mechanisms.

Likewise, PMIs are in charge of the management of attribute certificates. In general, thesecertificates are issued for short periods of time and, therefore, it is not necessary to check theirvalidation status. However, sometimes attribute certificates are issued for long periods of time,thus requiring the provision of a mechanism to check them.

These infrastructures are mainly based on the use of certificates according to the X.509-based format. However, there are other proposals of certificate format, such as SPKI or PGPcertificates.

We consider attribute, PGP and SPKI certificates since we want to provide a generic solutionand although not used in AdES forms, in other scenarios they could be used. In fact, in XKMSthe validation of these kinds of certificates is already supported.

3.2. Clients

In this architecture, shown in Figure 1, clients contact the Validation Authority to check the statusof a certificate (or some of them) at a given moment in time. There are two kinds of clients: thinor lightweight clients and thick or powerful clients.

Thin or lightweight clients are those that have limited networking and computational resources(reduced memory, bandwidth and speed processor). In this category could be introduced clientswith mobile devices, such as mobile phones and PDAs. These clients only need to know whethera certificate is valid at a given time (when the request is being performed or at a previousmoment). Additionally, they need to know whether the certificate satisfies a specific policy atthe moment it is being verified. Thus, in their requests the clients send the minimum possible



information (e.g. instead of the full certificate they could send a reference to the certificate).Usually, the answer to their requests is only valid or not valid. When these clients need thevalidation data, they request the server to store them on their behalf. Later they recover themeither by themselves or from a more powerful client if they do not have enough computationalresources.

Thick or powerful clients are those that send their requests from devices, such as a personalcomputer, a laptop or a server. In general, these clients contact the validation authority becausethey need to recover the different validation data used to validate a certificate (e.g. for building anAdES form in some of the scenarios mentioned in Section 2). However, at the same time, theywant to avoid the complexity of supporting different protocols for the tasks of certification pathprocessing.

The clients request the certificate validation or localization to the validation authority usingthe XKMS protocol (see Figure 1). They use the Validate service for certificate validation andLocate for obtaining certificates or (public) keys. Moreover, if they also want the validation data(in the Validate service) or additional information about certificates, they may use XKMS with theextensions (XKMS-ACVS).

3.3. Validation authority

The Validation Authority is responsible for receiving certification validation requests fromthe clients and answering them. In the proposed architecture, this entity is different from aPKI or a PMI, it is a trusted third party for the clients. Although established as a separateentity, this certificate validation task could also be carried out by the corresponding PKIor PMI.

The validation authority implements an XKMS-ACVS server with the services associated withXKMS as well as the extensions mentioned in Figure 1 and explained in detail in Section 4.In Figure 2, we depict the different modules that are part of the XKMS-ACVS server for providingan advanced validation service. This architecture is based on SAVaCert and on some ideas fromECPV, such as the Scheduler and Harvester modules, thus improving the certification path vali-dation. Furthermore, we have defined some new modules to satisfy the requirements needed forthis advanced validation service. These modules are described next.

XKMS-ACVS Server

XKMS Request/Response Processor

XKMS SERVICES

LOCATE VALIDATE REGISTER

REISSUE REVOKE RECOVER

STATUS PENDING COMPOUND

XKMS ACCESS-RELATED SERVICES

AUTHORIZATION AUTHENTICATION

ACCOUNTING

SUPPORT MODULES

Service Profiles

User’s Profiles

RepositoriesModule

ValidationData Store

Policy Management

Log

Harvester Scheduler

Certificate, Storage and Crypto SupportRepositories

OCSPCLIENT

SCVPCLIENT

XKMSCLIENT

XKMS-ACVSCLIENT

LDAPCLIENT

PKI OCSPCLIENT

MAPPINGPKI OCSP

CLIENTPKI LDAP

CLIENT

Figure 2. XKMS-ACVS service modules.



3.3.1. Certificate validation service modules. Conceptually, there are four main groups of modules(marked in Figure 2):

• XKMS Request/Response processor: This module is responsible for receiving differentrequests from the clients and providing an answer. It uses XKMS access-related services tocontrol the users’ access to the service. When the request is processed, it is redirected to thespecific XKMS service in charge of carrying out the task requested. To support the differenttasks to perform, this module could make use of Support Modules.

• XKMS access-related services: There are several modules in charge of performing differentactions related to the access of the clients to the system, such as authentication, authorizationand accounting. Thus, the service could determine whether a client is able to use the serviceor not, that the request comes from a valid client, and even take into account the differentaccesses made from the different clients in order to subsequently charge for their services(in the event of some services being charged for). The integration of these security servicesin XKMS could be based on SAML and XACML as proposed in [30].

• XKMS services: These modules are responsible for supporting the different functionalitiesprovided by the different services offered by XKMS, such as Locate, Validate and Register.The behaviour of these services is described in the XKMS specification [16]. They are alsoresponsible for managing the different extensions proposed for each service.

• Support modules: The different modules in charge of supporting the different functionalitiesof XKMS-ACVS to carry out its tasks.

Next, we provide a clarification on the different modules that are part of the Support Modulesgroup because they constitute the core modules needed to support the different functionalities ofthe modules of the XKMS-ACVS services group. These modules are:

• Certificate, storage and crypto support: This module offers all the functionalities related tothe processing of certificates, its storage, as well as all cryptographic functions (parser, verify,etc.) needed to process certificates, e-signatures, etc.

• Service and user’s profiles: These modules are used to manage and support the differentprofiles supported by the server. A profile is useful to make requests simpler. The profiledetermines which information can be requested and should be answered in a response. Forexample, there could be a profile that returns the specific information needed for the XAdES-Tform, another for the XAdES-X-L form, etc., or the information contained in the certificatefrom a particular PKI (user’s name, passport ID, address, etc.). The profile could also determinethe information to return for a specific type of client such as thin clients. In our system, tosimplify requests, we have defined a profile for each AdES form (see Section 2.2). Thus, wedo not need to specify the validation data explicitly to recover them. In the response, theserver provides the validation data needed.

• Policy management: This module is responsible for the different policies that can be used inthe service. Specifically, a policy determines the behaviour for a specific profile.

• Harvester module: This module gathers from the CA repositories (e.g. LDAP servers), OCSPand SCVP responders some information needed to carry out certification path processing.This information is stored in a repository called harvested evidences. Thus, we could have inadvance some information which is used in the certification path processing and makes thisprocess faster.

• Scheduler module: The scheduler interacts with the harvester module to have the validationinformation up to date.

• Analyzer: It is responsible for analysing the information obtained from the Harvester module.• Repositories: It is the module that accesses the database systems to store all the informationthat needs to be stored by the rest of the modules.

• Validation data store: This specific module, by using repositories modules, stores all theinformation needed for particular certification path processing operations. This informationis stored so that the requester can subsequently have the information used in a validation andwhich at that specific moment could not have been returned (e.g. in the event, it is a thin client).



• Log: It registers the different events that occur in the system in order to detect possibleproblems or attacks related to the behaviour of the different modules and their implementation.

• LDAP (pkiCA), OCSP, SCVP, XKMS, XKMS-ACVS Clients: These modules implement theLDAP (pkiCA), OCSP, SCVP, XKMS, XKMS-ACVS protocol according to their specifica-tions, respectively.

• PK IX LDAP (pkiCA), OCSP, SCVP, XKMS, XKMS-ACVS Clients: These modules implementslightly different versions of these protocols for a specific PKI because the PKI implementa-tion is not fully compliant or it introduces some changes not contemplated in the standard,e.g. specific authentication methods.

• Mapping: This module helps to determine which module is used to perform the certificatevalidation. Most PKIs introduce the URL of the CRL distribution point, the URL of theOCSP responder, etc., in the certificate extensions. However, some certificates do not includethis information. Thus, a module that allows the system to know which module the clientshould use to validate a certificate is needed. This module processes a configuration file,which indicates, for each PKI, the module to be used. This module is also used to determinethe module and the URI to use so as to recover certificates from the reference to a certificate.

3.4. PKI protocols

PKI protocols are used by the validation authority to build candidate certification paths and performthe subsequent validation. Depending on the certificates involved in the validation process, theservice requests validation information from the corresponding PKI. The protocols used dependon the mechanisms supported by every PKI. These protocols vary from online validation protocols(OCSP, SCVP, etc.) to offline methods (CRLs, delta CRLs, etc.).

In each request, this service uses the protocol it considers the most adequate. This behaviouris modified it the client specifies the protocols to be used in the validation. This functionality isfundamental for some scenarios, such as in e-commerce when some transactions, due to the risksassumed, require online verification.

It is also important to mention that our extension to the XKMS protocol (XKMS-ACVS), canalso be considered a PKI protocol. Thus, our service could make a request, by means of XKMS-ACVS, this request being processed by other entities, such as a PKI or another validation entity.Thus, the delegation of the validation of some particular certificates is possible.

4. CERTIFICATE VALIDATION SERVICE SPECIFICATION

In this section we present the design of the proposed XKMS-ACVS. First, we define the main goalsto be supported in order to provide an ACVS. Next, we introduce the different working modes theprotocol supports to interact with it. These modes are compatible with the XKMS specification.Then, we provide a detailed specification of the different extensions made to XKMS to supportthis kind of service. Finally, we provide an example of a validation flow to describe the workingof the different components of our proposal to perform this certificate validation.

4.1. Main goals for an advanced validation service

This section defines the main goals and requirements that an ACVS should fulfil. Regarding thegoals, six objectives have been formulated.

First, clients of a certificate validation service should be as independent as possible from theunderlying protocols used during the validation process. As a second goal, legacy validationmechanisms must be supported; that is, it should be possible to perform different types of vali-dation processes through this service (e.g. OCSP/SCVP), depending mainly on which validationmechanism has been implemented by the underlying infrastructure.

The third goal is the support of different kinds of certificates belonging to several infrastruc-tures. At least, X.509-based certificates (both identity and attributes certificates), PGP and SPKIcertificates have to be supported.



As a fourth goal, a repository is mandatory to store the validation data for future non-repudiationchecking operations. These data could be certificates, CRLs, OCSP/SCVP responses, amongothers. They depend on the validation mechanism chosen.

The fifth goal is related to policy and profile configuration. End clients must be able to select aspecific policy and/or profile to configure the behaviour of the service. In some cases it could beinteresting to perform any kind of validation, but sometimes only an online mechanism validationcould be valid (e.g. in e-commerce platforms).

Finally, the last goal is the control access configuration by which we can determine what entitiescan use the service and how they can do it. In some organizations only certain clients are allowed(e.g. after paying a fee), whereas others have free access.

Bearing in mind the above goals and the open issues discussed in Section 2, some needs andrequirements are raised for an ACVS. We next summarize those needs and requirements which aservice with these features would have. The general requirements are as follows:

• The certificate validation service must fulfil the DPD and DPV requirements.• This service must allow validating different types of certificates.• The architecture of a validation service should be as generic and extensible as possible toenable the incorporation of new features in future releases.

Next, we summarize the requirements of mandatory fulfilment for the main actors involved ina validation process. On the client side, we have the following:

• Clients should be able to include intermediate certificates to ease the building process of thecandidate certification paths.

• Clients have to be able to indicate whether they want the revocation status of the certificatesincluded in the certification path to be verified by the server.

• Clients should be able to specify the precise time by which the validation process should becarried out.

On the server side, the following requirements should be fulfilled:

• Storing the validation data along with all information used during that process.• Receiving the trust anchors in which clients trust to build the certification paths.• Receiving indications about the protocol to be used in the validation process.• Supporting service policies and profiles.• Returning both validation information about the protocols used during the validation processand information about a particular format and form (e.g. XAdES-X-L).

• The server might establish that all requests are digitally signed by the clients to check whetherthey are authorized to use the service or not.

• An asynchronous message exchange must be allowed.

Finally, regarding the information that needs to be exchanged between clients and server, whichimplements the certificate validation service, two main requirements are defined:

• Requests could indicate that the server stores information about the validation process, togetherwith all information used by the server to carry out such a task.

• Requests must specify what information contained in the certificate should be returned in theresponse. Thus, this requirement eases the processing of the certificates by a client.

4.2. XKMS-ACVS

In this section we explain how we have extended XKMS (named XKMS-ACVS), its services andmodes to satisfy the goals defined in the previous section.

According to XKMS specification, there exist two kinds of messages in the Validate service:ValidateRequest and ValidateResult; similarly, there exist two types of messages in the Locateservice: LocateRequest and LocateResult. All these messages extend the MessageAbstractType,which includes the element MessageExtension that was intended as an extension mechanism forXKMS messages.



Table I. Extensions defined in XKMS (XKMS-ACVS).

Service Service message Extension Message extension defined

Validate ValidateRequest ExtendedValidation ExtendedValidationRequestValidateResult ExtendedValidationResult

Locate LocateRequest ExtendedLocation ExtendedLocationRequestLocateResult ExtendedLocationResult

CLIENT

NORMAL MODE / SYNCHRONOUS MODE

XKMS ValidateRequest + ExtendedValidationRequest

XKMS ValidateResult + ExtendedValidationResult

XKMS-ACVSSERVER

Figure 3. The XKMS-ACVS Validate Service in the synchronous mode.

Taking this into account, to reach the goals outlined in Section 4.1, we have defined the extensionsnamed ExtendedValidation and ExtendedLocation for the XKMS Validate and Locate services,respectively. These extensions define four new elements that suit the MessageExtension fieldperfectly. Thus, as we have defined them as extensions, we maintain backward compatibility withthe current XKMS systems and facilitate the support/migration to the new extensions proposed.These extensions are shown in Table I and described in Section 4.3.

For the different services defined in XKMS (Validate, Locate, etc.), there are different modesto access them: synchronous and asynchronous. Furthermore, a two-phase protocol is defined foravoiding denial-of-service attacks with these modes. In the following sections we explain how thedifferent modes work and how we have extended the different requests and responses with theelements shown in Table I to support the goals defined in the previous section.

4.2.1. Synchronous mode. The synchronous mode is used when the information requested can beprovided in the response almost immediately or in a short interval of time. It consists of a requestand a response (see Figure 3).

In the validation of a certificate, according to XKMS, the client sends a ValidateRequestmessageand receives a ValidateResult message. As for Locate service, the client sends a LocateRequestand receives the result in the LocateResult.

In this mode, for the Validate service (see Figure 3), in the request (ValidateRequest) we includethe element called ExtendedValidationRequest. In the ValidateRequest we include the certificate(or a reference to its public key) to validate and, optionally, the instant of time at which we wantto perform the validation. In the ExtendedValidationRequest we include the rest of the informationneeded to customize the certification path processing (protocols to use, validation data to obtain,etc.). An in-depth description of this element is provided in Section 4.3.

As a response to this request (see Figure 3), we return a ValidateResult which contains anExtendedValidationResult. The ValidateResult only returns if the certificate is valid or not in theperiod of time requested. The rest of the data needed to recover for an advanced certificate validation(validation responses, CA certificates, etc.) is provided in ExtendedValidationResult, described inSection 4.3.

With the Locate service, in order to fetch or locate a certificate, the steps to follow, in thesynchronous mode, are similar to the steps explained for the Validate service but the servicemessages and extensions defined in Table I for this service must be used. With the extension(details in Section 4.3) we can obtain additional information contained in the certificate or in itsextensions (e.g. user’s name, e-mail, role, etc.).



CLIENT

Asynchronous MODE


XKMS ValidateResult + PendingRequest

XKMS StatusRequest

XKMS StatusResponseX times

XKMS PendingRequest

XKMS ValidateResult + ExtendedValidationResult

XKMS-ACVS SERVER

Figure 4. The XKMS-ACVS Validate Service in the asynchronous mode.

Two-phase protocol


XKMS ValidateResult + Represent + Nonce

XKMS ValidateRequest +Nonce+ ExtendedValidationRequest

XKMS ValidateResult + ExtendedValidationResultCLIENT

XKMS-ACVSSERVER

Figure 5. The XKMS-ACVS two-phase protocol with our extensions.

4.2.2. Asynchronous mode. The asynchronous mode is used when the server receives a requestthat cannot be completed immediately. In this case, the client receives a response indicating thatits request is pending and that he has to wait to obtain it. In particular, for the advanced validationof a certificate, the process is depicted in Figure 4.

In this process the client requests the advanced validation by sending the ValidateRequest withthe ExtendedValidationRequest. As a response, the server sends the ValidateResult indicating withthe PendingRequest value (in the ResultMajor attribute) that the request cannot be processedimmediately. In this response is also included a request identifier (RequestId) to subsequentlycheck the status of this request.

From the moment the client receives the PendingRequest value, he has to check periodicallywhether the response is available or not. This checking would not be necessary if the client in hisrequest had specified a notification mechanism such as e-mail. For the purpose of checking thestatus of a request, in XKMS, the StatusRequest and StatusResponse messages are defined. Whenthe response is available the server indicates it in the StatusResult with a Success.

The client sends a PendingRequest request to the server to recover the response that is alreadyavailable. As a response the server sends a ValidateResult with the ExtendedValidationResult.

The asynchronous processing for the Locate service follows the same behaviour just describedbut using instead the corresponding messages shown in Table I.

4.2.3. Two-phase protocol. In XKMS, the two-phase protocol is defined to protect the serviceagainst denial of service attacks. This protocol performs a lightweight authentication just beforesatisfying a request. The goal of this protocol is to check if the client is able to process theresponses provided by the server.

Thus, in the first phase, when the service receives a (Validate, Locate, etc.) request (see Figure 5),the server replies with a response indicating that the two-phase protocol has to be executed(Represent value in the response) and also sends a nonce.



In the second phase, the client sends the original request with the nonce. If the nonce is thesame as the one provided in the first phase by the server, then, the response is now sent. Thistwo-phase protocol can even be combined with the asynchronous mode.

In XKMS-ACVS, the behaviour of the two-phase protocol is the same as specified in XKMS,but we have extended the requests and responses with our extensions as shown in Figure 5. Next,we comment on some aspects of the authentication process and a new way of performing it.

In XKMS, a stronger way of authentication would be the use of an e-signature in eachrequest. However, this process supposes a higher overload to the server. We propose next alightweight process of authentication which is a hybrid approach between these earlier ways ofauthenticating the user for those cases when the client usually works with a certificate validationservice.

Our proposal of authentication is based on the two-phase protocol and on the use of Paywords[19], which are chains of hash values. The idea consists in the client sending a hash value calledroot (w0) to the server. This root value is the result of executing n times a hash value over astarting value (wn). Thus, w0=hn(wn). This root value is signed and sent to the server. Thus,each time the client has to access the service, the client reveals a new value of the chain, from thefirst value (w1) to the n-value (wn) in turn. The service would know that the hash value comesfrom the client because in a hash function the reverse operation is impossible to perform if wesuppose perfect cryptography.

We propose that when the service needs to authenticate the client to avoid denial-of-serviceattacks, the server executes the first phase as explained before. Then, in the second phase, the clientsigns the request with a root value of a Paywords chain. This root value is used as a new nonce.Then, the server verifies the signature and stores this nonce. In subsequent requests the client sendsdirectly the following Payword. Thus, we avoid that the service has to send us a response with anonce indicating that an authentication is required.

In this mechanism, in the first authentication, the number of messages exchanged between clientand service is the same as the two-phase protocol proposed by XKMS. For subsequent times, theserver does not execute the two-phase protocol, and therefore the number of messages to exchangeis reduced. As for the security, we can say that it is the same as in the previous proposal becauseboth proposals are based on the use of nonces.

4.3. Extensions

The subsequent sections describe the information included in each of the new extensions mentionedin different modes and shown in Table I.

In these extensions, we have defined two elements that are used for extensibility purposes inthe requests (the OptionalInputs element) and in the responses (the OptionalOutputs element).These elements are defined similar to MessageExtension defined in XKMS for basic services, andcan contain any type of element. These elements are common to all our extensions and will becommented upon only when an element is introduced in them.

4.3.1. ExtendedValidationRequest. In the validation of a certificate, the client sends the service aValidateRequest message, which includes information regarding that certificate within the elementQueryKeyBinding; optionally, the time at which the certificate should be validated can be includedwithin the TimeInstant subelement.

For the ValidateRequest we have defined the ExtendedValidationRequest extension. The purposeof this extension is to allow the client to customize the process of certification path processing (thespecific validation mechanism that should be used or the indication that the complete certificationpath validation should be accomplished) and indicate the information that should be retrieved (suchas the complete certification path) and stored (as a proof of existence of such validation data tobe used later). The elements of this extension are shown in Figure 6.

The ExtendedValidationRequest field has two attributes: Profile and ReturnCertificate. Theformer allows a user to indicate the server with a specific profile. A profile usually establishes acontext that requires a predefined behaviour, thus simplifying the number of parameters indicated



Figure 6. ExtendedValidationRequest element.

in a message. The latter indicates if the client wants the validated certificate to be returned withinthe response, as it is not mandatory to include the complete certificate within the request (it caninclude a reference to the certificate, such as its IssuerAndSerial or an URI). Additionally, theExtendedValidationRequest consists of several subelements.

The ValidationProtocols subelement defines the validation mechanisms to be used. The servercan use the first available mechanism or even all of them. For each mechanism we specifyits identifier, the priority with which the mechanism should be applied, the validation responsereturned, the details regarding that response, etc.

The CertificationPathValidation subelement indicates that the server should accomplish the certi-fication path validation from the target certificate up to one or several trust anchors. It also indicateswhether certificate status data (OCSP/SCVP responses, CRLs, etc.) should be returned. Addi-tionally, the client can provide intermediate certificates to ease the building process of candidatecertification paths.

The ReturnCertificationPath subelement indicates that the server should return one or severalcertification paths up to one or more trust anchors. These certification paths can be different fromthose validated by the server. Furthermore, this subelement allows the client to indicate if thesecertification paths should be validated by the server, although no validation data will be returned(certification path validation data could only be returned if specified inCertificationPathValidation).

The StoreValidationInformation subelement expresses that the validation data used in the certifi-cate validation process should be stored in the own XKMS-ACVS server or in an external secureserver as long as the XKMS-ACVS server offers these capabilities. By default, when we includethis element, the information is stored in the XKMS-ACVS server. We also provide the possibilityof specifying the information needed for an external server for those cases when the XKMS-ACVSserver does not offer/support storage capabilities for this information or when he wants to enablethe client with the possibility of using his preferred storage system. As this element is generic weconvey the information needed by any current server or other future proposals that could appear.If the server does not provide any of these capabilities (own storage or external storage) and theclient had to store validation data, the client would have to obtain them and, after that, he wouldhave to send them to a secure server.

This element supports that clients (especially thin clients) can store, by means of the XKMS-ACVS and in a secure way, the validation data used in the certificate validation process so thatthese data can be used and recovered subsequently. Thus, a client may indicate that he is interestedin performing the validation but does not want to obtain validation data right now, instead wantsto store them to recover them later. Hence, the functionality of the client is simplified since theserver is in charge of the management and storage of the validation data.

Currently, a secure external server that could be used is a Long-Term Archive and NotaryServices (LTANS)-based server. The main advantage of a LTANS server, unlike using a traditionaldatabase, is that the LTANS server periodically generates cryptographic evidences that can proveto any party that the information stored in the system has not been tampered with, since this



information was stored in the server. Another advantage is that the client does not have to manageand store this information, and therefore avoids making backups and prevents its loss or damage.LTANS is interesting even when the client stores signed information as certificates or signeddocuments since the algorithms used in them, long time after storing this information, may becomeweak. LTANS prevents this problem by including periodically cryptographic evidences that provethat these data have not been modified and that they existed before the algorithms became weak.In the short term, it is also useful if the certificates and data validation use cryptographic keysthat at present could be considered weak (e.g. currently RSA keys of 512 bits length are notrecommended [31] since this kind of key might be broken in a short period of time). The useof the LTANS server is also useful when the client wants to create an AdES form that requiresthe references to the validation data but not the validation data itself, e.g. AdES-C. The reasonthat the client could store validation data in a secure way is that he could need to use them laterfor creating a more advanced AdES form as AdES-X-L. Thus, LTANS is also useful when weneed to develop a validation data registry so that validation data are protected against losses orcryptographic weaknesses. Finally, the client can use this proposal when he does not know if theevidences will be stored for a short or long term (e.g. for storing the evidences generated duringthe negotiation of a contract).

As LTANS [32–34] might become standardized, we have defined the information that we needto specify with this proposal through an element named LTANSServerInfo. This element is includedin the StoreValidationInformation element. In the LTANSServerInfo element, we specify the accessaddress to the LTANS server, the client identifier to gain access to that server, the LTANS serveridentifier to store the validation data in, the set of policies to be applied when archiving thevalidation data, the validation data that should be archived, etc.

Subsequently, when the client wants to recover the validation data, he can send a request(Validate or Locate) with the certificate and in the OptionalInputs subelement, the stored validationdata identifier and the LTANSServerInfo element.

4.3.2. ExtendedValidationResult. The ValidateResult message indicates whether the specifiedcertificate is valid or not at the moment requested. If the ValidateRequest message sent to theservice included the ExtendedValidationRequest field, the service would send, as a response, aValidateResult message with the extension ExtendedValidationResponse. In this case, the existenceof this element is mandatory. The purpose of this extension is to carry the data asked for in theExtendedValidationRequest element, such as the complete certification path and the validationmechanisms responses.

This extension is composed of several elements (see Figure 7). It has one attribute, called Profile,which indicates the profile used by the server when validating the specified certificate. Generally,its value is equal to the corresponding attribute in the ExtendedValidationRequest element withinthe ValidateRequest message.

The CertificateValidity subelement includes the validated certificate (or a reference to it) andinformation related to the certificate validation process, the specific validation mechanism used,the validation responses and the reference to the certificates within the certification paths from thespecified certificate up to one or several trust anchors.

Figure 7. ExtendedValidationResult element.



The CertificationPaths subelement can include one or more certification paths from the specifiedcertificate up to one or several trust anchors. It can also include validation data regarding everycertificate within a certification path.

4.3.3. ExtendedLocationRequest. When a client wants to locate a certificate, he sends the servicea LocateRequest message. This includes information regarding the certificate within the elementQueryKeyBinding and it also includes, optionally, the time the certificate should be located at,within the TimeInstant subelement. For the LocateRequest message we have defined the extensionExtendedLocationRequest. Its purpose is to allow the client to obtain the information includedwithin the specified certificate (such as the name of the subject, the identification number of thesubject, the identification of the certificate issuer, etc.) as well as recovering the stored informationassociated to the certificate, such as the information of certification path processing used in aprevious validation. Thus, we facilitate that clients (especially thin clients) do not need eithercapabilities for processing the certificate and extensions, some of them defined for a particularenvironment (e.g. some certificates may contain some information such as name and surname,passport identifier, etc. in the common name of the certificate or in an extension) or the managementand storage of the information associated to a certificate validation process. The elements of thisextension are shown in Figure 8.

The subelement named ReturnKeyInfoPersonalData indicates that the client is interested inrecovering information related to the certificate or the certificate owner. In order to recover thevalidation information stored in the XKMS-ACVS server or in an external server we use theOptionalInputs element with some of the elements of the StoreValidationInformation elementdescribed in Section 4.3.1.

4.3.4. ExtendedLocationResponse. The ExtendedLocationRequest element is mandatory when aLocateRequest request contains an ExtendedLocationRequest field. The purpose of this extensionis to carry data asked in the request. Its elements are shown in Figure 9.

The subelement called KeyInfoPersonalData includes information related to the specified certifi-cate (e.g. its description), the certificate owner (e.g. its identification number, name, surname,email, etc.), the entity represented by the owner (e.g. the entity identifier, the entity name, the entitydomain, etc.) or the existing relationship between the certificate owner and the entity (e.g. theowner position within the entity, the entity unit, etc.). This subelement includes the Other fieldfor extensibility purposes in the specification of certificate data. If requested, the OptionalOutputselement would contain the stored information associated to the certificate.

4.4. Certificate validation flow example

In this section we present an example that describes the main operations that could take placewhen a (thin) client wants to validate a certificate. In this example let us suppose that this clientalso wants to obtain the validation data associated with this certificate for, subsequently, creatingan AdES-C form from the signature of another entity he has received in CMS/XMLSignature or

Figure 8. ExtendedLocationRequest element.

Figure 9. ExtendedLocationResult element.



Figure 10. Certificate validation example flow.

AdES-BES/EPES/T forms (more details on e-signature formats and AdES forms can be foundin Section 2.2). We also suppose that this client provides the validation authority (an XKMS-ACVS server) with the certificate and wants to obtain the references to certificate, CA certificate,OCSP responses and he also wants to store the validation data (not the references) in a LTANSserver because he thinks, probably, that he could need them in the future to create an AdES-X-L form. For the sake of simplicity we suppose that the client can make the request withoutauthentication and the two-phase protocol. The steps that would take place in this example appearin Figure 10.

In step 1, the client creates a ValidateRequest indicating that he wants the validation of thecertificate referenced in the request. He also provides the information needed to store the associatedvalidation data in a LTANS server.

The server checks (in step 2) whether the client is able to make the requests. The request isprocessed to determine the kind of request (step 3). Then, it is forwarded to its associated module(step 4) to process it.

The request specifies the validation in the terms explained above. Thus, the server queries(step 5), in the harvested data repository, whether the validation data requested (certificate and CAcertificate) had been obtained in the anticipated way for the Harvester module. In this example,we suppose that these data are not stored in this repository. Thus, the server requests the Schedulermodule (step 6) to schedule to obtain these data for future validations (creating also the CPVTstrees, see Section 2.3.1).

As the validation data are not stored, the server proceeds to recover them. For this purpose,it checks the module and the URI in the Mapping module to obtain the validation data for thecertificate requested (step 7). In this case, the module used to recover them is the LDAP (pkiCA)protocol. With the LDAP (pkiCA) protocol (steps 8 and 9), the server obtains the certificates andthe CAs certificate from the corresponding PKI up to a trust anchor. There we suppose that the CAof the certificate is not a trust anchor, but a subdomain of another considered as a trust anchor.



Figure 11. Using stored information to build AdES-X-L form.

To check the validity of the certificate, the server processes the certificates to be validated(step 10). In these certificates the OCSP responder to be used is specified. The server additionallychecks in the Mapping module whether specific OCSP modules should be used. In this case, wesuppose that this is not necessary since the PKIs offer this service according to the standard andwithout any special authentication. Thus, the server uses the OCSP client to check the status of thecertificates (steps 12 and 13). All the validation data obtained (certificates and OCSP responses)are stored in the LTANS server specified by the user (steps 14 and 15). Thus, these data couldlater be recovered by the user from a more powerful client to create the AdES form. Finally, theValidateResult (with the ExtendedValidationResult providing a stored validation data identifier andthe references to the certificate validation information) is created (step 16) and sent (step 17) tothe client.

Later, if needed, the client operating from a thick device (if we consider the thin client hasnot enough computational resources for this operation) could use the XKMS-ACVS server (or theLTANS server, directly) to recover the validation data and create a more advanced AdES form.This process is shown in Figure 11 and we explain it next.

Let us suppose the client needs to convert the AdES-C form into an AdES-X-L form froma powerful device. First, the client invokes the XKMS-ACVS server (step 1 in Figure 11; fromnow on the steps mentioned refer to this figure) by indicating that he wants to check the validityof the certificate at that moment and recover the information previously stored by using theValidateRequest, or he could request directly the information previously stored by using theLocateRequest. The XKMS-ACVS server, similar to the process previously explained, verifiesand identifies the kind of request and the client’s intention to recover the certificate validationinformation previously stored (steps from 2 to 6). From the information obtained, the XKMS-ACVS server can retrieve this information from the secure server indicated by the client. In thiscase, the LTANS server (steps 7 and 8), namely, the LTANS Export operation, is invoked for thispurpose. Once the client has recovered the information needed for creating the AdES-X-L form,the client has to request a timestamp from a PKI (steps 9 and 10). This timestamp is added to anAdES-C form and thus we obtain an AdES-X form. Finally, we add the validation data obtainedfrom the XKMS-ACVS server to the AdES-X form and then the AdES-X-L form is built (step 12).



Thus, the XKMS-ACVS facilitates that the clients follow the set of steps related to the certi-fication path processing (from 4 to 13 in the Figure 10) associated to a certificate validation aswell as the management and storage of certificate validation data (steps 9 and 10 in Figure 10 andsteps 7 and 8 in Figure 11). If XKMS-ACVS was not supported, the client, in order to build anAdES signature, would have to support the different protocols and develop the business logic tofollow the steps just explained. Thus, with our proposal the client only has to support one protocol,XKMS-ACVS. Furthermore, if a server as LTANS was used as in Figure 11, the client could besure of when the validation data were stored and that they have not been modified since then, evenif a cryptographic weakness appeared in the keys or certificates used during the certificate valida-tion process. Therefore, with our extension we reduce the client’s implementation (they have tosupport only one protocol instead of several). Furthermore, our proposal also facilitates the updatesof existing PKI protocols as well as the appearance of new ones since this task is performed inthe server. This is especially interesting when some PKIs implement their own access mechanismto validation data. Finally, if storage support is provided, the client does not have to manage andstore the evidences used in the different processes, preventing the losses or damages of these data.

5. AN SOA-BASED ADVANCED ELECTRONIC SIGNATURE ARCHITECTURE

In this section we describe the main elements that compose the SOA architecture of the Universityof Murcia [35, 36] for the e-government processes where the advanced electronic signature isinvolved. Next, we focus on a real scenario for the university community, such as the generationand signing of electronic mark certificates.

5.1. Design of the architecture

The e-government SOA Infrastructure of the University of Murcia (Figure 12) is composed ofseveral elements. Some of them are hosted by the University and the rest by trusted third parties,such as certificate service providers or PKIs. We introduce next those that are necessary to under-stand the scenario presented in the following section.

The Digital Signature Services (DSS) server is the pivotal element of the infrastructure. Thisserver is able to produce server-based signatures on behalf of the University of Murcia and

Figure 12. e-government SOA infrastructure.



verify signatures on different formats (PKCS/CMS, XMLDSig, PDF, AdES forms) and supportdifferent profiles of use (profiles for different options of signature formats and forms—PKCS,CMS, XMLDSig, AdES—different parameters, extensions to include, etc.). Furthermore, althoughthe e-signatures created are based on the use of the keys on the server, a client that has generatedhis own signature (CMS or AdES) or that has received a signature from another entity, can usethis server to verify and/or update it to a more advanced signature form (AdES forms). Thus, thisserver facilitates that the clients carry out these operations, especially thin clients that have lesscomputation resources. Hence, all the operations performed in Figure 11 by the client would beperformed by the DSS server (behaving as an XKMS-ACVS client) and the client would only haveto invoke the DSS Web service by sending the signature and indicating that he wants to convertit to another more advanced form as AdES-X-L.

The service has been developed according to the OASIS DSS [37] specification that defines it asa Web service. This service is invoked by all the different applications and services which requirethe incorporation of the e-signature processes in the University, either for validating any kind ofe-signatures (produced by clients or servers) and timestamps or for producing signatures on behalfof the University. Thus, thanks to the DSS service, the incorporation of e-signature functionality iseasier since applications (or services) only have to develop a client for this service. Some of theseapplications are the virtual campus (also known as SUMA) [38], the official electronic noticeboardsystem, the electronic registry and the annual university enrolment application. In e-signatureprocesses, our most commonly used profile is able to perform the verification process, add atimestamp to the verified e-signature and store it in a secure archive system based on LTANS.Other profiles supported by our implementation are the conversion from CMS/XMLSignaturesignatures to AdES forms and from AdES forms, as AdES-BES/EPES/T or AdES-C, to moreadvanced signature forms such as AdES-X-L. Thus, the DSS facilitates (thin) clients to performthese transformation processes.

The DSS server performing the different operations related to certification path processinginvokes the XKMS-ACVS server, which is described below. The invocation is made by means ofthe Web services interface it offers. Thus, we simplify the functionality to be developed in the DSSserver, which is focused on e-signature operations. Hence, the rest of the operations related to theverification of an e-signature, such as certification path processing, is delegated to another server,the XKMS-ACVS. Furthermore, this delegation facilitates the maintenance and the update of thefunctionality of the operations related to certification path processing. Any change produced in theimplementation of the XKMS-ACVS server, such as incorporating new algorithms and protocols,solving bugs, etc, does not imply changes in the DSS server because the DSS server only has toknow the interface to invoke the XKMS-ACVS, which remains unchanged.

For the invocation to the XKMS-ACVS from DSS we have developed a client library gener-ated from the Web service specification in Web Service Description Language (WSDL) that theXKMS-ACVS server offers. This library implements the different operations according to the spec-ification of the XKMS-ACVS service described in Section 4. The details of the implementationare commented upon in Section 5.3. Similar to the XKMS-ACVS service, the functionality that theDSS server needs from the LTANS server is invoked by means of a client library that implementsthe operations defined by the LTANS Web service.

In this infrastructure (see Figure 12), SUMA [38] provides to lecturers and students a set oftools to improve the learning of students as well as facilitating this process to be carried out anytime, everywhere. In SUMA students can see contents and syllabi, chat with lecturers, query theirmarks, etc. It also offers additional services to the university community, some of them specificallyfor lecturers, such as the generation and signing of electronic marks certificates.

The Security Assertion Markup Language (SAML) [39] server is the element that performs allthe authentication and authorization processes through the infrastructure. This server exchangesassertions with applications and services in the university, for the performing of access controldecisions.

The XKMS-ACVS server is the element that carries out the validation of all the certificatesused in the e-signature processes performed mainly in the DSS service or in the applications or



services that use it directly. In the context of the University of Murcia, it is able to perform avalidation operation against three main certificate services providers. The first is the DireccionGeneral de Policıa (DGP)—Spanish state police headquarters—for the validation of the SpanishNational Identity Card through the OCSP protocol. The second and third are the Fabrica Nacionalde Moneda y Timbre (FNMT)—the Spanish state certification service provider—which is the maincertificate service provider in Spain and provides CRLs for performing the validation process, and,the Agencia de Certificacion de la Comunidad Valenciana (ACCV)—a regional certificate serviceprovider—which provides both CRLs and OCSP validation services. The University of Murciahas an agreement with the ACCV not only for the provision of digital certificates, but also forconsuming its timestamp service according to the RFC 3161 [40]. This service is offered throughits Time Stamping Authority (TSA), which is qualified by the Spanish Government.

The LTANS server is the element in charge of archiving and preserving the electronic documentsover long periods of time. As an internal policy, all documents to be preserved are stored by theapplications (or services) in this repository, even XAdES-X-L documents. We have decided to usethis server instead of converting to XAdES-A because this latter form is not legally required. Oneof the services more frequently used by this server is the DSS, where we have defined a profileused to create an AdES-X-L form and store it as we explain in the following section. Furthermore,with LTANS the long-term validation information generated is common for all the documentsstored, which involves storing less information than when we have to include it separately for eachone. Thus, the LTANS server periodically generates timestamps for the archived documents toprevent the weakness of the cryptographic material [32–34]. Currently, although the XKMS-ACVSimplementation supports the storage of validation data in an LTANS server, our applications andservices are not still using this functionality. However, we plan to incorporate it into this service fortwo purposes required in some applications (or services): first, for the management and storage ofevidences associated with AdES-C form, and second, for the management and storage of validationdata when certificates with keys that may become weak in a short period of time are involved.

5.2. Scenario of use: electronic marks certificate

Based on the previous infrastructure, we describe how they are used in a scenario of use: thesigning process of a mark certificate by a lecturer. This process (see Figure 13), takes place at the

Lecturer DSSSAMLServer LTANSXKMS-ACVS TSAPKI

1. Signing the marks certificate

2. Verification, add timestamp and archive request

3. Authorization request

10. Archive request (XAdES-X-L document)

4. Validation request5. OCSP request

6. Timestamp request

grace - period

10’. Archive response

6’. Timestamp token

5’. OCSP response

3’. Authorization response

4’. Validation response

7. Validation data request

8. CA certificates / OCSP request

8’. Certification path / OCSP response7’. Validation data response

9. Timestamp request9’. Timestamp token

SUMA

2’. Response

Figure 13. Electronic mark certificate process.



end of the term when the lecturer wants to publish the official marks that are sent to the secretariatof the University.

At the beginning of the process, the lecturer signs the electronic marks certificate by means of aqualified certificate of the Spanish National Identity Card (step 1). This signed document is receivedby the SUMA application, which initiates the validation of the e-signature and the archive of thisdocument (step 2). At this point, the DSS server performs several tasks to carry out this process.

As part of these tasks, the DSS server requests an authorization to the SAML server (step 3).This server checks the attribution of the SUMA application for invoking an e-signature validationand archive operation. Next, DSS checks the revocation state of the electronic certificate usedfor signing the document through the XKMS-ACVS server (step 4). The XKMS-ACVS server,which functions according to the architecture presented in Section 3.3, is able to establish anonline connection with the certificate service provider for performing the validation process witha standard mechanism, like OCSP (step 5). Once the verification is performed, the DSS serverrequests a timestamp token to the TSA (step 6) with the aim of guaranteeing the validation time.Thus, the DSS server creates a signature according to AdES-T form (including the timestamp) toguarantee the non-repudiation of the document and the date it was produced.

The University of Murcia has adopted, according to the Spanish government recommendations,XAdES for the different electronic signed documents that must be archived and preserved. XAdESalso introduces the grace-period concept, as the period of time that the verification system mustwait until the validation data of the electronic document are available.

After this grace period, DSS begins the second validation process (step 7). In this process, therecovering of all the validation data of the digital certificate is essential. For this reason, a secondcommunication with the certificate provider is performed (step 8). In this connection the trustedcertificate chain of the lecturer certificate, and a signed OCSP response which results from thechecking about its revocation state, are provided.

Then, DSS requests a new timestamp token to the TSA (step 9) for protecting the certificatechain obtained in this second validation process. Finally, an XAdES-X-L is generated and sentto the LTANS server for the archiving and long-term preservation of this information (step 10).LTANS securely stores this document and the process finishes. The reason that we use LTANSinstead of converting the XAdES-X-L form into XAdES-A was already explained in Section 5.1.

5.3. Details of the implementation

In this section we provide a description of the different elements and components developed inthe architecture and the scenario presented in the previous sections. Our developments are basedon open source code and mainly based on the Java language because it is object-oriented and thecode can be used in several platforms.

The different Web servers involved in the architecture are based on the OAS 10 g applicationserver. We have based the support of Web services used in the different servers (DSS, LTANS,SAML, XKMS-ACVS) on Apache Axis library, which provides an implementation of the SOAPserver as well as several tools and APIs for the development of Web service applications in Java.For the invocation to the different Web services we have developed client libraries generatedfrom the different specifications of the Web services in WSDL. Hence, we have developed clientlibraries for DSS, LTANS and XKMS-ACVS from their specifications in WSDL by using ApacheAxis. These libraries are also developed in Java. Namely, the DSS client library is used by thedifferent applications included in SUMA and needs the use of signature operations on behalf of theUniversity of Murcia. The DSS server, in turn, uses the XKMS-ACVS and LTANS client libraries toinvoke the different operations they offer. Thus, the DSS server only develops functionality relatedto e-signature and operations related to certification path processing, and the secure storage andmanagement of certificate validation evidences are delegated to XKMS-ACVS and LTANS servers,respectively. Thus, the development and maintenance of the DSS Web service is easier since adifferent functionality is provided by different Web services specialized in some specific task.

For the development of the different software we have made use of the Eclipse Open SourceIDE. As cryptographic library, we have used Bouncy Castle Crypto APIs. This library is used for



basic cryptographic operations (encryption and signature) and algorithms as well as for the supportof the main ASN.1 standards formats, such as PKCSs, CMS, RFC 3161, OCSP and CRLs. ForXML formats related to cryptography we have used Apache XML security library. Based on theselibraries we have developed the DSS service based on OASIS specification. The DSS service alsouses the iText PDF library for PDF documents. The development of the SAML server is based onOpenSAML.

The development of XKMS-ACVS, presented in this paper, is based on the OpenXKMS library[41] and on the extensions we have developed for this library. We had to include the source codeto process and manage the extension defined in Section 4.3. Our implementation uses OpenLDAPfor access to LDAP servers, Bouncy Castle for CRLs and OCSP, and our own implementation ofSCVP [42]. It is worth mentioning that most of PKIs are totally compatible with these standards.We also make use of a specific library for the access to the certificates provided by the FNMTbecause the method it offers is not completely based on LDAP. The reason is that they providerestricted access to this service (only provides access to public organisms). The functionality ofthe LTANS service developed follows its specifications [33, 34]; we have focused on Archive andExport operations since these are the operations currently needed in our services and applications.SUMA is developed using J2EE technologies, and for the invocation to the different services (DSS,XKMS-ACVS, etc) it uses the different client libraries above mentioned.

Finally, as database for storing data, for information about the different applications or Webservices, such as SUMA, XKMS-ACVS and LTANS. we are using Oracle 10 g.

6. RELATED WORK

This section analyses some related work with respect to the different components of the architecturepresented in Section 3 and the XKMS solutions presented in the current literature. Our architectureis based on SAVaCert [29] and some modules (mainly the Scheduler and Harvester modules) fromECPV [28]. Our proposal relies on these architectures for the validation phase of certificates, andwe have extended their main core to include some modules and features needed for supportingthe XKMS-based advanced validation required to recover and store the validation data associatedwith this process. Furthermore, we have presented a complete implementation of this proposal,currently being used at the University of Murcia.

On the other hand, regarding the current XKMS solutions, many have been the implementationsthat have appeared since the release of XKMS version 2.0 [16]. Almost all the participants andcontributors have developed their own prototypes, or even complete reference implementations.These companies are VeriSign, RSA Security, Microsoft Corporation, SQLData Systems andDataPower Technology, among others.

VeriSign’s implementation [43] allows key functionalities of PKI to delegate trust decisions forauthentication purposes. Its XKMSWeb service is located in [44]. On the other hand, Microsoft hasdeveloped an XKMS client and server on ASP.NET [45] with the aim of providing SOAP message-based accesses to PKI services. SQLData Systems provide a live test server for demonstrations andinteroperability tests [46]. A client side implementation of XKMS is also provided by SQLDataSystems, which is written in C/C++ as a COM object to be used in VBScript and/or ASP pages.Finally, DataPower Technology provides XKMS support to its XS40 XML Security Gateway [47],which can act as an XKMS client during the certificate validation phase with the aim of increasingthe security in Web service transactions.

Apart from previous implementations, other interesting commercial implementations can befound. For instance, the TrustFinder XKMS Server [48], developed by Ascertia, provides an XML-based server for locating and validating certificates. The building and validation of the candidatecertification paths can help the TrustFinder SCVP Server and/or the TrustFinder OCSP Server,both also developed by Ascertia.

Regarding open source implementations of XKMS 2.0, only OpenXKMS [41] has appeared.This solution, widely explained in [49], defines a complete design and implementation of this



specification. Moreover, it includes a new module to the XKMS engine, called PKIForXKMS,which is a connector used to add new specific underlying PKI implementations. The XKMSengine chooses the proper PKIForXKMS connector, which is in charge of interacting with thefinal PKI solution, according to the protocols implemented by this PKI. Finally, they have testedthe performance of XKMS and have concluded that the overhead time introduced by XKMS inthe validation is acceptable. We have used and extended OpenXKMS to include our extensions,since this solution is open source, quite complete in its definition and implementation, and isbased on Java so that it can be executed under several operating systems. A limitation of thissolution is the fact that OpenXKMS associates with a concrete domain the use of a specific module(the proper PKIForXKMS connector) manually. Our proposal is more generic by looking for theaccess information to the OCSP responders, CRL distribution points, etc. directly in the certificateextensions through a PKI-independent module. In case this information is not defined, a specificmodule is used as OpenXKMS proposes.

Finally, it is worth mentioning that there exist a number of XKMS prototypes that can be usedby the research community for interoperability testing purposes. Among others, we emphasizeWings of Hermes [50], which provides an online XKMS server accessible through different URLs.

7. CONCLUSION AND FUTURE WORK

In e-commerce, e-business and e-government, AdES signatures are fundamental in guaranteeingthe integrity and non-repudiation of a signed document over long periods of time. To build thesesignatures we need to incorporate some validation data. These data are needed so that the e-signatureand the certificate used in this signature remain valid for a long time after their creation. Thevalidation data are also needed to build a validation data registry when these forms are not usedor when they must be maintained independently.

The validation data could be obtained by means of XKMS when we validate the certificate.However, XKMS only provides a simple response indicating whether the certificate is valid ornot. We have extended XKMS to recover validation data. Our extension, XKMS-ACVS, is basedon the extensibility mechanisms provided by XKMS. Thus, we facilitate the incorporation of ourextensions to the current implementations of XKMS. Furthermore, we have defined the systemarchitecture and the different modules that a server providing this functionality should support.We have also proposed a lightweight authentication to facilitate long-term relationships betweenclients and the server. Finally, our proposal is extensible and could be improved with new features.

Our proposal has been developed and is being used by supporting different PKIs. This devel-opment has also been incorporated in the e-government platform developed in the University ofMurcia. In this platform, this component is fundamental for the generation of AdES forms and isrelated to the signature service based on DSS.

Finally, as regards future work, we are studying how to improve the infrastructure for access tothe services provided in the platform with Single Sign-On. We are also studying how to define afederation between different validation authorities based on XKMS-ACVS servers.

ACKNOWLEDGEMENTS

We thank the anonymous reviewers for their comments and suggestions. They have significantly contributedto improve the quality of this paper.

This work has been partially funded by ‘Programa de Ayuda a los Grupos de Excelencia de la FundacionSeneca 04552/GERM/06’ and CICYT TIN2008-06441-C02-02 project.

REFERENCES

1. European Parliament. Directive 1999/93/EC of the European Parliament and the council of December 1999 ona Community framework for electronic signatures. Official Journal of the European Communities 2000; L 013:12–20. Available at: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:en:HTML.



2. United Nations. UNCITRAL Model Law on Electronic Signatures with Guide to Enactment. United NationsPublications: New York, 2002.

3. European Parliament. Council directive 2001/115/EC of 20 December 2001 amending Directive 77/388/EECwith a view to simplifying, modernizing and harmonizing the conditions laid down for invoicing inrespect of value added tax. Official Journal of the European Communities 2002; L 015:24–28. Available at:http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32001L0115:EN:HTML.

4. Ministerio de Economıa y Hacienda. ORDEN EHA/962/2007, de 10 de abril. Boletın Oficial del Estado, no 90.14 de Abril de 2007.

5. Comite Europeen de Normalisation (CEN). E-invoices and digital signatures. CEN Workshop Agreement (CWA)15579, 2007.

6. Myers M, Ankney R, Malpani A, Galperin S, Adams C. X.509 Public Key Infrastructure: Online CertificateStatus Protocol—OCSP. IETF RFC 2560, 1999.

7. Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W. Internet X.509 Public Key InfrastructureCertificate and Certificate Revocation List (CRL) Profile. IETF RFC 5280, 2008.

8. Pinkas D, Pope N, Ross J. CMS Advanced Electronic Signatures (CAdES). IETF RFC 5126, 2008.9. Cruellas JC, Karlinger G, Pinkas D, Ross J. XML Advanced Electronic Signatures (XAdES). W3C

Recommendation, 2003. Available at: http://www.w3.org/TR/XAdES [6 August 2009].10. Consejo Superior de Administracion Electronica. Esquema de identificacion y firma electronica en las

Administraciones publicas, Consejo Superior de Administracion Electronica—Grupo de Identificacion yAutenticacion, 2009.

11. Cooper M, Dzambasow Y, Hesse P, Joseph S, Nicholas R. Internet X.509 Public Key Infrastructure: Certificationpath building. IETF RFC 4158, 2005.

12. Lloyd S. Understanding certification path construction. PKI Forum, 2002.13. Wahl M, Howes T, Kille S. Lightweight Directory Access Protocol (v3). IETF RFC 2251, 1997.14. Freeman T, Housley R, Malpani A, Cooper D, Polk W. Server-based Certificate Validation Protocol (SCVP).

IETF RFC 5055, 2007.15. Perlines Hormann T, Wrona K, Holtmanns S. Evaluation of certificate validation mechanisms. Computer

Communications 2006; 29(3):291–305.16. Hallam-Baker P, Mysore SH. XML Key Management Specification (XKMS 2.0). W3C Recommendation 2005.

Available at: http://www.w3.org/TR/xkms2 [6 August 2009].17. Papazoglou MP, Traverso P, Dustdar S, Leymann F. Service-oriented computing: state of the art and research

challenges. Computer 2007; 40(11):38–45. DOI: 10.1109/MC.2007.400.18. Nezhad HRM, Benatallah B, Casati F, Toumani F. Web services interoperability specifications. Computer 2006;

39(5):24–32. DOI: 10.1109/MC.2006.181.19. Rivest RL, Shamir A. PayWord and MicroMint: Two simple micropayment schemes. Proceedings of the

International Workshop on Security Protocols (Lecture Notes in Computer Science, vol. 1189). Springer, 1997;69–87. DOI: 10.1007/3-540-62494-5 6.

20. RSA Laboratories. PKCS#7: Cryptographic Message Syntax Standard. An RSA Laboratories Technical Note.Version 1.5, November 1993.

21. Housley R. Cryptographic Message Syntax (CMS). IETF RFC 3852, 2004.22. World Wide Web Consortium (W3C). XML-Signature Syntax and Processing. W3C Recommendation, 2002.23. European Telecommunications Standards Institute (ETSI). Electronic Signatures and Infrastructures (ESI);

Registered Electronic Mail (REM). ETSI Technical Specification (TS) 102 640, 2008.24. ETSI. ESI: Profiles of CMS Advanced Electronic Signatures based on TS 101 733 (CAdES). ETSI TS 102 734,

2007.25. ETSI. ESI: Profiles of XML Advanced Electronic Signatures based on TS 101 903 (XAdES). ETSI TS 102 904,

2007.26. Pinkas D, Housley R. Delegated path validation and delegated path discovery protocol requirements. IETF RFC

3379, 2002.27. Department of Information Security and Electronic Signature, Slovakian National Security Authority. Certificate

Path Validation v1.4, 2006.28. Halappanavar M, Mukkamala R. ECPV: Efficient certificate path validation in public-key infrastructure.

Proceedings of the 17th Annual Working Conference on Data and Application Security (DBSec’03), U.S.A.Kluwer, 2004; 215–228.

29. Berbecaru D, Lioy A. Towards Simplifying PKI Implementation: client-server based validation of public keycertificates. Proceedings of the Second IEEE International Symposium on Signal Processing and InformationTechnology (ISSPIT’02), Marrakesh, Morocco, 2002; 277–282.

30. Kim J, Kim S, Moon K. Design of integration security system using XML security. Proceedings of WorldAcademy of Science, Engineering and Technology (WASET’05), Engineering and Technology, vol. 8(26), 2005;136–140.

31. Barker E, Barker W, Burr W, Polk W, Smid M, Recommendation for key management—Part 1: General (Revised).National Institute of Standards and Technology (NIST) Special Publication 800-57, 2007.

32. Jerman Blazic A, Klobuear T, Jerman BD. Long-term trusted preservation service using service interaction protocoland evidence records. Computer Standard and Interfaces 2007; 29(3):398–412. DOI: 10.1016/j.csi.2006.06.004.



33. Gondrom T, Brandner R, Pordesch U. Evidence Record Syntax (ERS). IETF RFC 4998, 2007.34. Jerman Balzic A, Sylvester P, Wallace C. Long-term Archive Protocol (LTAP). IETF Internet-Draft version 08,

2009.35. Sanchez-Martınez D, Marın-Lopez I, Gomez-Skarmeta AF, Jimenez-Garcıa T. Towards e-Government: The security

SOA approach of the University of Murcia. Third International Conference on Digital Information Management(ICDIM 2008), London, 2008; 813–818.

36. Sanchez-Martınez D, Marın-Lopez I, Jimenez-Garcıa T. Electronic Document Management in the University ofMurcia. European UNiversity Information Systems (EUNIS 2008 Conference), Aarhus, Denmark, 2008. Availableat: http://eunis.dk/papers/

37. OASIS. Digital Signature Service Core Protocols. Elements, and Bindings Version 1.0. OASIS Standard, 2007.38. University of Murcia. SUMA Campus Virtual. Available at: http://suma.um.es/suma/sumav2 [6 August 2009].39. Cantor S, Kemp J, Philpott R, Maler E. Assertions and Protocols for the OASIS Security Assertion Markup

Language (SAML) V2.0. OASIS Standard, 2005.40. Adams C, Cain P, Pinkas D, Zuccherato R. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).

IETF RFC 3161, 2001.41. OpenXKMS. Open Source Implementation of XKMS 2.0. Available at: http://xkms.sourceforge.net [6 August

2009].42. UMU-PKIv6 SCVP API. Public Key Infrastructure with IPv6 support. University of Murcia. Available at:

http://pki.inf.um.es/SCVP/ [6 August 2009].43. XML Trust Services—XKMS, VeriSign Inc. Available at: http://www.verisign.com/developer/xml/xkms.html

[6 August 2009].44. VeriSign’s XKMS Web service. Available at: http://interop-xkms.verisign.com/xkms/Acceptor.nano [6 August

2009].45. Dillaway B. Implementing XML Key Management Services Using ASP.NET. ASP.NET Technical Articles,

Microsoft Corporation, 2002.46. SQLData Systems, Inc. Available at: http://www.sqldata.com [6 August 2009].47. DataPower Technology Corporation. Available at: http://www.dptia.com [6 August 2009].48. TrustFinder XKMS Server. Available at: http://www.ascertia.com [6 August 2009].49. Alcaraz Calero JM, Lopez Millan G, Martınez Perez G, Gomez Skarmeta AF. Towards the homogeneous access

and use of PKI solutions: Design and implementation of a WS-XKMS server. Journal of Systems Architecture2009; 55(4):289–297. DOI: 10.1016/j.sysarc.2008.10.004.

50. XKMS Prototype Server, Wings of Hermes. Available at: http://www.wingsofhermes.org/xkms.html [6 August2009].


an advanced certificate validation service and architecture based on xkms

Documents