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.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com
Received on Sunday, 2 June 2002 12:44:04 UTC

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