Re: Section 4.1 and 4.2 proposal

Blair,

Thank you for your proposal.  It looks really good!  Please see my comments
below.

>    3. Encrypting an [XML <> ] Element
><http://www.w3.org/TR/2000/REC-xml-20001006>  or [XML <> ] element
>Content <http://www.w3.org/TR/2000/REC-xml-20001006>
>         a. The application is responsible serializing the
>Element or Content to produce a valid string-based XML source
>representation.  This could be a simple "as-is" serialization (commonly
>referred to as the OuterXml and InnerXml for an element) or a
>canonicalized form such as defined in [XML-C14N].  It is assumed the
>application knows the appropriate format to insure the decryptor has
>sufficient information to process the decrypted data.
>         b. If the string-based XML representation not UTF-8
>encoded, it must be converted to UTF-8 prior to passing it to the XML
>Encryptor.  The application must also provide the Type of the data
>(Element or Content).
>         c. The Encryptor accepts the UTF-8 encoded string
>representation and interprets it as an octet sequence for encryption.
>The octet sequence is encrypted based on the algorithm/parameters and
>key value determined in steps 1 and 2 producing an encrypted octet
>sequence.

In this step, the application is expected to produce a valid XML and encode
it using UTF-8 by itself.  However, even if it does not do so, the
following steps seem to work.  Do you think the Encryptor has to check the
input XML?


>    6. EncryptedData Processing
>...
>         b.  If the Type of the encrypted data is not Element or
>Content, then the EncrypedData structure is returned to the application.
>The application may use this as the top-level element in a new XML
>Document or insert it into another XML document.

This step would be taken when the Type is not specified.


>4.2 Decryption
>For each item to be decrypted (either an EncryptedData or EncryptedKey
>element):
>
>    1. Parse the application identified element to determine the
>algorithm, parameters and key to be used.

This step should be clarified more as follows: "1. Parse the application
identified element to determine the algorithm, parameters and KeyInfo
element to be used.  If some information is omitted, the application must
supply it."


>    2. If the data encryption key is encrypted, locate the
>corresponding key to decrypt it. (This may be a recursive step as the
>key may itself be encrypted. Or, one might retrieve the data encryption
>key from a local store using the provided attributes or implicit
>binding.)  If the data encryption key is not stored in an accessible
>EncryptedKey structure, then the application must supply the correct key
>value.  Key attributes, stored in a KeyInfo element, may supply hints
>for locating this key.

This step seems to instruct that the Decryptor has to process EncryptedKey
elements in a KeyInfo element first and then process the other key
attributes, but I think it makes no sense to define the processing order.
So I propose the following: "2. Locate the data encryption key according to
the KeyInfo element, which may contain one or more key attributes but there
is no processing order among them.  If the data encryption key is
encrypted, locate the corresponding key to decrypt it.  (This may be a
recursive step as the key may itself be encrypted.)  Or, one might retrieve
the data encryption key from a local store using the provided attributes or
implicit binding."


>    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?


>    5. Decrypting other Types of data
>         a. The cleartext octet sequence obtained in Step 3, and
>Type if available, is always returned to the application for further
>processing.

This step would be taken when the Type is not specified.


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

Received on Thursday, 9 August 2001 08:42:35 UTC