Re: Semantics of xenc:EncryptedData/@Type

On Donnerstag, 3. Januar 2002 17:58 -0500 Joseph Reagle <reagle@w3.org> 
wrote:
> On Thursday 03 January 2002 11:40, Christian Geuer-Pollmann wrote:
>> Do I have have to flag an error if I try to decrypt (or encrypt)
>> xenc:EncryptedData/@Type="&xenc;Content" which has siblings? Or should we
>> specify that @Type="&xenc;Content" only means that the decrypted content
>> is possibly not well-formed (which I would prefer).
>
> I'd argue that since we reference [1] it must merely match that XML BNF
> production which means that siblings are fine though the decrypted
> content  might not be well-formed. This leads me to believe that we
> should add some  text to 4.1.5.1 akin to:
>
> ( Note: If the /+plaintext encrypted is &xenc;Content which has sibling
> elements+/ or the EncryptedData element is used as the root element of a
> new document and its Type is 'content' the plaintext resulting from
> decryption may not be well-formed.)
>
> [1] http://www.w3.org/TR/2000/REC-xml-20001006#NT-content

The reason why I asked is the following: During the Encryption Workshop in 
SFO/2000, I asked whether it's possible to encrypt parts of a 'pure' Text 
Node like this:

<DATA>This contains secret parts</DATA>

<DATA>This contains <xenc:EncryptedData Type="Content" /> parts</DATA>

And the consensus was that this should not be possible (didn't find that in 
the minutes, but I have in mind that I ). It was said that if somethings is 
important enough to be encrypted, it should also be importat enough to have 
it's own markup and then use Element encryption. But the current spec 
allows encrypting parts of a Text Node (and it's very simple to implement 
;-). Additionally, if we want to allow cut-and-paste for protocol scenarios 
where ciphertext from one msg is pasted into another msg, it MUST be 
possible to do something like this.

Christian

Received on Friday, 4 January 2002 04:33:22 UTC