Understanding Path construction-af - PKI

1 Public Key Infrastructure (PKI) supports a number of security-related services, includingdata confidentiality, data integrity, and end-entity authentication. Fundamentally, theseservices are based on the proper use of public/private key pairs. The public component ofthis key pair is issued in the form of a public key certificate and, in association with theappropriate algorithm(s), it may be used to verify a digital signature, encrypt data, a certificate can be used, it must be validated. In order to validate such a certificate,a chain of certificates or a certification path between the certificate and an establishedpoint of trust must be established, and every certificate within that path must be process is referred to as certification path general, certification path processing consists of two phases: 1) path construction and2) path validation described as follows:1) path construction involves "building" one or more candidate certification paths.

2 Notethat we use "candidate" here to indicate that although the certificates may chaintogether properly, the path itself may not be valid for other reasons such as pathlength, name, or certificate policy ) path validation includes making sure that each certificate in the path is within itsestablished validity period, has not been revoked, has integrity, et cetera; and anyconstraints levied on part or all of the certification path are honored ( , path lengthconstraints, name constraints, policy constraints). However, some aspects that mightbe associated with path validation are sometimes taken into consideration during thepath construction process in order to maximize the chances of finding an acceptablecertification path sooner rather than later.

3 We will revisit these concepts later in should be recognized that there are several reasons that separate key pairs should be used fordigital signature and confidentiality, including differing requirements associated with key backup/recovery and long-term handling of keying material, and the ability to use different algorithms foreach ( , DSA could be used for the digital signature and RSA could be used for symmetric keyexchange).2 This is sometimes called "certificate path processing." We use "certification path processing" inorder to maintain consistency with the terminology found in path ConstructionThis White Paper is adeliverable from the PKIF orum s Technical Group(TWG). Several memberorganizations and individualshave contributed by providingcontent, editorial assistance andeditorial :Steve LloydPKI ForumContributors:Andrew NashRuss HousleyJohn LinnMagnus NystromRSA SecurityHelen MullengerBaltimore TechnologiesJeff StapletonKPMG LLPA cknowledgementsSeptember 2002 Certification path construction is a complex process and is subject to somedegree of trial and error.

4 The certification path construction process hasnot been standardized, and there is very little published informationavailable to help implementers and product evaluators understand thecomplexities involved. The purpose of this white paper is to clarify issuesassociated with the certification path construction process and to makerecommendations where , Scope andAssumptions2 Basic Concepts2 Identifying AppropriateCertificates6 Constructing CertificationPaths8 Evaluating CertificatePaths During the PathConstruction Process12 Summary14 References14 ContentsPKI Forum: Understanding Certification path construction : September 20022 The purpose of this paper is toclarify terminology and review is-sues associated with the certifica-tion path construction process andto make recommendations paper focuses on Version 3public key certificates as definedin the 4th Edition of the Rec-ommendation [Ref1].

5 We con-centrate on Version 3 public keycertificates since they are the mostcommon form of certificate foundin most enterprise and govern-ment deployments, and many ofthe extensions that are only sup-ported with Version 3 are essen-tial in order to control business re-lationships within and across Forum: Understanding Certification path construction : September 2002 The 4th Edition of [Ref1] and the Internet Certificate and Certificate Revocation ListProfile as defined in RFC3280 [Ref2] provide the most recent implementation guidelines forcertification path validation. However, both sources are silent when it comes to the certifica-tion path construction In fact, there is very little published literature that addressesthe certification path construction issue.

6 Notable exceptions include [Ref3] and [Ref4].The path construction process can be complex and subject to some degree of trial and error,and there is very little existing literature that discusses issues associated with the certificationpath construction process. Therefore, the purpose of this paper is to clarify terminology andreview issues associated with the certification path construction process and to make recom-mendations where appropriate. However, this paper is not meant to dictate how vendorsMUST perform path construction , nor are we attempting to describe a complete path con-struction algorithm. Vendors are free to implement their own path construction logic as theysee fit. Nonetheless, this paper provides useful information that should be taken into consid-eration when evaluating or implementing certification path construction this paper discusses issues related to certification path validation, it is not thepurpose of this paper to address certification path validation per se.

7 The 4th Edition of RFC3280 should be consulted for additional information regarding the certification pathvalidation paper focuses on Version 3 public key certificates as defined in the 4th Edition of Recommendation [Ref1]. We recognize that other forms of certificates exist, includingthe Version 1 and Version 2 public key certificates defined in previous Editions of , we concentrate on Version 3 public key certificates since they are the most commonform of certificate found in most enterprise and government deployments, and many of theextensions that are only supported with Version 3 are essential in order to control businessrelationships within and across PKI domains. This paper discusses certain Version 3 certifi-cate extensions that can be used to help facilitate the certification path construction should be noted that any discussion associated with these extensions is not applicable in thecontext of Version 1 or Version 2 public key is recognized that path construction software can be implemented locally ( , coupled with theclient system), remotely ( , delegated to an external trusted 3rd party), or a combination of , where path construction is performed is irrelevant for the purposes of this basic structure of the Version 3 public key certificate is illustrated in Figure 1.

8 Certificatesare issued by Certification Authorities (CAs) to other CAs or to end-entities ( , end-users,devices, Web servers, processes). CAs may also "self-issue" certificates to themselves (this isdiscussed in more detail later).Certificates issued to CAs are known as CA certificates, and certificates issued to end-entitiesare referred to as end-entity certificates. The Basic Constraints certificate extension is used todistinguish between CA certificates and end-entity 4th Edition of defines a relying party as "a user or agent that relies on the data in acertificate in making decisions." Stated another way, a relying party "uses" end-entity certifi-cates for some express purpose. For example, a relying party may authenticate a messageoriginator and verify the integrity of the message by "using" the message originator's corre-sponding certificate to verify a digital signature associated with the message.

9 A trust anchoris a CA certificate (or more precisely, the public verification key of a CA) used by a relyingparty as the starting point for path validation (which may or may not be the same startingpoint for path construction as discussed further below). A relying party may have one ormore trust anchors, and these trust anchors can be derived from a number of sources. Forexample, a trust anchor may be the public key of a root CA or it may be the public key of theCA that issues one or more certificates directly to the relying Concepts3 This is simply a statement of fact and is not intended to be a criticism. It is generally agreed within theindustry that path construction algorithms should not be subject to standardization.

10 The purpose ofthis paper is to shed light on path construction issues that are not immediately obvious from the , Scope and AssumptionsPKI Forum: Understanding Certification path construction : September 20023A certificate that one CA issues toanother CA is referred to as a cross-certificate. Cross-certification can beunilateral or certificate that one CA issues to another CA is referred to as a cross-certificate. Asuperior CA may issue a cross-certificate to a subordinate CA as commonly found inhierarchical trust models. This is referred to as unidirectional or unilateral cross-certifi-cation. When CAs issue certificates to each other it is known as mutual or bilateral cross-certification.