Hi, I read from the RFC5280 that AKI is mandatory for all certificates generated by a conforming CA. "The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building."
And that Subject Key Identifier is "MUST" for CA certificates but only "SHOULD" for end entity certificates. "For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates". I am going to support only v3 certificates in which the above extensions seem to be MUST(For EE I don't need the SKI to be processed anyways, AKI is sufficient). So the go ahead I would need from the community is whether the AKI/SKI checks are sufficient for chain formation in a v3 PKI or not. -- Ashok On Mon, Jul 23, 2012 at 1:48 PM, Sukalp Bhople <bsuk...@gmail.com> wrote: > Hi Ashok, > > If you have a look at the v3_purp.c, > > You can follow following algorithm: > 1. check issuer name, if okay then proceed or exit. > 2. check akid,.... > 3. check the key usage ... (if the issuer certificate in the chain for a > subject under consideration is allowed to sign or not), > 4. check the path length constraint., and check for proxy certificates. > > As far as understood from openssl source code, it checks the akid only if > it is present in the certificate otherwise it only depends on the subject > name and issuer name match. > > Of course, at the end you need to verify the signature. But thats not the > part of the certificate chain formation. > > > On Mon, Jul 23, 2012 at 10:06 AM, Ashok C <ash....@gmail.com> wrote: > >> Thanks Sukalp, >> >> But I would like confirmation for the algorithm also. >> Whether SKI/AKI related checks are sufficient for the chain formation, or >> if anything else needs to be checked. >> >> -- >> Ashok >> >> >> On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople <bsuk...@gmail.com>wrote: >> >>> Hi, >>> >>> You can have a look at following files from openssl source code. >>> >>> 1. ssl_cert.c (around line number 626) >>> 2. x509_vfy.c (around line number 153) >>> 3. v3_purp.c (around line number 700). >>> >>> good luck! >>> >>> On Mon, Jul 23, 2012 at 8:41 AM, Ashok C <ash....@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I have a requirement to form a correct certificate chain (for a server >>>> application, to send to client). >>>> Currently I was forming the chain using the issuer-id and subject name >>>> combination alone. >>>> Eg: The algorithm followed was: >>>> Let End entity(server certificate) be called as 'E'. Root certificate >>>> as 'R' , and intermediate CA certificate be 'I'. >>>> >>>> >>>> 1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >>>> 2. Search trust store for CA certificate which has this 'C=IN' as >>>> subject name and add it to chain. This is "I". Chain at this step: "E-I" >>>> 3. Look at issuer-id of I and search trust store which has it as >>>> subject-name. In this case I will find 'R'. Since for 'R' issuer-id and >>>> subject-name are same, this is considered to be root and hence not >>>> added to >>>> chain. >>>> >>>> But, I find that this chain is not conclusive enough, as >>>> subject-name==issuer-id is not a complete criteria for a root certificate >>>> and also that "I" cannot be treated as issuer of "E" just because of the >>>> success of the issuer-id/subject-name checks. >>>> I read the openSSL verify man page and understood that checks related >>>> to authority key identifier and subject key identifier are required to >>>> decide upon the correct chain. >>>> >>>> So I presume that the logic should be modified to look something like >>>> this: >>>> >>>> >>>> 1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >>>> 2. Search trust store for CA certificate which has this 'C=IN' as >>>> subject name. This is "I". Check if authority key identifier of "E" is >>>> the >>>> same as the subject key identifier of "I". If this is true, add it to >>>> chain. Chain at this step: "E-I" >>>> 3. Look at issuer-id of I and search trust store which has it as >>>> subject-name. In this case I will find 'R'. Check if authority key >>>> identifier of "I" is the same as the subject key identifier of "R". 'R' >>>> can >>>> be concluded as the root only if subject-name==issuer-id and >>>> authority-key-identifier==subject-key-identifier. >>>> >>>> Is this solution complete for a multi-level hierarchy? As of now, I do >>>> not have to deal with cross-certification, though I am very interested to >>>> know from you guys on the complications involved when that comes into the >>>> picture. I understand there is RFC 4158 explaining this path formation, but >>>> was wondering that needs to be read in detail only for the >>>> cross-certification related parts. >>>> >>>> Does openSSL have any sample implementation somewhere for this path >>>> formation(subject-key/authority-key checks) which I could use for >>>> reference? >>>> Thanks in advance. >>>> >>>> Regards, >>>> Ashok >>>> >>>> >>> >>> >>> -- >>> Regards, >>> *Sukalp Bhople.* >>> >>> >> > > > -- > Regards, > *Sukalp Bhople.* > >
