[xmlsec] extended character set encryption/decryption

[Aleksey Sanin]

This parser error doesn't look good. I would report it to libxml2
maintenanerce.

Aleksey

On 4/1/13 3:03 PM, Russell Beall wrote:
> Ok.
> 
> Maybe the code I used to use will still work for this, but when I upgraded the libraries, I had to switch from
> xmlSecEncCtxDecrypt
> to
> xmlSecEncCtxDecryptToBuffer
> 
> This was because decrypting packets like below produces a document error, perhaps within libxml:
> Entity: line 4: parser error : internal error
>       <USCID>5843020612</USCID>
>              ^
> func=xmlSecReplaceNodeBufferAndReturn:file=xmltree.c:line=573:obj=unknown:subj=xmlParse
> InNodeContext:error=5:libxml2 library function failed:Failed to parse content
> func=xmlSecEncCtxDecrypt:file=xmlenc.c:line=648:obj=unknown:subj=xmlSecReplaceNodeBuffe
> r:error=1:xmlsec library function failed:node=EncryptedData
> 
> This happened regardless of extended character sets.
> 
> Previously I would decrypt to a document and then do an xmlDocDumpMemory to get the data.
> 
> Does this ring any kind of a bell?
> 
> Maybe I need to run another upgrade of libxml or libxmlsec?
> 
> Thanks,
> Russ.
> 
> On Apr 1, 2013, at 2:04 PM, Aleksey Sanin <aleksey at aleksey.com>
>  wrote:
> 
>> Yes. I am not exactly sure what was the original behavior but this
>> transformation looks correct to me: c14n does replace the entities.
>>
>> Aleksey
>>
>> On 4/1/13 1:40 PM, Russell Beall wrote:
>>> Looks like I spoke too soon.  What made it appear to work just now was actually a fix that my coworker put in place on the receiving end to re-encode the characters if they showed up unencoded.  The change I made to parse the document differently did not actually maintain the encoding.
>>>
>>> The original request is this:
>>> <?xml version="1.0" encoding="US-ASCII" ?>
>>> <Update>
>>>  <Person>
>>>    <IDs>
>>>      <USCID>5843020612</USCID>
>>>    </IDs>
>>>    <Multi-KIMRole>
>>>      <KIMRole>
>>>        <RoleID>xxx&#xe1;xxx</RoleID>
>>>      </KIMRole>
>>>      <KIMRole>
>>>        <RoleID>xxx&#xf6;xxx</RoleID>
>>>      </KIMRole>
>>>    </Multi-KIMRole>
>>>  </Person>
>>> </Update>
>>>
>>> running xmllint as you specified generates the following, and converts the encoded characters back to original:
>>>
>>> $ xmllint --c14n misctest/unicodedevascii.xml 
>>> <Update>
>>>  <Person>
>>>    <IDs>
>>>      <USCID>5843020612</USCID>
>>>    </IDs>
>>>    <Multi-KIMRole>
>>>      <KIMRole>
>>>        <RoleID>xxxáxxx</RoleID>
>>>      </KIMRole>
>>>      <KIMRole>
>>>        <RoleID>xxxöxxx</RoleID>
>>>      </KIMRole>
>>>    </Multi-KIMRole>
>>>  </Person>
>>> </Update>
>>>
>>> Does this show what you were looking for?
>>>
>>> Thanks,
>>> 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:
>>>
>>>> Can you run your file through "xmllint --c14n"? This will tell us if
>>>> the issue is on libxml2 or xmlsec sides.
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>