RE: Section 4.1 and 4.2 proposal

Takeshi,

Thank you for the excellent comments.  Responses in-line below.

Blair

> -----Original Message-----
> From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com] 
> Sent: Wednesday, August 08, 2001 4:03 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,
> 
> 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?
> 

My opinion is that the Encryptor need not do this.  The 
application is responsible for providing valid input.  If
they don't then decryption processing may be impossible.
That said, an implementor may decide to provide
such validation as a value added service.

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

Yes, unspecified makes the type not Element or Content.  But,
we can make this explicit by stating
"If the Type of the encrypted data is unspecified or is not
Element or Content ...."


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

I'm happy to use your text.


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

I agree and did not intend to imply a processing order. 
Your text sounds good to me.

> 
> >    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's response to this seems to capture my intent.  If his 
wording seems clearer I'm happy to go with that.

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

Agreed, we can make this explicit with wording suggested above.

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

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