RE: Section 4.1 and 4.2 proposal

Blair,

The validation on whether a decrypted XML becomes valid or not can be done
not only by a Decryptor but by an Encryptor.  But anyway, if we worry about
such validity, we may have to move from octet-based processing to
infoset-based or nodeset-based processing, where we don't have to worry
about it...

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



From: "Blair Dillaway" <blaird@microsoft.com> on 2001/08/10 06:16 AM

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

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



My only concern with your wording is that it leaves out a description of
what the XML source string represents for Element or Content types.  By
implication, a Decryptor is only reponsible for doing the replacement
without concern for whether the transform produces valid XML.  I think
there will be an expectation that the Decryptor will do some validation
and throw an exception on errors when doing this procesisng.  For
example, I would expect an error when processing an Element type when
the XML source has multiple top-level sibling elements or when
processing any mal-formed XML source.

I can go along with your proposed wording if others believe its either
(1) unnecessary to make explicit the required 'shape' of the XML source
for Element and Content types or (2) that any validation prior to
replacement is not the Decryptor's responsibility.  This latter
assumption may be OK since the parser and/or app are going to detect bad
XML if they try to do anything with it.

Blair

-----Original Message-----
From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com]
Sent: Thursday, August 09, 2001 9:28 AM
To: Blair Dillaway
Cc: edsimon@xmlsec.com; Joseph M. Reagle Jr.; XML Encryption WG
Subject: 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 Friday, 10 August 2001 01:57:33 UTC