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

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Wed, 8 May 2002 14:56:53 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OFED15DFCC.778AF23D-ON49256BB3.001DAF50@LocalDomain>


>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:
>  <SignedData>
>    <enc:EncryptedData>
>      ..#1..
>      <enc:EncryptionProperties>
>        <enc:EncryptionProperty>
>          <Foo>
>            <enc:EncryptedData>
>              ..#2..
>            </enc:EncryptedData>
>          </Foo>
>        </enc:EncryptionProperty>
>      </enc:EncrtypionProperties>
>    </enc:EncryptedData>
>  </SignedData>
>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.

Maybe.  Actually, our current implementation does serialization and
parsing.  But I think that it is possible to support this case without
doing them.

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

Whether serialization is required or not, considering the meaning of the
same-document reference, the reference should be dereferenced over the
original tree, I think.

>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.

I agree that supporting the second case is important, but sorry, I don't
still understand why it is the rationale of decrypting e regardless of what
children are present in the node-set.  Could you explain this more?

>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.

Tokyo Research Laboratory
IBM Research
Received on Wednesday, 8 May 2002 02:12:11 UTC

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