Op 11 May 2012, om 00:48 heeft Dr. Stephen Henson het volgende geschreven:
> On Thu, May 10, 2012, Dirk-Willem van Gulik wrote: > >> >> On 10 mei 2012, at 18:59, "Dr. Stephen Henson" <st...@openssl.org> wrote: >> >> >> Nets me >> >> 365:d=7 hl=2 l= 3 prim: OCTET STRING [HEX DUMP]:020164 >> >> which looks close (02 type == integer, 01 length, number 100) -- but is >> obviously not right as it is seen as an octed string still. >> >> Where am I going wrong this time ?! :) >> > > That's how all extensions are encoded: an structure with an OCTET STRING > wrapper. If you want so see the contents use -strparse 365 to the asn1parse > utility. Ah lovely. I had na-ively assumed/hoped that there was something which would trigger/understand that an v3 extension (am I correct in understanding that they always are to be an OCTED STRING) would kick in and decode it when it would contain an ANS.1 sequence it could recognize. Why is it that these extensions are OCTED STRINGS ? Is it intentional that the value of an extention cannot be an arbitrary ASN.1 sequence itself; but has to be wrapped. Or more a historic accident ? Thanks, Dw.______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
