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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Tue, 07 May 2002 22:54:08 +0100
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: xml-encryption@w3.org
Message-Id: <20020507215408.778DC44C41@yog-sothoth.ie.baltimore.com>
r/IMAMU@jp.ibm.com/2002.05.03/17:23:38
>>The serialization is necessary for bizarre node sets that cut out
>>parts of an EncryptedData, but that just introduces a whole bunch
>>of problems. It is probably easiest and best for many reasons if
>>we decrypt the element e, regardless of what children are present
>>in the node set. So:
>
>I'm not confident of this.  Maybe we should ask the XPath WG if, in this
>case, it is correct to access nodes that are not in a node-set.

I'm not sure that it is an XPath WG question; it is an issue of
whether we interpret the input node set as identifying
EncryptedData elements or selecting EncryptedData structures,
and there are arguments in either direction.

Though I'm loathe to give it, my specific example is:
  <Document>
    <SignedData>
      <enc:EncryptedData>
        ..#1..
        <enc:EncryptionProperties>
          <enc:EncryptionProperty>
            <Foo>
              <enc:EncryptedData>
                ..#2..
              </enc:EncryptedData>
            </Foo>
          </enc:EncryptionProperty>
        </enc:EncrtypionProperties>
      </enc:EncryptedData>
    </SignedData>
  </Document>

Run through the XPath transform:
  self::enc:EncryptedData[not(ancestor::Foo)] or
  ancestor::Foo[not(self::enc:EncryptedData)]
(This may need tweaking for namespace nodes, etc.)

The result is:
  <enc:EncryptedData>
    ..#2..
  </enc:EncryptedData>

If we are to cater for cases like this, most implementations
will probably need to serialize and parse the node set.

Personally, I do not think that this is a use case worth
supporting. Requiring serialization rules out the following:
  <Document>
    <SignedData>
      <EncryptedData>
        <EncryptedKey>
          <RetrievalMethod URI="#recipient" />
        </EncryptedKey>
      </EncryptedData>
      <EncryptedData>
        <EncryptedKey>
          <RetrievalMethod URI="#recipient" />
        </EncryptedKey>
      </EncryptedData>
    </SignedData>
    ...
    <KeyInfo>
      <X509Data Id="recipient" />
    </KeyInfo>
  </Document>

I would argue that supporting the second type of document is
more important than the first, and we should therefore decrypt
the element e, without regard to what children are present in
the node set.

More importantly, if an application actually wants to apply
strange XPath filters, then they can perform an explicit c14n
step and get exactly the behaviour that they desire.

Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com
Received on Tuesday, 7 May 2002 17:54:22 GMT

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