Re: memory leaks

[Julio Sánchez Fernández <j_sanchez@stl.es>]

El mié, 05-12-2001 a las 16:53, Kurt D. Zeilenga escribió:

> I assume OpenSSL (having not looked at the code :-) provides
> the AVA as an OID and a DER encoded value, which we can
> represent in LDAPDN same as if we had read same from a
> RFC 2253 AVA 1.2.3=#DERvalue.

It is not as bad as that.  Look at this fragment from an old apps/ca.c:

        for (i=0; i<X509_NAME_entry_count(name); i++)
                {
                ne= X509_NAME_get_entry(name,i);
                str=X509_NAME_ENTRY_get_data(ne);
                obj=X509_NAME_ENTRY_get_object(ne);

                if (msie_hack)
                        {
                        /* assume all type should be strings */
                        nid=OBJ_obj2nid(ne->object);

                        if (str->type == V_ASN1_UNIVERSALSTRING)
                                ASN1_UNIVERSALSTRING_to_string(str);

                        if ((str->type == V_ASN1_IA5STRING) &&
                                (nid != NID_pkcs9_emailAddress))
                                str->type=V_ASN1_T61STRING;

	[etc.]

The return value from X509_NAME_ENTRY_get_data is an ASN1_STRING.
As can be seen, it contains a type field that contains the ASN1
type (or an interpretation thereof).

So, unless I am mistaken, the choices for directory strings are
well covered. I think this is true for integers and similar
common syntaxes.

Now, of course, the DN can contain attribute types with arbitrarily
bizarre syntaxes.  This are rare, however.

> Figuring how to turn this
> into attribute=escapedUTF8value requires schema, as only
> the schema tells you how to map 1.2.3 to attribute and
> #DERvalue to a value's LDAP string syntax for proper
> 2253 escaping.

I think OpenSSL uses just the ASN1 tag to decide on the value syntax.
I know this is limited. I also think it can work well in practice.

Julio