<div dir="ltr"><div style="font-size:16px">In fact I did not use any store (thus openssl should be correct). I just tested the logic (openssl verify -CAfile $ca_file $file) and found that it is a little tricky to find the issuer of a certificate (e.g., name/sn-based, key id based), and the behavior is unpredictable.  Sometimes a certificate may have two or more authority key ids (it should be incorrect, but I just produced some certificates to test the logic, and found that the issuer can be found or not found.)<br></div><div style="font-size:16px"><br></div><span style="font-size:16px">Sounds like that the issuer cannot be found because the authority key id of file3.pem does not match with the subject key id of file4.pem. Meanwhile the building strategy is flexible. I also made some certificates contains two or more instances of authority key ids, and the issuer can be found (or sometimes cannot be found).</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 4, 2015 at 2:35 PM, Yuting Chen <span dir="ltr"><<a href="mailto:chenyt@cs.sjtu.edu.cn" target="_blank">chenyt@cs.sjtu.edu.cn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>In fact I did not use any store (thus openssl should be correct). I just tested the logic (openssl verify -CAfile $ca_file $file) and found that it is a little tricky to find the issuer of a certificate (e.g., name/sn-based, key id based), and the behavior is unpredictable.  Sometimes a certificate may have two or more authority key ids (it should be incorrect, but I just produced some certificates to test the logic, and found that the issuer can be found or not found.)</div><div><br></div>Sounds like that the issuer cannot be found because the authority key id of file3.pem does not match with the subject key id of file4.pem. Meanwhile the building strategy is flexible. I also made some certificates contains two or more instances of authority key ids, and the issuer can be found (or sometimes cannot be found).</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 4, 2015 at 1:22 PM, Jeffrey Walton <span dir="ltr"><<a href="mailto:noloader@gmail.com" target="_blank">noloader@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What makes you think it is incorrect to check the Key<br>
> Identifier (where present) before checking a signature<br>
> against a key?<br>
<br>
An X.509 certificate does one thing: it binds a public key to an<br>
identity. In PKI, a public key alone means nothing because trust is<br>
placed in principals or issuers.<br>
<br>
In end entity certificate, you don't need the Issuer DN and AKI<br>
because they are disjoint and uncertified. You need the issuing<br>
certificate with a valid signature. But it would be helpful to find<br>
the issuer's certificate easily.<br>
<br>
If the AKI is missing, wrong or a duplicate, then it just means that<br>
you lost the ability to find an issuing certificate easily.<br>
<br>
OpenSSL could be more flexible or friendly in its building strategy.<br>
But that could move into the "which directory" problem rather quickly.<br>
<br>
If Yuting Chen provided a store with the required certificates, then<br>
OpenSSL is probably incorrect. Chen's original email does not detail<br>
it, so its hard to say at the moment.<br>
<br>
> What other reasonable purpose could the Key Identifier<br>
> fields serve?<br>
<br>
Its a hint to help find the issuing certificate. Its supposed to be<br>
used when an issuer has multiple signing keys.<br>
<br>
The AKI does not need to be a key identifier. It can also be be the {<br>
Issuer DN, Serial Number } pair of the issuer's certificate.<br>
<br>
Jeff<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>