Understanding Certification Path Construction - oasis pki

Figure 2: Name Chaining IllustrationEqual[Self-Signed Certificate]Issuer = CA0Subject = CA0Equal[Intermediate CA Certificate]Issuer = CA0Subject = CA1Name chaining alone may not besufficient to determine if the certificationpath is a legitimate candidatethat should be submitted to the certificationpath validation process.Issuer = CA1EqualSubject = CA2[Intermediate CA Certificate]Equal[End-Entity Certificate]Issuer = CA2Subject = User1Although we will discuss this in more detail later, let's quickly review how a certification pathcan be constructed using name chaining. (In order to keep things simple, it is assumed that theIssuer DN's match the corresponding directory entries associated with each CA.) Whenbuilding certification paths in the forward direction, we can use the Issuer DN in the end-entitycertificate to retrieve the certificate(s) that have been issued to the CA that issued the end-entitycertificate. As illustrated in Figure 2, Issuer=CA2 in the end-entity certificate will lead to CA2'scertificate. Once we have retrieved CA2's certificate, we can use the Issuer DN in CA2'scertificate to retrieve CA1's certificate. Finally, the Issuer DN in CA1's certificate leads us toCA0's certificate. The same logic applies when we build certification paths in the reversedirection (with the order reversed, of course). This is discussed in more detail later.AKIDs are used to distinguish onepublic key from another when agiven Certification Authority (CA) hasmultiple signing keys, and SKIDsprovide a means to identify certificatesthat contain a specific publickey.If Certification Authorities (CAs) were guaranteed to have only one public/private signing keypair active at any given time, satisfying the name chaining requirement would be all that isrequired to construct a candidate certification path. However, it is possible (even likely) thatCAs will have more than one valid signing key pair at the same time (e.g., to support CA keyrollover). This means that name chaining alone may not be sufficient to determine if thecertification path is a legitimate candidate that should be submitted to the certification pathvalidation process. This leads us to the notion of "key identifier chaining" as discussed below.Key Identifier ChainingThe Authority Key Identifier (AKID) and Subject Key Identifier (SKID) are certificate extensionsthat can be used to help facilitate the certification path construction process. As discussedin X.509 and the Internet Certificate and CRL Profile (RFC3280), AKIDs are used todistinguish one public key from another when a given Certification Authority (CA) has multiplesigning keys, and SKIDs provide a means to identify certificates that contain a specificpublic key. 4Similar to "name chaining" between a trust anchor and an end-entity certificate, the SKID ofthe first certificate should be the AKID of the next certificate in the path, and so on. Figure 3helps to illustrate this concept. Note that since the AKID and SKID are certificate extensions,the concept of key identifier chaining applies only to Version 3 public key certificates.4The reader may be interested in a recently published PKI Forum Implementation Guideline regardingAKIDs/SKIDs in the context of cross-certification. This guideline can be found at http://www.pkiforum.org/resources.html.4PKI Forum: Understanding Certification Path Construction: September 2002 PKI Forum: Understanding Certification 4Path Construction: September 2002