Re: AW: Problem in Decryption

[Vishal Mahajan]

Hi Dittmann,

Dittmann Werner wrote:

Vishal, Berin

during some encrypt/decrypt tests with signature:

This is mainly a problem for "content" mode encryption.
AFAIK, during encryption XMLCipher creates a document fragment
with the content, serializes and encrypts it. Decryption
is reverse. After decryption XMLCipher first removes
(or shall remove) all child-nodes of the element e.g. 
CreditCard, then puts in the nodes of the document 
fragment (effectivly restores the original content).

I looked at the code again and  don't think it's happening this way. 
Only a replace child operation is being done (all child nodes are not 
being removed). I am looking at the XMLCipher.decryptElement() method.

Please correct me if I am wrong.

Thanks,

Vishal

Thus, IMHO, there is no problem with Signature/Encrypt.
During our test we already did tests signature/encryption
in content mode.
Regards,
Werner
 

-----Ursprüngliche Nachricht-----
Von: Vishal Mahajan [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 11. Februar 2004 08:35
An: [EMAIL PROTECTED]
Betreff: Re: Problem in Decryption

Hi Berin,

I agree with your reading of the spec. But, the spec does not prevent 
the encrypter from putting whitespaces between the tags of 
EncryptedData 
and its parent node. Also there are example encrypted 
documents like the 
following in the spec:

     <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
      Type='http://www.w3.org/2001/04/xmlenc#Content'>
       <CipherData>
         <CipherValue>A23B45C56</CipherValue>
       </CipherData>
     </EncryptedData>
Other thing to note is that if the document was signed prior to 
encryption, the signature verification would fail. I think this is an 
important interop issue. What do you think?

Thanks,
Vishal
Berin Lautenbach wrote:

   

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