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

Re: Decryption Transform processing question

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 3 Jun 2002 01:16:33 +0900
To: merlin <merlin@baltimore.ie>
Cc: Ari Kermaier <arik@phaos.com>, xml-encryption@w3.org
Message-ID: <OF384C830F.DDA8F343-ON49256BCC.0053505F@LocalDomain>

Hi Merlin,

>Bear in mind that applications that encrypt parts of a signed
>document cannot, by definition, be ignorant of XML security
>concerns. They must understand that namespaces cannot be
>rewritten, whitespace cannot be changed, comments cannot
>be stripped, etc. With this in mind, trying to produce
>a specification that can undo arbitrary changes made by
>arbitrary security-ignorant applications is, in my opinion,
>a white elephant. These applications must be aware of the
>limitations of the tools that they have available to them.
>Multiple encryption is a minor limitation of this tool.

I don't agree.  I don't still think that limiting multiple encryption makes
sense.  According to the discussion, it seems that you are concerned about
the following:

1. XPointer evaluation
2. Reference to outside of an EncryptedData element

I understand that there are some cases where 1 and 2 are not addressed
properly, but considering the purpose of decryption transform, I don' think
that we should limit the function of the transform for that reason.
Rather, I prefer to limit 1 and 2.  As for XPointer, all we have to do is
to note in the spec that it is recommended to use "#xpointer(id('ID'))".
As for reference, the transform is not responsible for whether a reference
can be dereferenced or not.  If the reference is not dereferenced, the
validation will fail, but that is the correct result.

Tokyo Research Laboratory
IBM Research
Received on Sunday, 2 June 2002 12:44:04 UTC

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