RE: Section 4.1 and 4.2 proposal

Blair,

I see what you intend, but I still prefer the octet-based processing, like
your text for encryption.  The text would be as follows:

"The Decryptor may support the ability to replace the EncryptedData element
with the decrypted Element or Content XML (RECOMMENDED).  In this case, the
application must supply an XML document context and a reference to the
EncryptedData element.  The Decryptor will remove the EncryptedData element
and insert the decrypted XML in its place.  This may require encoding the
UTF-8 encoded XML into the character encoding used by the supplied document
context."

While the processing rule is defined as the above, the implementation can
be done in any way as far as the result is the same from the application's
point of view.  For example, for a DOM-based implementation, it is
sufficient to provide exactly the same DOM tree as the one which is created
by parsing the resulting XML document (i.e., the XML document where the
EncryptedData element is replaced with the decrypted XML).

What do you think?

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



From: "Blair Dillaway" <blaird@microsoft.com> on 2001/08/09 00:59

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

To:   <edsimon@xmlsec.com>, Takeshi Imamura/Japan/IBM@IBMJP
cc:   "Joseph M. Reagle Jr." <reagle@w3.org>, "XML Encryption WG"
      <xml-encryption@w3.org>
Subject:  RE: Section 4.1 and 4.2 proposal



Ed,

Your text captures my intent and I'm happy to go with this
wording.

Takeshi, does this address your concerns?

Blair

> -----Original Message-----
> From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
> Sent: Wednesday, August 08, 2001 5:17 AM
> To: Takeshi Imamura; Blair Dillaway
> Cc: Joseph M. Reagle Jr.; XML Encryption WG
> Subject: Re: Section 4.1 and 4.2 proposal
>
>
> Blair, I agree that your text looks great.
>
> Regarding Takeshi's comment on step 4 of decryption, perhaps
> the text would be clearer if it was slightly reordered like this:
>
> <new>
> c. The Decryptor may support the ability to replace the
> EncryptedData element with the decrypted Element or Content
> XML (RECOMMENDED). In this case, the Decryptor does the
> following steps:
>
> 1. Convert the XML source string to the character encoding of
> the containing XML document (not necessary, of course, if the
> containing
> document is encoded in UTF-8).
>
> 2. Parse the XML source string to obtain a node list.
>
> 3. If the Type was Element, the node list will have exactly
> one top-level Element.  Replace the EncryptedData element
> with the decrypted Element.
>
>    If the Type was Content, the node list may have one or
> more top-level nodes including CDATA, Element,
> ProcessingInstructions, and Comment nodes.  In this case
> remove the EncryptedData element and insert the nodes in the
> decrypted node list as children of the EncryptedData's parent
> element. </new> Ed
>
>
> >
> >>    4.  Decrypting data whose Type is [XML <> ] Element
> >><http://www.w3.org/TR/2000/REC-xml-20001006>  or [XML <> ] element
> >>Content <http://www.w3.org/TR/2000/REC-xml-20001006>
> >>...
> >>         c. The Decryptor may support the ability to replace the
> >>EncryptedData element with the decrypted Element or Content XML
> >>(RECOMMENDED). In this case, the Decryptor parses the XML source
> >>string to obtain a NodeList.  If the Type was Element, this
> will have
> >>exactly one top-level Element which replaces the EncryptedData
> >>element.  If the Type was Content, the NodeList may have
> one or more
> >>top-level nodes including CDATA, Element,
> ProcessingInstructions, and
> >>Comment nodes.
> In
> >>this case the EncryptedData element is removed and the nodes in the
> >>NodeList inserted as children of the EncryptedData's parent
> element.
> >>When replacing the EncryptedData elements, it may be necessary to
> >>transform the encoding of the inserted nodes from UTF-8 to the
> >>character encoding of the containing XML Document.
> >
> >Sorry, I don't follow this step.  It seems node-based and
> octet-based
> >processings are mixed up.  Which processing do you intend?
> >
>
> --------------------------------------------------------------
> ---------------------------------
> Ed Simon
> XMLsec Inc.
>
> Interested in XML Security Training and Consulting services?
> Visit "www.xmlsec.com".
>
>
>

Received on Thursday, 9 August 2001 12:28:39 UTC