W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

Re: Updated Section 4.1

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 23 Aug 2001 14:35:57 -0400
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Blair Dillaway" <blaird@microsoft.com>
Cc: xml-encryption@w3.org
Message-Id: <20010823183558.18D0087519@policy.w3.org>
[ Resulting document:
  $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:

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."

Received on Thursday, 23 August 2001 14:36:03 UTC

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