Understanding Certification Path Construction - oasis pki

More documents

Recommendations

Info

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
Figure 3: Key Identifier Chaining IllustrationEqual[Self-Signed Certificate]AKID = W(if present)SKID = WEqual[Intermediate CA Certificate]AKID = WSKID = XEqual[Intermediate CA Certificate]AKID = XSKID = YEqual[End-Entity Certificate]AKID = YSKID = ZAKID/SKID Structure and UseIn accordance with X.509, the AKID can be represented using a keyIdentifier, anauthorityCertIssuer, authoritySerialNumber pair, or both. However, X.509 also states that:The keyIdentifier form can be used to select CA certificates during path construction.The authorityCertIssuer, authoritySerialNumber pair can only be used to providepreference to one certificate over others during path construction.In addition, the Internet Certificate and CRL Profile (see RFC3280) states that the keyIdentifierfield in the AKID must be included in all certificates generated by conforming CAs (with theexception of self-signed certificates, in which case the keyIdentifier would be included withinthe SKID and, optionally, within the AKID). Further, the Internet Certificate and CRL Profilestates that:The keyIdentifier field of the Authority Key Identifier extension MUST be included in allcertificates generated by conforming CAs to facilitate chain building.In accordance with X.509, the SKID can only be represented using the keyIdentifier (i.e., theSKID syntax does not include the authorityCertIssuer, authoritySerialNumber pair). Further,the Internet Certificate and CRL Profile states that all CA certificates must include theSKID extension and:The value of the Subject Key Identifier MUST be the value placed in the key identifier fieldof the Authority Key Identifier extension … of certificates issued by the subject of thiscertificate.Thus, a CA conforming to the Internet Certificate and CRL profile must populate the AKIDof all certificates that it issues with the same keyIdentifier that is populated in the SKID of thecertificate used to verify the digital signature on those issued certificates.The Internet Certificate and CRLProfile states that: thekeyIdentifier field of theAuthority Key Identifier extensionMUST be included in allcertificates generated byconforming CAs to facilitatechain building and the value ofthe Subject Key Identifier MUSTbe the value placed in thekeyIdentifier field of theAuthority Key Identifierextension...of certificates issuedby the subject of this certificate.Calculation of keyIdentifier ValueThere are multiple methods available for calculating the keyIdentifier. The following methodsare specifically mentioned in the Internet Certificate and CRL Profile:• the 20 byte SHA-1 value of the subject public key (not including tag, length, and unused bits)• a four bit value 0100 followed by the least significant 60bits of the SHA-1 value of thesubject public key (not including tag, length, and unused bits)• a monotonically increasing sequence of integersNote that these are recommendations only - the profile does not mandate a particularalgorithm.PKI Forum: Understanding Certification Path Construction: September 2002 5
Page 1 and 2: UnderstandingCertification Path Con
Page 3: Basic Concepts continuedFigure 1: X
Page 7 and 8: This leads us to several conclusion
Page 9 and 10: Building certification paths within
Page 11 and 12: always be possible (e.g., when Vers
Page 13 and 14: (CESG) interoperability initiatives

Understanding Certification Path Construction - oasis pki

Create successful ePaper yourself

Delete template?

Save as template?