Hi, Thanks a lot for the prompt and clear response - much appreciated.
It turned out that the apparent nested string was caused by a mismatch between the ASN.1 definition in the parser and the actual ASN.1 structure being parsed. Thanks again, Bryn -----Original Message----- From: Dr. Stephen Henson [mailto:[EMAIL PROTECTED] Sent: Thursday, 28 June 2007 1:07 AM To: Williams Bryn-R40716 Cc: openssl-users@openssl.org Subject: Re: Nested ASN1 strings and OPENSSL_ALLOW_NESTED_ASN1_STRINGS On Tue, Jun 26, 2007, Williams Bryn-R40716 wrote: > Hi, > > A team in our organisation has a small ASN.1 decoding example that > works with openssl 0.9.7g, but not with any more recent release. The > reason seems to be that the ASN.1 structure in question includes > (perhaps > wrongly) a nested ASN.1 string, which is no longer supported by default. > > I see from the commit logs that the change to conditionalise this in > tasn_dec.c was made prior to openssl-0.9.7h by Dr. Stephen Henson with > the comment "Don't attempt to parse nested ASN1 strings by default" > (code included below). > > If we recompile openssl (e.g. 0.9.8e) with > OPENSSL_ALLOW_NESTED_ASN1_STRINGS then our example works. However, > given that this has been disabled by default since 2005 I assume that > this is not normally required, annd perhaps should be taken as an > indication that we have a bad ASN.1 structure or are parsing it incorrectly. > > I was hoping someone (Dr Henson...?) could help me to understand why > this change was made, and in what circumstances it's appropriate to > recompile with OPENSSL_ALLOW_NESTED_ASN1_STRINGS. > Well the standards technically allow constructed string types to be nested to arbitrary depth. This is potentially a problem for recursive parsers especially if the stack size is limited. I've never come across an example of such a string except one specifically constructed as an example. I created some pathological cases for an ASN1 testing suite: before the above change they would crash the parser. In some structures (such as certificates) they are illegal anyway. The normal use of constructed strings is for streaming purposes and that can be handled using a single level of nesting: which OpenSSL can process. If the input data comes from a trusted source then it is OK to recompile with OPENSSL_ALLOW_NESTED_ASN1_STRINGS. From an unstrusted source it could be a security hole. I'd be interested to know what kind of structure you have which includes a string with more than one level of nesting. 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]
