On Fri, Nov 07, 2008, Siva Jayaraman wrote:
> No response from openssl-users, hence trying the dev alias.
>
> I have a X509_NAME variable which contains something like
> /CN=mycn/OU=myou/O=myo
>
> I want to modify this into
> /CN=mycn/OU=yourou/O=myo
>
> i.e. I want to change the OU from "myou" to "yourou"
> Extracting the different RDNs (CN, OU & O) and recreating a new X509_NAME
> using
> X509_NAME_add_entry with loc as -1 works fine.
>
> However, if I try to modify the existing X509_NAME by deleting the CN
> from it & then
> inserting the modified CN in between the exiting CN & O gives me problems.
> This is what I tried.
> - Get the index of the OU - it was 1.
> - Now called X509_NAME_delete_entry with index 1 - worked fine.
> - Next called X509_NAME_add_entry_by_txt with "yourou" & "OU" & loc as 1.
> - This did insert the modified CN, but it made the OU & O as a
> multivalued RDN instead
> of making the OU as a separate RDN.
> i.e. my X509_NAME becomes /CN=my/OU=yourou+O=myo
> instead of /CN=my/OU=yourou/O=myo
>
> I debugged through the add_entry code & it boiled down to the handling of the
> "set" field in the X509_NAME_ENTRY structure.
>
> This is the structure.
> typedef struct X509_name_entry_st
> {
> ASN1_OBJECT *object;
> ASN1_STRING *value;
> int set;
> int size; /* temp variable */
> } X509_NAME_ENTRY;
>
> Can someone help me understand the set member in this structure.
>
> When you delete a NAME_ENTRY & insert another on that point, the function
> X509_NAME_add_entry doesn't seem to adjust the "set" member
> of the X509_NAME_ENTRY structure like the way I think it should.
>
> Hence the insertion causes the OU we are inserting to be
> treated as a part of the previous field (CN) - i.e. it becomes
> a multi-valued RDN, rather than a new RDN in the NAME.
> This happens because the "set" field of all NAME_ENTRIES
> beyond the insertion point doesn't get incremented - not sure
> if this is a bug in the function or I am misunderstanding something.
>
> I feel this is how the "set" member should be adjusted I think.
> if(loc == -1 or loc == <current size>)
> <don't increment "set" field of any other node>
> else
> <increment "set field" of all nodes beyond insertion point>.
>
> I am referring to the X509_NAME_add_entry function sources in x509name.c
>
> Can someone tell if this is a bug or am I misunderstanding how this is
> supposed
> to work?
This looks like a bug in X509_NAME_add_entry(). If the "set" (that is the
function argument called "set") value is zero it is supposed to create a new
RDN but it treats set >=0 in the same way.
The line:
inc=(set == 0)?1:0;
should be moved so it is before "set" gets clobbered.
The reason this hasn't been spotted so far is that hardly anyone inserts
in the middle or X509_NAME structures.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
