[xmlsec] extended character set encryption/decryption

[Russell Beall]

Actually, some luck just now helped me find some options on the usage of libxml, and I found that the initial method of parsing the xml before encrypting changes the resulting packet of xml at the destination, so this appears to be only related to libxml and isn't related to libxmlsec.

And, yes, parsing while requiring US-ASCII broke things, but setting UTF-8 caused the encoding style to change, but it remained encoded through the process and worked at the other end.

Thanks for bearing with us users who have fuzzy lines of understanding between the two libraries :-)

Regards,
Russ.

==============================
Russell Beall
Systems Programmer IV
Enterprise Identity Management
University of Southern California
beall at usc.edu
==============================






On Apr 1, 2013, at 11:34 AM, Aleksey Sanin <aleksey at aleksey.com> wrote:

> Hi Russell,
> 
> Can you run your file through "xmllint --c14n"? This will tell us if
> the issue is on libxml2 or xmlsec sides.
> 
> In general, you probably want to generate your xml files in utf8 and
> specify utf8 as your encoding.
> 
> 
> 
> Aleksey
> 
> On 4/1/13 11:12 AM, Russell Beall wrote:
>> Hello,
>> 
>> I have a question about how to work with this library when dealing with
>> extended characters.
>> 
>> I recently upgraded from old versions of libxml and libxmlsec.  
>> libxml 2.6.9 --> 2.7.7
>> libxmlsec 1.2.5 --> 1.2.16
>> 
>> We are using a fairly boilerplate copy of the recipe for encrypting the
>> xml and then decrypting it on the other end of the communication line.
>> The old version of these libraries would refrain from converting the
>> XML encoding of characters.  The new version of these libraries seems to
>> be translating these encodings back to their wide character format, and
>> this then crashes the system.
>> 
>> What I would like to do, is figure out which API flag can be used to
>> retain the encoding.  Possibly I also need to switch to wchar buffers or
>> something else, because calling free on the regular buffer seems to
>> corrupt memory.
>> 
>> For instance, if a section of the XML has this:
>>        <RoleID>á</RoleID>
>> 
>> before going into xmlsec it gets translated into this by a perl function:
>>        <RoleID>&#xe1;</RoleID>
>> 
>> At the top of the xml block, I tried specifying an encoding of
>> "US-ASCII" and I was hoping this would keep the libraries from
>> converting it back.  I need the encoding to stay in place because it
>> needs to be converted only at the final destination code.  I tried also
>> setting "US-ASCII" as the encoding value on the call to
>> xmlSecTmplEncDataCreate, but no matter what value I set on that field,
>> even an invalid one, it doesn't seem to change the behavior.
>> 
>> I'm hoping someone on this list can help me with a clue to point me in
>> the right direction.
>> 
>> It would also be very good to get a pointer to the documentation that
>> specifies how to set a value for the xmlChar options, and what options
>> are accepted.  I searched through lots of documentation at:
>> http://www.aleksey.com/xmlsec/api/
>> 
>> and found no reference on how to configure those options, just that they
>> existed and expected some value in an xmlChar.
>> 
>> Thanks!
>> Russ.
>> 
>> 
>> ==============================
>> Russell Beall
>> Systems Programmer IV
>> Enterprise Identity Management
>> University of Southern California
>> beall at usc.edu <mailto:beall at usc.edu>
>> ==============================
>> 
>> 
>> 
>> 
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>> 
>