ECPV: EFficient Certificate Path Validation in Public-Key Infrastructure [chapter]

M. Halappanavar, R. Mukkamala
2004 IFIP International Federation for Information Processing  
In the current public-key infrastructure (PKI) schemes based on X.509, a relying party must validate a user's certificate as well as the existence of a path from its trust points to the CA of the certificate. The latter part is referred to as certificate path validation. In this paper, we suggest an efficient certificate path validation scheme (ECPV) that employs delegation with efficient computing at relying parties. In particular, in our scheme, a relying party is provided with certificate
more » ... with certificate path validation trees (CPVTs) depending on its trust points and applicable trust policies. This information should enable a relying party to perform certificate path validation locally. The CPVAs can be deployed either as autonomous entities or in a federated mode. We discuss the two major components of ECPV: the data harvester and the data analyzer. Some of the concerns of security, trust, and performance are also discussed. Keywords: Certificate Path Validation Authority (CPVA), certificate path validation trees (CPVT), delegated path discovery (DPD), delegated path validation (DPV), public-key Infrastructure (PKI), security and trust DATA AND APPLICATIONS SECURITY XVII communication is made possible by having a trusted third-party (TTP) in the form of Certification Authority (CA) whom both the parties trust. When a user or subject submits a certificate to a relying party (RP) for a service, the relying party would like to validate the user certificate prior to offering a service. Typically, the validation of a certificate is done in three steps. In the first step, a relying party (RP) builds a chain of trust, also known as certificate chain, starting from the CA that has issued the user's certificate to the CA that RP trusts (also known as a trust point). This step is known as certificate path discovery. Generally, trust between CAs is established by issuing CA-CA cross-certificates. These certificates can also be revoked from time to time. Thus there is a need to confirm the validity of the links in the certificate chain built in step one. The second step conducts the validation, and is referred to as certificate path validation. (The logic for the validation process described above is described in RFC 2459 [9,10] and is based on various parameters specified in certificate policies.) In the third step, the validity of the issued certificate is itself verified with information provided by its CA. In this paper, we are interested in the first two steps of the validation process. Recent research trends in public-key infrastructure favor delegation of authority for certificate path validation to trusted-severs and for path discovery to untrusted-servers. DPV (Delegated Path Validation) and DPD (Delegated Path Discovery) are examples of such protocols [9]. These protocols are still evolving and are described in Internet drafts [8,9]. Simple Certificate Validation Protocol (SCVP) is another delegation protocol that is conceptually similar to DPV and DPD [6]. In this paper, we propose an efficient certificate path validation (ECPV) scheme to overcome the weaknesses in the current path validation protocols. Our scheme is based on one or more certificate path validation authorities (CPVA) that upload RPs with a certificate path validation trees (CPVT). An RP, in turn, can use this locally available tree to validate certificate paths of user certificates. The trees shall be periodically updated by the CPVA. The CPVAs can be implemented either as an autonomous entity working in isolation or organized as a federation to share information. The paper is organized as follows. In section 2, we discuss some of the issues in certificate path validation and current solutions. In section 3, we describe the proposed ECPV scheme for certificate path validation. A more detailed description of the CPVA module is provided in section 4. Two possible options for deployment are discussed in section 5. Section 6 reviews the security, trust, and performance aspects of the proposed scheme. Finally, section 7 summarizes the contributions of the paper and discusses plans for future work.
doi:10.1007/1-4020-8070-0_16 fatcat:a3ei5llwlzawrpk4vdrimbp34a