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

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

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 30 May 2002 14:37:29 -0400
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-Id: <20020530183730.1C377675@policy.w3.org>

On Thursday 30 May 2002 12:57 pm, merlin wrote:
> 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.

Understood. While not specified, my expectation was that such a thing could 
be accomodated via a step 3.5 in decryptIncludedNodes() that said something 
like:
2. If the value of the Type attribute of e is &xenc;Element or 
&xenc;Content ...
3. If the Type attribute is absent or otherwise indicates octets ...
/+3.5 If the value of the Type attribute is some other value, perform the 
decryption and processing as defined by that Type. If they type is unknown 
or unsupported, fail.+/

So in the following:

<Document>
  <SignedPart>
    <Data />
    <EncryptedData ID="enc1" Type="http://merlin.org/foo#PrivateKey" ... />
    <EncryptedData ID="enc2" Type="http://merlin.org/gzip#Element" ... />
  </SignedPart>
  <Signature>
    ...
    <Transform Algorithm="&dcrpt;">
      <Except URI="#enc2" xmlns="&dcrpt;"/>
    </Transform>
    ...
  </Signature>
</Document>

The Signature is over the Document with enc1 as is, but the uncompressed 
clear text form of enc2. Would adding this step 3.5 be satisfactory?
Received on Thursday, 30 May 2002 14:38:10 GMT

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