> To do that properly you do need to at least parse some of the 
> ASN1 data. There
> is some header information at the start which contains the 
> SEQUENCE tag+length
> bytes.

Right.  This isn't a problem, as I've been pulling the data out by
parsing the ASN.1 data anyway.
 
> The actual bit you will hash is in the middle of the data. 
> One SEQUENCE
> header is deleted from the start and some data from the ends. 
> If you parse a
> few tag+length bytes you can work out how much to hash and 
> the position
> and length of the signature.

Actually, I already have the signature.  But what I don't quite grok is
how the signature was generated.

I've been using http://rfc-ref.org/RFC-TEXTS/3280/chapter12.html#sub3 as
a guide to parsing the ASN.1 data.  When I look at that example
(12.3.C.3) I see an encapsulating SEQUENCE that contains a SEQUENCE that
contains all the certificate data, a SEQUENCE that identifies the
signature's hash/encryption algorithm, and then a BIT STRING with the
actual signature.

To generate the signature, has that first embedded SEQUENCE (the one
that contains the certificate data) been hashed entirely?  Including the
tag and length fields?  Or has some subset of that been hashed?  I
assume that the SEQUENCE with the hash/encryption algorithm is omitted
and clearly the signature isn't included.  Is there anything else
omitted?

Thanks for your help,
Anthony.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to