Vishal, that depeneds: if you encrypt/decrypt in Element mode then it is correct. If you encrypt/decrypt in Content mode then the methods are: encryptElementContent(...) decryptElementContent(...)
As you can see in encryptElementContent, it constructs a DocumentFragment that contains _all_ child nodes (including text nodes, other element nodes, PI nodes, comment node,...) of an Element node if the _contents_ of that Element node shall be encrypted. Element mode just takes the Element node and performs encryption of that node. IMO this is as defined in XML-Enc specs. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Vishal Mahajan [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 11. Februar 2004 12:33 > An: [EMAIL PROTECTED] > Betreff: Re: AW: Problem in Decryption > > > 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 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > >
