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

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 29 Jul 2002 17:54:02 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OFEDD8BA5E.22A217EE-ON49256C05.002C6119@LocalDomain>


>You have a good point, and I've added text to the Limitations
>part of the document that tries to describe this problem
>and recommends placing the XPath/... transform first; if you
>don't like this, please proposed text.
>However, you point out that placing the XPath first will
>solve the problem in most cases. Adding the MAY text solves
>only a miniscule number of additional cases:
>. Undoable super encryption must be performed
>. AND this encryption must change the structure of the document,
>    preventing the XPath from going first
>. AND the unprocessable encrypted data must occur in a part of
>    the super-encrypted document that is removed by the XPath.
>. BUT the super encryption must not change the structure
>    of the document sufficiently to break the signature reference.
>Your MAY text means that in these few cases, the signature
>MAY validate. I don't think that's good enough; either we
>should state that the transform MUST fail or we should state
>that the transform MUST proceed. In the latter case, we could
>almost eliminate exception handling altogether.

My intent was not to solve the problem but rather to enable to use the
decryption transform in any places.  I can easily think of cases where the
decryption transform has to be performed first.  For such cases, I don't
think that we should suppose any place where the decryption transform is

>I'm not proposing the prohibition of full XPointers, I'm
>proposing that we limit our super-encryption hack to just
>handle barename XPointers. In the normal case, full XPointers
>are processed fine. If, however, someone has an exception
>URI that points into a super-encrypted block, then normal
>XPointer processing cannot be performed and we have to
>fall into a hack, which is to identify super-encrypted
>EncryptedData elements based on their Id attribute and barename
>XPointers. We're no longer doing XPointer evaluation, we're
>doing a hack; I want to keep this hack simple, because the
>added complexity of handling #xpointer(id('foo')) XPointers
>doesn't buy us anything.
>Handling full XPointers in main-document exceptions is really
>useful. Extending this into our hack isn't useful; it has
>cost with absolutely no benefit.

So I'm proposing to make it recommended or optional to implement.
Considering that support of full XPointers in main-document exceptions is
optional, it seems natural to make support of them in sub-document
exceptions optional.  However, I don't have so strong opinion on this, so I
can take yours.

Tokyo Research Laboratory
IBM Research
Received on Monday, 29 July 2002 04:54:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:04 UTC