Also adding openSSL community into loop. Thanks Dave. But main use case for me is the trust anchor update case. I have a certain requirement which goes like this: I have a client application which runs on my machine and it will attempt to connect to multiple remote servers. *At time T0:* Client has old root. All servers have old end entity, connection goes fine. *At time T1:* Trust anchor updates itself and my client gets hold of the new root. But at the same time it will not delete the old root since some servers would not yet have procured the new end entity from the new root. At this time, both roots would be present in my trust store. And I will need to form the right certificate chain for a display command which should display: new EE-->new root. And not new EE-->old root. For this, I would need the AKI/SKI related checks. Since the issuer-id subject-name fields of both old as well as new root would be same.
And regarding the "some even don't have AKI/SKI", I read the RFC and it mandates the presence of these extensions in all conforming CAs. -- Ashok On Fri, Jul 27, 2012 at 4:18 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > ** > I'm not certain that actually works as described. > > I see the checks in crypto/x509/x509_vfy.c and crypto/x509v3/v3_purp.c, > but the 'search for parent' part has multiple options spread over several > sourcefiles -- > the standard ways are to look in a file commonly designated CAfile and/or > a directory commonly designated CApath, but there are several ways to > extend this. > There are comments on x509_lu.c _get1_issuer, but I'm not sure if/when > they apply. > > It has never been an issue for me, because all the CAs I've seen > have distinct DN's for each cert they issue, i.e. they never need > to disambiguate using AKI/SKI. And some don't even *have* AKI/SKI. > > Good luck. > > ------------------------------ > *From:* Ashok C [mailto:ash....@gmail.com] > *Sent:* Thursday, 26 July, 2012 02:08 > *To:* Dave Thompson > *Subject:* Fwd: Forming the correct chain for an end entity certificate > Reg. > > Hi Dave, > > Could you please help me on this? > > -- > Ashok > > ---------- Forwarded message ---------- > From: Ashok C <ash....@gmail.com> > Date: Mon, Jul 23, 2012 at 12:11 PM > Subject: Forming the correct chain for an end entity certificate Reg. > To: openssl-users@openssl.org > > > 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 > > >
