Sven Heiberg wrote:
>
> Hi!
>
> I'm not sure whether all topics touched describe bugs or not. At least
> these are things which seem unnatural to me. Thank you in advance for your
> attention and patience.
>
> Sven Heiberg
>
> -------------------------------------------------------------
>
> 1. Problem with i2d_ASN1_OBJECT
>
> My code:
>
[code deleted]
>
> Problem is that length_before and length_after differ by 2. This does not
> seem to be normal behaviour and causes trouble when i'm using length_after
> to save DER encoded ASN1_OBJECT.
>
Agreed. Its fixed now.
> 2. Problem with ASN1_INTEGER_to_BN
>
> In OpenSSL there is following code:
>
> BIGNUM *ASN1_INTEGER_to_BN(ASN1_INTEGER *ai, BIGNUM *bn)
> {
> BIGNUM *ret;
>
> if ((ret=BN_bin2bn(ai->data,ai->length,bn)) == NULL)
> ASN1err(ASN1_F_ASN1_INTEGER_TO_BN,ASN1_R_BN_LIB);
> if(ai->type == V_ASN1_NEG_INTEGER) bn->neg = 1;
> return(ret);
> }
>
> I wonder what will happen if I write my code like this:
>
> BIGNUM *mybig = NULL;
>
> mybig = ASN1_INTEGER_to_BN(some_previously_defined_int, mybig);
>
> In my opinion everything will be fine up to the point where BN_bin2bn
> fails. Now if (BN_bin2bn returns NULL) AND (some_previously_defined_int
> happens to be negative) then SIGSEGV is on the fly. Am I right?
>
Yes that is a typo. It should change 'ret' instead of 'bn'.
> Also note that ASN1_INTEGER_to_BN and BN_to_ASN1_INTEGER do not check
> whether their first argument is NULL or not. Is this intended behaviour?
>
Well not everything checks the arguments passed to it. A few cases like
the *_free() functions are guaranteed to tolerate a NULL pointer, others
aren't.
>
> 3. Problem with i2d_PKCS and d2i_PKCS
>
> If i read rfc2630 and rfc2315 then i notice that one can define other
> contentTypes for CMS data instead of data, signed-data, enveloped-data ...
> which are defined in rfc2630. Now i defined my own OID and tried to use it
> with PKCS. It doesn't work 'cause if PKCS doesn't recognize the OID used
> the attatched data will not be saved. Why is it not possible to do
> following:
>
> if OpenSSL recognizes the data type encapsulated in PKCS then the data
> will be interpreted. If OpenSSL doesn't recognize the data type it is
> handled so as if it was arbitrary der-encoded byte array there? (This
> means it's also saved and loaded during i2d and d2i functions).
>
That's CMS. OpenSSL implements PKCS#7 v1.5 which is much earlier. The
PKCS#7 code is likely to choke on several CMS constructs if they are
present.
This may be fixed as part of the ASN1 revision. This should make it
easier to add custom content types.
However since that is some time away I can add support for placing
unknown content types in an ASN1_TYPE structure for now.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
