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

Make that ACTION-439.  Apologies.
--
Thomas Roessler, W3C  <tlr@w3.org>







On 7 Dec 2009, at 14:51, 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 Monday, 7 December 2009 13:52:58 UTC