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

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:

<Document>
  <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>
</Document>

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.

Merlin

r/reagle@w3.org/2002.05.30/12:23:10
>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 12:59:11 UTC