Re: Encryption Subset Scenario

If one needs to combine adjacent elements before encrypting so that one ends
up with a single <EncryptedData> element, then one can always use a
transform (eg. XSLT) just before encryption and just after decryption.  Note
that these transforms fall outside the core encryption and decryption
processes and are NOT related to the <Transforms> element in XML Encryption.

Note that the above technique doesn't require elements to be adjacent.  For
example, if one wanted to encrypt all <Age> and <Address> elements in a
document, regardless of their location, into one <EncryptedData> element,
one could do so.

Of course, the critical question is not "can I do this?" but "should I do
this?".   In other words, always ask if using a workaround to get a desired
result is really justified.  I would recommend initially assuming the answer
is NO until proven otherwise.

Ed

----- Original Message -----
From: "Jiandong Guo" <jguo@phaos.com>
To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
Cc: <xml-encryption@w3.org>; "Hammond, Ben" <bhammond@rsasecurity.com>;
<edsimom@xmlsec.com>
Sent: Thursday, May 16, 2002 10:17 AM
Subject: Re: Encryption Subset Scenario


>
>
> "Dournaee, Blake" wrote:
>
> > All -
> >
> > Given an input Document D:
> >
> > <doc>
> >   <elem1> foo1 </elem1>
> >   <elem2> foo2 </elem2>
> >   <elem3> foo3 </elem3>
> > </doc>
> >
> > I want to encrypt just the first two child elements (<elem1> and
<elem2>).
> > This doesn't appear to fit the definition of
> > Type='http://www.w3.org/2001/04/xmlenc#Element', which suggests a single
> > element, or Type='http://www.w3.org/20001/04/xmlenc#Content'
> > which suggests that all three elements must be encrypted (elem1, elem2
and
> > elem3).
> >
> > Choosing to treat the first two elements as arbitrary plaintext also
seems
> > overkill, and if so, this ruins the XML semantics. I cannot
> > treat it as text/xml, because this document subset is not well-formed.
> > Treating it as text/plain looses all of the XML semantics.
> >
> > The obvious solution is to create two <EncryptedData> elements, but this
is
> > redundant. Another solution is an XPath transform, but this
> > doesn't exist for XML Encryption.
> >
> > Am I missing something here? Is there an obvious solution to this? It
seems
> > like a simple case that might have been overlooked.
>
> If you want to encrypt two elements in one EncryptedData, the question is
> that how do you handle the "replace" process in encryption and later in
> decryption,
> considering there could have other nodes (text nodes or other elements)
between
>
> these two elements?
>
> -----------------------------------------
> Jiandong Guo
> Phaos Technology
> www.phaos.com
>
>
>
>
>

Received on Thursday, 16 May 2002 11:19:36 UTC