Re: Decryption Transform processing question

Hi Merlin,

I'm sorry for not replying sooner, but here are my comments:

>This is no different from an unknown encryption algorithm:
>The recipient does not know how to process the type, so it
>cannot process the data. We have to fail in this case; the
>encryptor has produced data that we cannot verify; we should
>not try and verify something else in this case.
>
>Essentially, the octet-stream text defeats the only way
>that we can combine compression and encryption, which is to
>use the strong typing mechanism. I think that the typing
>system is really important for this reason.

I don't think that the text defeats the way because it allows to process an
octet-stream further.  However, comparing this case with an unknown
algorithm case, you may be right.  So it's now OK to me.

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

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

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Wednesday, 24 July 2002 05:56:03 UTC