On Wed, May 17, 2006, Phil Dibowitz wrote: > Dr. Stephen Henson wrote: > > Your problem is that you are telling OpenSSL to include the AKID > > extension by > > copying the SKID from the issuing CA. That CA doesn't have an SKID > > extension > > so it gives the error. > > > > Either remove that extension from the config file or include SKID in the > > root > > CA. > > So as I mentioned previously, I saw a proprietary solution doing this > (generating an AKID keyID without a parent SKID), even though I realized > it made no sense. So I called them on it. I asked how they were getting > a keyID for AKID when the parent CA had no SKID. > > They informed me they're "calculating a hash of the public key of the > parent public key for the AKID"... in other words - they're generating a > SKID for the parent even though it doesn't have one. > > Intuitively, this kinda seems wrong to me, but reading the RFC it seems > to comply. AKID keyId just needs to uniquely identify the parent public > key. I'm curious what your thoughts on this are. Is this a reasonable > thing to do? Are there problems with this? In the case where I have > this, I plan to re-sign the parent to have SKID, but I'll be in this > configuration for a bit before I can do that. Is this AKID bad in any way? >
Well AKID is supposed to be a "hint" to the authority certificate by matching its SKID. If the authority doesn't have an SKID then its a bit misleading. That wont matter to OpenSSL but other software might decide because the authority doesn't have a matching SKID then it isn't the real signer. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
