Vishal,
I ran accross this when I was doing the checks for the Merlin Interop
examples - which have white space prior to the EncryptedData node, even
when that node is of type "element content". According to the spec (from
section 4.2) :
#####################################
"The decryptor SHOULD support the ability to replace the EncryptedData
element with the decrypted 'element' or element 'content' represented by
the UTF-8 encoded characters. The decryptor is NOT REQUIRED to perform
validation on the result of this replacement operation."
######################################
The key words for me were in the first sentance - "...replace the
EncryptedData element with the decrypted 'element' or element
'content'...".
There is no mention of the parent of the EncryptedData, or any of the
surrounding nodes, so my reading is that the libraries (both the C++ and
Java libraries have this behaviour) are doing the correct thing.
Happy to be corrected if someone can find something else in the spec!
Cheers,
Berin
> Hi All,
>
> I think there is a problem in the decryption process of the XMLCipher
> class. To put the problem across, here's my question:
>
> If there is some whitespace between the tags of EncryptedData and its
> parent (See the example below) and the Type attribute of the
> EncryptedData corresponds to "element content", then the current
> implementation simply replaces the EncryptedData with the decrypted
> DocumentFragment. Shouldn't it first remove the existing contents
> (whitespace, etc) of the parent node of EncryptedData and then do an
> appendChild(DocumentFragment) on the parent?
>
> <CreditCard Limit='5,000' Currency='USD'>
> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
> Type='http://www.w3.org/2001/04/xmlenc#Content'>
> <CipherData>
> <CipherValue>A23B45C56</CipherValue>
> </CipherData>
> </EncryptedData>
> </CreditCard>
>
> If this is accepted as a bug, I even have a patch for it. Should I also
> raise a bugzilla?
>
> Thanks,
> Vishal
