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

Re: Data replacement

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 22 Jan 2002 13:43:16 -0500
Message-Id: <200201221843.NAA00637@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Hi Takeshi,

On Monday 21 January 2002 09:30, Takeshi Imamura wrote:
> What does "data is an 'element' or element 'content'" mean?  To my
> understanding, it means the type of the serialized version of data is
> 'element' or element 'content', but is it right?  If yes, step 5.1:

I argue that data of that type is a sequence of characters matching the BNF 
productions [39/43] from the XML 1.0 specification. This would not mean 
they have to already be serialized in a particular encoding, as the spec 
says, *after* you've identified them as such *then* you "obtain the octets 
by serializing".

> If the Type of the encrypted data is 'element' or element 'content', then
> the encryptor MUST be able to return the EncryptedData element to the
> application. ... The encryptor SHOULD be able to replace the unencrypted
> 'element' or 'content' with the EncryptedData element.
> means the encryptor replaces only the data that is 'element' or element
> 'content'.  However, it is a little limiting because the application may
> want to have the encryptor replace data that is actually an element but
> is not serialized to octets of type 'element'.  So, I think we should
> relax the limitation by allowing the encryptor to replace data as far as
> it is actually an element.  How do you feel?

In this section, steps 4/5 don't speak of the serliazation of 
EncryptData/Key, only of "build the EncryptedType" element. Again, since 
we're based on XML 1.0, this would be a set of XML character but this would 
not preclude an InfoSet item or DOM or node... Is this your question? Does 
this text necessitate the exchange of octets versus a more abstract 
representation? I don't think so. I'd argue (1) it doesn't require octets, 
(2) it can use XML characters, but (3) doesn't preclude other abstractions 
of an element.


Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Tuesday, 22 January 2002 13:43:19 UTC

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