Ben Laurie wrote:
>
> Oscar Jacobsson wrote:
> >
> > Hi all!
> >
> > From what I've managed to comprehend of draft-ietf-pkix-ipki-part1 my
> > v2 CRL needs an AuthorityKeyIdentifier. Quoting paragraph 4.2.1.2:
> >
> > (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
> > value of the BIT STRING subjectPublicKey (excluding the tag,
> > length, and number of unused bits).
> >
> > Seeing as cert_info->key->public_key is an ASN1_BIT_STRING, am I
> > correct in assuming that I should hash public_key->length bytes of
> > public_key->data in order to get my AuthorityKeyIdentifier?
>
> I'm not absolutely sure without reviewing source, but I'd guess you have
> to omit the first byte, and the number of bits specified in it from the
> last byte (if you see what I mean) - but the SHA1 functions don't appear
> to operate at the bit level, so if that is anything other than zero, you
> are probably going to have a problem.
>
There are two different kinds of BIT STRING. The usual form which is a
bit string is not allowed to contain trailing zero bits in its DER
incarnation. Hardly anyone pays any attention to this: lots of
certificates include trailing zeros in such extensions as
netscape-certificate-type and keyUsage. I think OpenSSL gets it right
now though...
The other (kludge) form is as a wrapper for something else. In this
incarnation it *is* allowed to contain trailing zero bits and bytes.
This form is used for certificate and CRL public keys and signatures
among other things. If trailing zeros are deleted from these forms then
it could break the signature or structure. This form will never have any
unused bits so there is no problem hashing its contents.
<That reminds me I must check OpenSSL does this properly: I think it
stuffs up public keys>
> Is there a sample in the draft?
>
There is and it doesn't include the extension :-)
Anyway to answer the original question I believe you should hash
public_key->length bytes of public_key->data.
Having said that I haven't seen any CRLs that include this extension
and almost nothing currently uses it.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
