RE: Updated Section 4.1

If we relax what is being returned in encryption, we should also relax that
in decryption.  That is, the Decryptor must be able to return a UTF-8
encoded XML, but it may return an XML represented in another way, depending
on the application's choice.

As for non-validation by the Encryptor, I withdraw my suggestion because of
the consistency with the processing for data of any other type, where the
data is not also validated by the Encryptor (i.e., applications are
responsible for encoding data validly).

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com



From: "Blair Dillaway" <blaird@microsoft.com> on 2001/08/24 03:44

Please respond to "Blair Dillaway" <blaird@microsoft.com>

To:   <reagle@w3.org>, Takeshi Imamura/Japan/IBM@IBMJP
cc:   <xml-encryption@w3.org>
Subject:  RE: Updated Section 4.1



Re:  Why must we return the UTF-8 encoding of this element? This
precludes
returning, for example, a DOM structure. I would remove "the UTF-8
encoding
of" and "UTF-8 encoded", so toolkits can operate as they desire.

It doesn't really affect interop, except across toolkits.  It should be
OK just to state that the implementation returns the EncryptedData
element in a manner they define.  For consistency the same wording needs
to be used when describing how EncryptedKey is returned.

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
Sent: Thursday, August 23, 2001 11:36 AM
To: Takeshi Imamura; Blair Dillaway
Cc: xml-encryption@w3.org
Subject: Re: Updated Section 4.1


[ Resulting document:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
  $Revision: 1.38 $ on $Date: 2001/08/23 18:31:43 $
]

You and Blair noted some similar things in things I dropped either
purposefully (but without providing an adequate replacement) or
accidently.

On Thursday 23 August 2001 03:20, Takeshi Imamura wrote:
> In Section 4.1, step 3.1, a sentence like the following should be
> added: "The Encryptor is not required to perform validation on the
> serialized XML."

I agree, but I don't understand why we would say this? If you have a
Element
or Element Content in XML, you already have chartercters, if it's a DOM
node,
we're saying serialize it. Why would you serialize XML and then be
required
to reparse and validate it?

> In Section 4.1, step 4, it is described only how to build the
> EncryptedData element.  It should be also described how to build the
> EncryptedKey element.

Yes, from Blair's text I was trying to focus on using ds:KeyInfo to
transport
the key, and one of the ways one might do that is with EncryptedKey.
I've
now generalized step 4 of Encryption to work on elements derived from
EncryptedType (as I tried to do in decryption.)

> In Section 4.1, step 5.1, it should be noted that re-encoding may be
> required when replacing the identified XML with the EncryptedData
> element.

I was wondering the same thing Merlin was:

http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0044.html
Why must we return the UTF-8 encoding of this element? This precludes
returning, for example, a DOM structure. I would remove "the UTF-8
encoding
of" and "UTF-8 encoded", so toolkits can operate as they desire.


> In Section 4.2, step 4.3, a sentence like the following should be
> added: "The application supplies the XML Document context and
> identifies the EncryptedData element being replaced."

Ok.

Received on Friday, 24 August 2001 01:27:37 UTC