> 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]
