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

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

From: Ari Kermaier <arik@phaos.com>
Date: Thu, 30 May 2002 13:44:06 -0400
Message-Id: <>
To: merlin <merlin@baltimore.ie>, reagle@w3.org
Cc: xml-encryption@w3.org

The ability to use information about the type of the encrypted content is 
of interest to any application using the XML-ENC decryption process, not 
only to DecryptionTransform. I'm strongly of the opinion that, if this sort 
of functionality is to be included in Decryption Transform, then it should 
rely exclusively upon the Type syntax specified in Encryption, and remedy 
any deficits using processing rules rather than new syntax in Decryption 
Transform. While I'm sure the proposed XMLType element would be convenient 
for certain usage scenarios, it seems too application-specific and too 
prone to incompatibility/redundancy with similar-but-not-equivalent 
solutions to this problem that will undoubtedly arise in other applications 
of XML Encryption.

So I'd support a well-considered variation on the alternative that Merlin 
propses below (using any Type URI to signal the presence of XML content), 
but the proposal for an XMLType element makes me very uncomfortable.

Ari Kermaier

At 05:57 PM 5/30/02 +0100, merlin wrote:

>The problem I'm trying to solve is that the decryption
>transform is fixed in its understanding of what EncryptedData
>are XML and whare are not: Two Type URIs indicate XML content;
>all others indicate binary content. This renders the
>decryption transform fundamentally incompatible with any
>future specifications that encrypt XML data.
>If another standard specifies that the Type URI &foo;PrivateKey
>indicates that the content is an encrypted foo:PrivateKey
>element then this cannot be used with the decryption transform.
>If another standard specifies that the type URI &gzip;Element
>indicates that the content is an encrypted, gzipped elmement,
>then this cannot be used with the decryption transform.
>So, I propose that the decryption transform can be
>parameterized with additional Type URIs that it should consider
>as XML, internal processing of which MAY be specified by
>another standard (e.g., gzip).
>The result is:
>   <SignedPart>
>     <Data />
>     <EncryptedData Type="http://merlin.org/foo#PrivateKey" ... />
>     <EncryptedData Type="http://merlin.org/gzip#Element" ... />
>   </SignedPart>
>   <Signature>
>     ...
>     <Transform Algorithm="&dcrpt;">
>       <XMLType URI="http://merlin.org/foo#PrivateKey" />
>       <XMLType Prefix="http://merlin.org/gzip#" />
>     </Transform>
>     ...
>   </Signature>
>Under the existing decryption transform, I cannot sign these
>EncryptedData elements. They will both be considered as
>binary data, even though the former is a simple serialized
>foo:PrivateKey element and the latter is a gzipped element.
>The proposed parameter to the decryption transform specifies
>that the Type URI http://merlin.org/foo#PrivateKey, and
>any Type URI starting with http://merlin.org/gzip# is to
>be considered as indicating that the plaintext content is
>XML. So the internal decryption process is done as per the
>spec that specifies the Type URI; the result is then handled
>by the decryption transform as if it were UTF-8 serialized
>XML content.
>Another option would be that we state that *ANY* Type URI
>indicates that the content is XML; the internal processing
>of the data will be specified by the appropriate standard,
>and the result will be a UTF-8 encoded stream of XML which
>the decryption transform handles as normal. This might be
>good because it would go some way towards differentiating
>the Type and MimeType attributes, which are, at present,
>somewhat undistinguishable.
> >On Wednesday 29 May 2002 07:36 pm, merlin wrote:
> >> I would like to be able to indicate that certain custom Type
> >> URIs should be treated as XML. For example, I would like to
> >> be able to have <EncryptedData Type="&foo;PrivateKey" ... />
> >> to indicate that encrypted data are a PrivateKey element. I
> >> agree that this is just &enc;Element; however, the alternative
> >> type is more informative. For a proposed solution, see the
> >> attached (which is my suggested changes with another change).
> >
> >1. I'm unclear about the prefix and URI thing in your proposal. I think an
> >example would help.
> >2. Is this type the actual element type? If so, why not just encrypt its
> >content instead of the element type name?
> >3. My preference is not to include more type attributes. My expectation is
> >if there was a type such as &foo;PrivateKey somewhere there would be a
> >specification (e.g., dereference it) that says "treat me just like
> >&xenc;Element and also foo." This definitely applies if that "foo" (e.g.,
> >decompress the content of that element using gzip) is some
> >normative/required behavior. I suspect in your scenario, this is not the
> >case? All you want is the &xenc;Element behavior but the foo is useful but
> >informational?
> >
> >For example, if that foo is normative, then the processing will fail
> >because it doesn't know what to do with it. But if it's not, it'll still be
> >processed as &xenc;Element and the "foo" is ignored?
> >
> >Even we did go this route, that means we'd have
> >1. A normative Type attribute.
> >2. An ?informational? Other attribute. (Your XMLType element though I don't
> >yet understand it.)
> >3. An informational MimeType attribute.
> >
> >It's getting sort of hairy.
> >
> >--
> >
> >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 Thursday, 30 May 2002 13:42:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC