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). 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 > >> > >> > > > > > > > > > > > > >
