Vishal, right, it doesn't remove after decryption, only after encryption (I got confused here).
However, the functionality during decryption is not exactly the same: - decryptElement(element) decrypts _that_ element which must be an EncryptedData element - decryptElementContent(element) first locates a child of _that_ element that is an EncryptedData element. It then calls the decryptElement with this child element. After decryption the plain bytes are serialized into a DocumentFragment. In element mode this DocumentFragment consist of one top-level node (an element in this case) only In content mode the DocumentFragment may consist of several top-level nodes. The replaceChild() does the rest. Pls refer to the DOM documentation how DocumentFragment is handled during replace/append functions. Thus, after all there are some slight, but important differences. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Vishal Mahajan [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 11. Februar 2004 13:31 > An: [EMAIL PROTECTED] > Betreff: Re: AW: AW: Problem in Decryption > > > Dittmann, > > I am in sync with you as far as encryption > (element/element-content) is > concerned. The point I was trying to make was that > decryptElementContent() method does not remove all the child nodes of > the element. It simply replaces the EncryptedData with the decrypted > fragment. Also please note that the behavior of decryptElement() and > decryptElementContent() methods is exactly the same. > > Thanks, > > Vishal > > Dittmann Werner wrote: > > >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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > >
