W3C home > Mailing lists > Public > xml-encryption@w3.org > February 2002

Re: Data replacement

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 5 Feb 2002 16:23:01 -0500
Message-Id: <200202052123.QAA20671@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org
On Tuesday 05 February 2002 02:52, Takeshi Imamura wrote:
> I don't have any concrete serialization, but one may want to serialize an
> element in UTF8 and then compress it...

I think this could be done by providing the compression algorithm as the 
type. I believe that we said instead of providing a sophisticated transform 
mechanism such as xmldsig, such content could be wrapped. So for instance,

        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         Type='http://www.example.org/xmlenc#zipCompressed'>
          <CipherData>
            <CipherValue>A23B45C56</CipherValue>
          </CipherData>
        </EncryptedData>

When the CipherValue is decrypted, one might have:
  <zipCompressed xmlns='http://www.example.org/xmlenc#zipCompressed'
    Type="http://www.w3.org/2001/04/xmlenc#Content">
       76fdsawerwae74747
  </zipCompressed>

 
> Yes.  But anyway, I think I understand what the spec says, and to my
> understanding, the sentence in step 3.2 for encryption:
>
> For example, the data might be a serialization of an XML Information Set,
> set of characters, binary image data, or a compressed XML element.
>
> may be confusing because "an XML Information Set" and "a compressed XML
> element" seem to hint an element or element content being encrypted.

How about if I move the comressed bit and add the following e.g.,'s:

For example, the data might be a serialization of an XML Information Set 
(MimeType="text/xml"), set of characters (MimeType="text/plain"), or binary 
image data (MimeType="image/png").

We can not address compressed XML, or elsewhere in the document mention if 
one has a compressed element content one might use the approach I specified 
above. I think we'd also want to point out that the following is not 
approriate as the MimeType is supposed to complement the Type attribute if 
both are available, it's not a transform mechanism:

        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         Type='http://www.w3.org/2001/04/xmlenc#Content'
         MimeType='application/zip'>
             ....
        </EncryptedData>

(The MimeType should not be read as "first do me then look at the 
corresponding Type." Type, MimeType, and Encoding should all be concurrent 
and accuration descriptions of the decrypted form of the CipherData.

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Tuesday, 5 February 2002 16:23:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT