Re: Review of XML Encryption / EXI integration (ACTION-493)

Thomas

I'm not sure about the following

> It's probably useful to point out that the *intended* style of  
> processing is to use EncryptedData, and replace an encrypted element  
> with it, but that the details of that process are out of scope for  
> this specification.


It seems that replacing an element with an EncryptedData element is a  
core concept of the specification and should be normatively specified  
- currently there is a SHOULD in the specification.

4.3 is  a bit odd, it says it is non-normative, but that SHOULD be  
supported and that other specs may make it normative... Agree we  
should clarify the normative bits versus the informative.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 7, 2009, at 8:51 AM, ext Thomas Roessler wrote:

> Per ACTION-493, I was to propose specific text for integrating EXI  
> into XML Encryption 1.1.  The relevant changes would have to occur  
> in section 4 of the XML Encryption specification:
>
>  http://www.w3.org/TR/xmlenc-core1/#sec-Processing-Encryption
>
> It turns out that this processing model chapter mixes a number of  
> things that we might be better off separating.  In particular, both  
> section 4.1 and 4.2 (encryption and decryption processing models)  
> mix requirements on the encrypted document, the processors, the  
> interface between the processor and the application, and the  
> application.  (E.g., "the application MUST provide XML data in  
> [NFC]" -- this seems to actually be an assumption that's made of XML  
> cleartext.)
>
> In 4.3, we have a lot of implementation advice with funny  
> conformance clauses such as "special care SHOULD be taken" -- but  
> also with some rather important material about name space processing  
> in 4.3.3 that probably should be normative (but currently doesn't  
> seem to be).  It seems like the normative content of that section is  
> actually limited to the "MUST IMPLEMENT" for 'element' and 'content'  
> type cleartext.  I'd prefer to move that particular paragraph out of  
> 4.3, and make the entirety of that section non-normative.
>
> Also note that the specification text is confused about the value  
> space of the Type parameter -- that's anyURI, not string; therefore,  
> 'element' and 'content' are really shorthand for the requisite URI  
> references.
>
>
>
> Back to 4.1 and 4.2:  I believe that the normative content of 4.1  
> can be summarized as follows (some of the language is still a bit  
> rough):
>
>>>>
> If a key is encrypted, it MUST be encapsulated in an EncryptedKey  
> element.  That element may be transported along with the message as  
> a child of a ds:KeyInfo, or otherwise.
>
> If a key is derived from a master key, an appropriate DerivedKey  
> element must be constructed.  That element may be transported along  
> with the message as a child of a ds:KeyInfo element, or otherwise.
>
> If the cleartext is an XML element or content, then it MUST be  
> serialized as an octet-stream using UTF-8 in normal form C. The Type  
> attribute of an eventual EncryptedData element SHOULD be present.   
> If present, it MUST be 'http://...#content' or 'http://...#element'.
>
> [[ If the cleartext is an EXI fragment, then it MUST be serialized  
> as an octet sequence that represents an EXI stream. ]]
>
> Otherwise, the cleartext MUST be an octet stream.
>
> The ciphertext is obtained by encrypting this cleartext; no further  
> preprocessing of the cleartext in this document.
>
> The ciphertext can be stored externally, or (in base64 encoded form)  
> in the CipherValue element.
> <<<
>
> It's probably useful to point out that the *intended* style of  
> processing is to use EncryptedData, and replace an encrypted element  
> with it, but that the details of that process are out of scope for  
> this specification.
>
> Note that the schema type of CipherValue is base64binary, therefore  
> it would seem superfluous to normatively mention a separate base64  
> encoding step in the processing model; in fact, having an explicit  
> base64 encoding step could be read to indicate *double* encoding.
>
>
> For 4.2, the normative context of the decryption step seems to boil  
> down to:
>
>>>>
> Retrieve the ciphertext octet-stream from a CipherData element,  
> either by using the value of CipherValue, or by processing a  
> CipherReference element.
>
> The ciphertext is decrypted.  The cleartext octet-stream is,  
> according to the value of the Type parameter, interpreted as:
>
> 1. an UTF-8 encoded XML element or content; or
> [[ 2. an EXI stream; or ]]
> 3. an octet-stream.
>
> Handling of the MimeType and Encoding parameters is up to the  
> application, and out of scope for this specification.
> <<<
>
> We should again say, additionally, that the intended processing  
> model is to replace an EncryptedData element that holds "element" or  
> "content" cleartext with that cleartext; I wonder whether we need to  
> say anything special about EXI.
>
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
>

Received on Wednesday, 30 December 2009 15:17:21 UTC