Hi, Could someone please confirm the points I mentioned in the previous email? Also wanted to understand on how to identify cross certificates using openSSL. I understand that the AKI checks are not sufficient when cross certificates are present in my certificate chain.
-- Ashok On Mon, Jul 23, 2012 at 2:09 PM, Ashok C <ash....@gmail.com> wrote: > 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.* >> >> >
