Re: Decryption Transform processing question

Hi Takeshi,

r/IMAMU@jp.ibm.com/2002.07.24/18:55:54
>>If some EncryptedData elements don't have to be replaced
>>then the encryptor will have used Except elements to
>>identify them. Any EncryptedData that are not excepted
>>have been encrypted *after* the signature was generated,
>>so *must* be decrypted before it will verify.
>>
>>If I'm just missing something, could you give a brief
>>pseudo-XML example?
>
>OK.  Suppose that a signer signed the b element of foo.xml and stored the
>signature in bar.xml.
>
>foo.xml:
><a>
>  <b>...</b>
>  <c>...</c>
></a>
>
>bar.xml:
><Signature xmlns=".../xmldsig#">
>  ...
>  <Reference URI="foo.xml">
>    <Transforms>
>      <Transform Algorithm=".../decrypt#"/>
>      <Transform Algorithm=".../REC-xpath-19991116">
>        <XPath>
>          *[name()='b']
>        </XPath>
>      </Transform>
>    </Transforms>
>    ...
>  </Reference>
>  ...
></Signature>
>
>Note that the he placed the decryption transform prior to the XPath
>transform in order to allow subsequent encryption of a part including the b
>element.  However, suppose that the c element was encrypted contrary to his
>expectation.
>
>foo.xml:
><a>
>  <b>...</b>
>  <EncryptedData xmlns=".../xmlenc#">...</EncryptedData>
></a>
>
>In this case, a verifier has to decrypt the encrypted part though the c
>element is not actually required for digest calculation.  If he can do so,
>it would be OK.  However, he can't always do so.  That is why I added a
>sentence allowing to skip encrypted parts.

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.

>>In XMLDSIG, we define the two to be semantically different;
>>URI #foo means one thing, whereas #xpointer(id('foo')) means
>>something else. I want to retain this semantic difference
>>here.
>>
>>Otherwise, how should we process the following equivalent:
>>URI #xmlns(foo=bar)xpointer(id('baz'))xpointer(//foo:Bar[@Id='baz'])
>>
>>In my opinion, anything other than a bare name is something
>>that we do not want to process because we cannot easily
>>know that it is not broken in the new context.
>
>To tell the truth, I don't want to process full XPointers :-)  However,
>given the fact that a bare name is just a shorthand of a full expression in
>the XPointer spec and there is no reason to distinguish their semantics in
>this case, I don't think that it makes sense to limit the spec
>unnecessarily.  So how about making support of a full expression of type
>"xpointer(id('ID'))" recommended or optional?

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.

Merlin