W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2002

Re: content type decryption clarification?

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Tue, 15 Jan 2002 10:32:53 +0100
To: Takeshi Imamura <IMAMU@jp.ibm.com>
Cc: reagle@w3.org, hirsch@zolera.com, xml-encryption@w3.org
Message-ID: <1773458840.1011090773@clouseau>
Hi Takeshi,

>> Note: If the Type is "content", the plaintext resulting from decryption
>> may not be well formed. This happens if the element whose contents
>> have been encrypted was (a) an element containing more than one
>> child element, or (b) containing non-whitespace text nodes.
>
> That also happens if an element contains only one element but also
> contains character data before the element.
>
> By the way, according to [1], shouldn't we use "well-formed" and
> "character data" instead of "well formed" and "text nodes", respectively?
>
> [1] http://www.w3.org/TR/REC-xml

That case (caracter data) is what I mean by non-whitespace text node (OK, 
non-whitespace character data). Just to illustrate this: If I take the 
following Element, encrypt the contents and make the EncryptedData root of 
a new document. In that case I could decrypt the EncryptedData and replace 
EncryptedData ELement the decrypted contents:



<PlainTextWhoseContentsAreEncrypted><!-- a small comment > <?pi1?>

<onlyASingleElement />

<!-- some more comments and PIs follow here - and only whitespace characted 
data -->

</PlainTextWhoseContentsAreEncrypted>

On the opposite side, If I have something like the following, it'd be no 
possible to make the contents to a new document because it contains not 
exactly one element and it contains non-ws characted data:

<PlainTextWhoseContentsAreEncrypted><!-- a small comment > <?pi1?>

<aSingleElement />

<!-- some more comments and PIs follow here - and only whitespace characted 
data -->
        characters
<aSecondElement />

</PlainTextWhoseContentsAreEncrypted>



Christian
Received on Tuesday, 15 January 2002 04:36:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:07 UTC