Re: Custom XML Types (Was: Decryption Transform processing question)

On Thursday 30 May 2002 05:15 pm, merlin wrote:
>   <SignedData>
>     <EncryptedData Type="&foo;" ... />
>     <EncryptedData Type="&bar;" ... />
>   </SignedData>
>
> The specifications &foo; and &bar; can't really describe how
> the decryption transform should operate over this. 

No... I think they would need their own decryption transform (more below):

1. XML Instance

<doc>
  <hello>Nice to meet you!</hello>
  <goodbye/>
</doc>

2. Compress the element content

<doc>
  <hello><zip Type="http://www.w3.org/2001/04/xmlenc#Content">
     cafebabe..</zip>
  </hello>
  <goodbye/>
</doc>

3. Encrypt the zip element and indicate it should be unzipped:

<doc>
  <hello>
    <EncryptedData Type="http://examle.org/CompressedContent">babecafe..
    </EncryptedData>
  </hello>
  <goodbye/>
</doc>

4. A receiving application will see the 3rd instance and, if familiar with 
the type, know that upon decryption it will get a <zip> element, which has 
compressed XML element content.

5. Your point is that If I had signed the original document the decryption 
transform would not know how to deal with this EncryptedData because
its Type is not known by the decryption transform.

<doc>
  <hello>
    <EncryptedData Type="http://examle.org/CompressedContent">babecafe..
    </EncryptedData>
  </hello>
  <goodbye/>
  <Signature URI="#h1"/>
     <Transform ...><Except URI="#enc1"/><Transform>
  <Signature>
</doc>

6. I'd agree, and suggest that someone would define a new Decryption
Transform for that type. You seem to be indicating that seems wasteful
because aside from the decryption it's the same as the Decryption Transform
for XML.
A. Yes, so the spec should be straightforward.
B. Yes, but this compression scenario is perhaps not the best example
of using the Type and XML nesting. Since it's so straightforward,
couldn't decrompession be built into part of the EncryptionMethod?
C. The scenarios where this Type facility would be for types quite
distinct from XML 1.0 (should anyone every go there) such as an Infoset
Item or pickled DOM node or some such thing.


Had we not made the two decisions of (a) trying to keep the 
Encryption/Decryption processing fairly abstract and pushing specifics to 
only where they are needed (such as the Decryption Transform) and (b) 
deciding we wouldn't specify nor require support for transforms (like
the ones we are discussing) there might be a different conceptualization
that would be more elegant than specifying a nested XML structure or 
"compound" EncryptionMethod there might be a different way of conceiving of 
these problems, but I expect those are decisions we can't undo, unless you 
were suggesting another alternative other than the XMLType?

Received on Friday, 31 May 2002 17:46:49 UTC