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]