Re: Data replacement

On Tuesday 05 February 2002 23:40, Takeshi Imamura wrote:
> >        <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>
> ...
> How about "a document [XML, section 2.1]" instead of "an XML Information
> Set"?  I think it is still confusing.

I removed the compressed bit and now refer to an XML document. I also 
tweaked that text. My intent is to express that the EncryptedData's Type 
tells you how to get/intepret the octets. We happen to define two Types 
(Content and Element) with their associated interprations (UTF-8) and 
possible processing (return or replace). Other people might define other 
Types that will also to you how to marshal and interpret the octets. If the 
decrypted data is octets and you don't need to do anythering further with 
it in the xenc context, one can also use the MimeType and Encoding 
attributes to describe the octets at that level but no action or processing 
is implied.

> >        <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.
>
> I agree with you on this.  If we address such a case, we might have to
> introduce another attribute.

Nope! No new attribute is needed. Consider again the two examples I used, 
they mean different things:

1. A NEW COMPRESSED TYPE

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

This means that the data is of type 
'http://www.example.org/xmlenc#zipCompressed', which is presumable defined 
somewhere (if a W3C spec you can dereference it to find the definition.) 
Just as we define what you do '&xenc;Content' and '&xenc;Element' and what 
sort of data one is processing, 'zipCompressed' might have similar 
processing instructions. One might expect its specification to say 
"after you decrypt it you'll get an XML document including compressed data 
and the mediatype of its uncompressed form; decompress the data and provide 
the resulting octets and its (optional) media type) to the application."

This same mechanism is how might one also support XML beyond the character 
data of XML 1.0 . For example, one could take an unambigous Infoset 
description/serialization (e.g., an RDF description of an Infoset [1], or a 
python pickled [2] DOM node) of an Element item and encrypt that and give 
it a type URI. Then a xenc application that supports that Type might be 
able to do much more sophisticated "replacement". 

[1] http://www.w3.org/2001/04/infoset
[2] http://www.python.org/doc/current/lib/module-pickle.html

Not everyone needs to support these types, they are extensions but it 
demonstrates that the mechanism itself is very powerful and flexible.

2. OCTETS WITH AN ORDINARY MEDIATYPE

I originally gave the following as (incorrect) example to demonstrate that 
one shouldn't infer any ordering:

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

but it's not really correct to have both. The type shouldn't be present. If 
one encrypted some octets and one should use:
        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         MimeType='application/zip'>
             ....
        </EncryptedData>

All this says is that you will be getting octets of application/zip 
mediatype back. How the media type of the unzipped data is determined (or 
specified) is up to that mediatype's definition -- if it does it at all.


I tried to make this more clear in the Encryption processing step.

-- 

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 Monday, 11 February 2002 15:50:24 UTC